Pfe Version Finale

REMERCIEMENTS
Nous tenons à remercier Monsieur Régragui, Directeur de FORINFO, pour

avoir bien voulu nous accueillir et nous avoir préparé les conditions favorables au bon
déroulement de notre stage.
Nous tenons à remercier également Monsieur Zaamoune, pour avoir bien voulu
nous encadrer et nous guider dans la conception et la réalisation de notre application.
Nos remerciements vont ensuite à Monsieur A. El Faker, notre encadrant à

l’ENSIAS, pour son suivi, en lui exprimant notre profonde gratitude pour tous les
efforts qu’il a consentis, ainsi qu’à tout le corps professoral et administratif de l’école.
Enfin, nous remercions Monsieur Nabil du CED pour son aide précieuse dans la
compréhension de la GIPE.
Et que tous ceux qui ont attribué de près ou de loin à l’élaboration de ce travail
trouvent ici, l’expression de notre profonde gratitude.
Projet de Fin d’Etudes 2003/2004
LISTE DES ABREVIATIONS
Abréviation Désignation
CPS Cahier des Prescriptions Spéciales
GIPE Gestion Intégrée du Personnel de l’Etat
GP Gestion du Personnel
GRH Gestion de Ressources Humaines
J2EE Java 2 Entreprise Edition
MCD Modèle Conceptuel de Données
MERISE Méthode d’Etude et de Réalisation Informatique par Sous Ensembles
MPD Modèle Physique de Données
MVC Modèle-Vue-Contrôleur
SGBD Système de Gestion de Bases de Données
UML Unified Modelling Language
3
LISTE DES FIGURES
Figure 3.1 : Diagramme des cas d’utilisation des appels à candidatures……………….. 28

Figure 3.2 : Diagramme de séquence pour le scénario «informations sur les appels»….. 29
Figure 3.3 : Diagramme de séquence pour le scénario « inscription »………………….. 30
Figure 3.4 : Diagramme de collaboration pour le scénario «traitement des inscriptions». 31
Figure 3.5 : Diagramme des cas d’utilisation de la formation………………………….. 32
Figure 3.6 : Diagramme de séquence pour le scénario «définition des besoins………... 33
Figure 3.7 : Diagramme de séquence pour le scénario «analyse des pré-inscriptions»… 34
Figure 3.8 : Diagramme de collaboration pour le scénario «annonce des besoins »……. 35
Figure 3.9 : Extrait du dictionnaire de données…………………………………………. 36
Figure 3.10 : MCD des deux modules : formation et appels à candidature………….…... 38
Figure 3.11 : MPD des deux modules : formation et appels à candidature…………..…... 39
Figure 4.1 : Architecture 3-tiers……………………………………………………...…. 42
Figure 4.2 : Schéma d’implémentation du modèle MVC…………………………..….... 44
Figure 4.3 : Architecture du site des appels à candidatures…………...……………..…. 46
Figure 4.4 : Page des appels à candidatures…………………………………………..... 47
Figure 4.5 : Les appels à candidature saisis par le département…………………...…… 48
Figure 4.6 : Saisie des appels à candidature par le département……………………...… 49
Figure 4.7 : Les résultats des appels à candidatures…………………………………….. 50
Figure 4.8 : Le titulaire du poste……………………………………………………...… 51
Figure 4.9 : S’inscrire à un appel à candidature……………………………………….... 52
Figure 4.10 : Le formulaire d’inscription…………………………………………..…….. 53
Figure 4.11 : Visualisation des inscriptions……………………..………………….……. 54
Figure 4.12 : La validation des inscriptions………………………………………….…... 55
Figure 4.13 : Aperçu d’un e-mail…………………………………………………….…... 56
Figure 4.14 : Architecture du site de la formation……………………………………...… 57
Figure 4.15 : Mise à jour des thèmes……………………………………………...……… 58
Figure 4.16 : Ajout d’un nouveau thème…………………………………………...…….. 59
Figure 4.17 : Mise à jour des programmes…………………………………………...…... 60
Figure 4.18 : Mise à jour des thèmes d’un programme………………………………...… 60
Figure 4.19 : Exemple d’un e-mail………………………………...………...…………… 61
Figure 4.20 : Exemple de lettre de notification………………………………...………… 62
Figure 4.21 : Choix d’un thème…………………………………………………...……… 63
Figure 4.22 : Formulaire d’inscription……………………………………………...……. 63
Figure 4.23 : le cahier de prescription des spécifications (CPS)……………………...….. 64
4
SOMMAIRE
INTRODUCTION GENERALE……………………………………………… 7
CHAPITRE 1 : Contexte du projet…………………………………………… 8

1.1 Présentation de FORINFO…………………………………………….. 9
1.2 Description du projet…………………………………………………... 13
CHAPITRE 2 : Analyse des besoins…………………………………………... 14

2.1 Analyse de l’existant…………………………………………………... 15
2.1.1 GIPE……………………………………………………………... 15
2.1.2 Gestion des appels à candidatures……………………………….. 17
2.1.3 Gestion de la formation………………………………………….. 18
2.2 Spécification des besoins……………………………………………… 21
2.2.1 Cahier des charges………………………………………………. 21
2.2.2 Assurance qualité………………………………………………... 23
CHAPITRE 3 : Conception des modules…………………………………….. 26

3.1 Conception des traitements……………………………………………. 27
3.1.1 Module des appels à candidatures……………………………….. 27
3.1.2 Module de la formation………………………………………….. 31
3.2 Conception de la base de données…………………………………….. 36
3.2.1 Le dictionnaire des données……………………………………... 36
3.2.2 Les règles de gestion…………………………………………….. 37
3.2.3 Modèle conceptuel de données………………………………….. 38
3.2.4 Modèle physique de données……………………………………. 39
CHAPITRE 4 : Réalisation de l’application…………………………………. 41

4.1 Environnement technique……………………………………………... 42
4.1.1 Architecture choisie et outils d’implémentation………………… 42
4.1.2 Modèle MVC…………………………………………………… 44
5
4.2 Réalisation du module des appels à candidatures…………………….. 46

4.2.1 Architecture du site …………………………………………….. 46
4.2.2 Réalisation du module…………………………………………... 47
4.3 Réalisation du module de la formation……………………………….. 57
4.3.1 Architecture du site de la formation.……………………………. 57
4.3.2 Réalisation du module de la formation…………………………. 58
4.4 Tests et mise au point……………………………………………….... 65
CONCLUSION GENERALE……………………………………………….... 66
BIBLIOGRAPHIE…………………………………………………………….. 67
ANNEXE 1 : Dictionnaire de données………………………………………... 68
ANNEXE 2 : Outils de réalisation …………...……………………….…….... 72
ANNEXE 3 : Exemples de codes sources…………………………………….. 80
6
INTRODUCTION GENERALE
FORINFO est une société privée spécialisée dans l’informatique et la formation du

personnel des administrations publiques. Ces administrations utilisent en majorité un
système de Gestion Intégré du Personnel de l’Etat (GIPE).
GIPE est un progiciel qui a pour objectif d’automatiser les procédures de gestion du
personnel telles que la dernière situation de l’agent, la loi cadre, les actes de
gestion …. Cependant, il demeure incomplet, voir inutilisable en ce qui concerne la
gestion des ressources humaines (GRH).
Les ministères clientes de FORINFO ont exprimé le besoin d’un système basé sur la
GIPE mais plus spécialisé en matière de GRH.
Notre projet consiste à concevoir et réaliser deux modules : un pour la gestion des
appels à candidatures et l’autre pour la gestion de la formation. Ces modules peuvent
intégrer ou non (selon le besoin du client) des fonctionnalités intervenant dans le cadre
de la GIPE.
Le présent rapport est une synthèse de notre travail. Il est divisé en quatre chapitres :
Le premier est une présentation générale du contexte du projet, autrement dit une
présentation de l’organisme d’accueil et une description de l’application.
Le deuxième est consacré à l’analyse du projet, depuis l’analyse de l’existant jusqu’à
la spécification des objectifs.
Le troisième est dédié à la conception du projet. Il s’agit des modèles conceptuels et
organisationnels de données et de traitements concernant chaque module de
l’application.
Et dans le quatrième chapitre nous présentons l’environnement technique utilisé ainsi
que la réalisation de chaque module du projet.
7
CHAPITRE 1 : Contexte du projet
Introduction........................................................ 9
1.1 Présentation de FORINFO.......................... 9
1.2 Description du projet................................... 13
Conclusion........................................................... 13
8
Introduction
Dans cette partie nous présentons l’organisme d’accueil au sein duquel nous avons
passé notre projet de fin d’étude à savoir FORINFO.
Nous présentons également une description complète de l’application.
1.1 Présentation de FORINFO
FORINFO, société de conseil et d'ingénierie informatique, a été créée en 1991, par

un groupe de consultants multidisciplinaires, afin de servir l'administration publique et
les entreprises nationales en Conseil, Formation et Développement d'applications
informatiques.
Consciente que la valeur ajoutée de ses prestations réside essentiellement dans la

"matière grise" de son potentiel humain, FORINFO a veillé à avoir une politique des
Ressources Humaines adaptée. Elle s'est ainsi assurée la collaboration de consultants
de haut niveau, constitués d'ingénieurs conseil et autres experts dans les domaines en
liaison avec son métier. Elle a, en outre, particulièrement investi dans la Recherche et
Développement.
Intervenant également, en matière du conseil en Management de la Qualité,

FORINFO tient à appliquer les concepts liés à cette "philosophie" en son sein. Aussi,
être orienté client est non seulement un adage chez FORINFO, mais une réalité de tous
les jours. Cela a bien évidemment des répercussions immédiates sur la manière de
travail. Le souci de FORINFO est d’aller au devant des préoccupations du client.
Utilisant les techniques les plus modernes, aussi bien en termes d’outils et méthodes
d’analyse qu’en terme de logiciels spécialisés, FORINFO tient à donner à ses
prestations une qualité à l’image de l’idéal qu’il entend véhiculer.
1.1.1 Activités de la société FORINFO
Alliant souplesse dans les structures et rigueur dans les méthodes, FORINFO,
hormis les départements Administratif et Commercial, agit aujourd’hui à travers les
départements suivants, dont nous indiquons les spécificités :
9
 Département Audit & Conseil
Formé d’ingénieurs informaticiens et d’experts en organisation et en management,

ce département traite des projets d'envergure, dans le cadre du conseil et de l'ingénierie
globalement tels la réalisation de :
- Plan de Développement Informatique
- Progiciel Intégré pour l’Administration Publique «IAP.2000»
- Audit Informatique
- Etude de Convergence de Solution Standard
- Intégration du Système d’Information
- Suivi de Performance
- Plan Assurance Qualité
 Département Recherche & Développement
Renforcé de concepteurs et de développeurs de hauts niveaux, cette entité peut se

venter d'avoir à son actif une dizaine de logiciels destinés à l’Administration publique
et une maîtrise des technologies nouvelles en matière de génie logiciel et des interfaces
et supports d’information les plus récents. Ce département opère pour des
interventions aussi variées que :
- Editeur de progiciels standards intégrés pour le secteur public
- Réalisation des applications informatiques
- Conception, Réalisation, Mise en place et maintenance des systèmes

d’information
- Mise en place des solutions de conversion ou de migration.
Cette entité veille à développer les compétences de la société, améliorer ses

prestations, et diversifier ses produits.
10
 Centre de formation FORINFO

Composé de six formateurs, l'entité dispense régulièrement un ensemble de
séminaires de formation. Les acteurs du centre dispensent les formations en interne ou
chez le client. Les sessions en interne se déroulent dans des salles équipées en matériel
et logiciels répondant aux besoins de formation sur les techniques et technologies
nouvelles. Le responsable de ce département veille à ce que les normes et standards de
qualité soient respectés, notamment en ce qui concerne le nombre de personnes par
groupe, l’homogénéité des participants, le professionnalisme des intervenants, la clarté
des objectifs par séance et par session. Des formulaires de suivi sont constamment
remplis par les intervenants. Vers la fin de chaque session les participants, renseignent
une fiche d’évaluation. Ces formulaires et fiches permettent d’établir un bilan (rapport)
dégageant les points forts et les faiblesses de chaque action entreprise par le
département. Des réunions périodiques sont tenues pour évaluer la qualité du service
rendu et faire les ajustements et adaptations qui s’imposent.
Outre ces séminaires, le département assure la formation et l’assistance
technique des utilisateurs des applications développées et/ou mises en place par la
société. De par la diversité de ses prestations, FORINFO est à même de proposer des
solutions intégrées à la hauteur des attentes des institutions publiques ou privées,
responsabilité engagée entièrement.
1.1.2 FORINFO en chiffres
FORINFO en chiffres, c’est :
 une quinzaine d’ingénieurs et de collaborateurs qualifiés, à temps plein, à votre

service
 un réseau de vingt sept experts en management public et informaticiens de

renom pour vous accompagner
 plus de 70 % des départements ministériels ont été touchés par une prestation
de service FORINFO
11
 près d’une quarantaine de projets d’étude de convergence, de développement et

de mise en place de progiciels intégrés entrepris.
 éditeur d’une dizaine de progiciels intégrés, dans le cadre de l’IAP.2000,

couvrant différentes activités de gestion de l’Administration publique
 plus de 12 ans d’expérience dans l’informatisation des systèmes d’information

du secteur public
 300 m2 de locaux, sur deux niveaux, au cœur de la capitale administrative
 10 salles, dont 4 dédiées à la formation, dûment équipées en matériel didactique

adéquat
 SSII dont le capital social est de 500.000,00 Dh
12
1.2 Description du projet
GIPE est un progiciel conçu par le CED du ministère des finances pour gérer les
situations administratives des employés. Certains ministères utilisent GIPE, d’autres
ont conçu leur propre système, tandis que le reste ne possède pas ce progiciel.
Les administrations publiques n’accordaient pas d’importance à la gestion des
ressources humaines (GRH), ou la confondait avec la gestion du personnel (GP).
Se contenter de GIPE pour réaliser les deux fonctions (GRH et GP) s’avère
insuffisant. Notre projet consiste à concevoir et réaliser deux modules pour la gestion
des appels à candidatures et de la formation pour les administrations publiques. Ces
modules peuvent intégrer des fonctionnalités intervenant dans le cadre de la GIPE. Ils
peuvent aussi ne pas les intégrer (cela dépend du besoin du client).
Ces modules devant être disponibles pour tous les employés des ministères, il s’agit
donc de les déployer sur le Web.
Notre application suit une architecture 3-tiers. Sa partie traitement est exécutée au
niveau d’un serveur Web, l’accès à la base de données se fait via un serveur de
données tandis que le client utilise un navigateur.
La séparation entre les trois couches : présentation, traitement et logique métier nous
conduit à adopter le standard MVC dans la conception de notre application.
Enfin, notre projet est réalisé en utilisant l’environnement de développement J2EE.
Cela assure des critères de portabilité et de stabilité exigés pour notre application.
Conclusion
Notre application est développée pour le compte de FORINFO. Elle est composée
de deux modules en relation avec les ressources humaines à savoir la gestion de la
formation et des appels à candidature. Elle est destinée aux administrations publiques
et elle est réalisée selon l’architecture 3-tiers et le modèle MVC.
13
14
CHAPITRE 2 : Analyse des besoins
Introduction........................................................... 15
2.1 Analyse de l’existant....................................... 15
2.1.1 GIPE...................................................... 15
2.1.2 Gestion des appels à candidatures...... 17
2.1.3 Gestion de la formation....................... 18
2.2 Spécification des besoins................................ 21
2.2.1 Cahier des charges............................... 21
2.2.2 Assurance qualité................................. 23
Conclusion............................................................. 25
15
Introduction
Dans ce chapitre nous présentons l’analyse de l’existant. Cette analyse permet
d’une part de comprendre les procédures utilisées par les ministères et d’autre part de
cerner les fonctionnalités à intégrer dans notre application.
Ensuite nous définissons le cahier de charges de notre projet qui contiendra les
objectifs de l’application et l’assurance qualité.
2.1 Analyse de l’existant

Notre existant est divisé en deux types : logiciel qui est la GIPE, et procédural qui
concerne la gestion des appels à candidatures et de la formation.
2.1.1 GIPE
Ce progiciel est destiné aux administrations publiques, il est développé par le CED
(Centre des Engagements et des Dépenses) en 1995 en utilisant Oracle Developper
2000 et une base de donnée Oracle ou SQLServer selon le choix de l’utilisateur. Il est
composé de 3 volets :
 Administration
 Paramétrage
 Utilisateur
Le volet qui nous intéresse est celui de l’administration. Il est constitué de 5 modules :
Dernière situation, loi cadre, gestion des actes, codification et GRH. Mais nous avons
axé notre étude uniquement sur les trois premiers modules.
Le module « dernière situation » est composé de trois menus :
 Dernière situation de l’agent : Ce menu offre un certain nombre de fonctionnalités
comme le chargement des données du CED, le contrôle des données chargées, la
mise à jour de la dernière situation (Services antérieures, Interruptions, Conjoints,
Enfants, Diplômes, Indemnisation...) et la visualisation de l’historique de l’agent.
16
 Dernière situation des postes budgétaires : Ce menu donne la possibilité

d’effectuer les opérations de mise à jour de la situation et des mouvements des
postes budgétaires.
 Edition multicritère : Ce menu permet d’effectuer des recherches multicritères
sur la situation de l’agent et sur les postes budgétaires. Le résultat de ces
recherches peut être imprimé sous un format paramétré.
Le module « actes de gestion » offre les fonctionnalités suivantes :
 Préparation des actes de gestion (avec une recherche des actes en préparation et
un regroupement des mouvements dans une même référence d’arrêté).
 Traitement de plus de 150 types de mouvements administratifs et familiaux
groupés dans une trentaines de classes de procédures types. L’automatisation
couvre tout le processus de traitement des actes de gestion. En effet, de chaque
état de l’acte on peut revenir à l’état précédent, en annulant automatiquement
les traitements déjà effectués. Les états possibles d’un acte sont : préparé,
proposé, validé, signé, visé (ou bien rejeté).
 Signature des actes (on peut annuler l’acte et donc son état devient préparé, et
on peut annuler sa signature et dans ce cas il devient dans un état validé et non
signé).
 Envoi des actes au CED dans un support magnétique avec Bordereau.
 Prise en charge des réponses du CED (actes visés ou rejetés).
Le module de gestion de la loi cadre intègre tous les aspects de traitement des
postes budgétaires : la préparation de la loi cadre et des errata, sa prise en charge
automatique, son individualisation ainsi que le suivi de la situation des postes
budgétaires.
Les informations relatives aux postes budgétaires sont par conséquent mises à jour
de deux manières : soit par l'individualisation des mouvements de la loi cadre qui agit
sur le type du poste et l'entité à laquelle il appartient, soit par le visa des actes de
gestion qui a un impact sur la situation des postes budgétaires.
17
Les fonctionnalités de ce module peuvent être résumés comme suit :

 Préparation des errata sur les postes
 Envoi et validation des errata (l’état d’un erratum est soit préparé, généré,
validé, utilisé par un acte, ou régularisé par une loi cadre).
 Consultation de la loi cadre.
 Edition de la loi cadre.
 Individualisation de la loi cadre (pour rendre les errata régularisés).
Ceci étant pour l’existant logiciel, en ce qui concerne l’existant procédural nous
avons eu des entretiens avec un certain nombre d’administrations (le ministère
d’agriculture, le ministère de l’habitat) pour collecter les informations et les documents
nécessaires. Nous avons remarqué que leurs besoins se situent au niveau de la gestion
des appels à candidatures et la gestion de la formation. Dans ce qui suit nous
présentons un compte rendu de ces réunions.
2.1.2 Gestion des appels à candidatures

Les administrations publiques ou semi-publiques peuvent proposer à leur personnel
des postes dites à pourvoir. Ces postes sont soit récemment vacants, soit nouvellement
créés. La direction des ressources humaines (DRH) lance un appel à candidature
concernant chaque poste. Ce dernier requiert un certain nombre de compétences et de
qualifications. Les agents qui estiment avoir ces qualités peuvent s’inscrire dans cet
appel et c’est la DRH qui choisi celui qui va être affecté au poste.
Dans ce qui suit, nous présentons en détail le déroulement de cette procédure :
 Les chefs de département envoient les appels à candidatures à la DRH.

 Ces appels sont soit validés par la direction de ressources humaines, soit rejetés.
Dans le deuxième cas les chefs de départements sont informés par des lettres.
18
 Les candidats peuvent s’inscrire dans n’importe quel appel de candidature

validé par la DRH.
 La DRH examine les inscriptions, et envoie des lettres de réponses aux
candidats. Ces derniers peuvent être soit acceptés pour passer un entretien, ou
non acceptés. Dans ce cas la DRH spécifie dans la lettre la raison pour laquelle
ils n’ont pas été admis (dossier incomplet ou conditions non remplies…).
 La DRH organise un planning qui contient la date, l’heure, le lieu et le comité
de chaque entretien. Les différents membres du comité sont ensuite informés
par des lettres de convocation.
 Les candidats passent les entretiens. Ceux qui sont retenus sont avisés par des
lettres d’acceptation.
2.1.3 Gestion de la formation

Toute administration publique ou semi-publique assure des formations dans des
thèmes spécifiques aux besoins en formation de son personnel.
Ces formations peuvent être assurées par des animateurs internes, qui font partie du
personnel de la direction ou par des animateurs externes. Dans ce dernier cas la
formation sera assurée par un prestataire, ou un fournisseur de service : une société.
C’est le service de la formation qui se charge de préparer les formations, les plannings
et consolider avec le fournisseur ou les animateurs internes.
Ce service communique l’information concernant la formation, son thème, sa durée et
le nombre des participants aux autres services.
Ensuite il collecte les besoins en formation des différents services, et détermine la
possibilité et le nombre de places à accorder pour chaque service ; tout en ayant la
possibilité de notifier ces services des décisions prises dans ce cadre.
19
 Les marchés de formation

La direction traite un ou plusieurs marchés avec un ou plusieurs fournisseurs afin
d’assurer à son personnel des formations dans des thèmes différents. Un marché peut
comprendre la formation d’un ou plusieurs cycles concernant un ou plusieurs thèmes.
Une fois le marché est soumis avec un prestataire, ce dernier est tenu d’exécuter le
marché par phase et selon un planning.
 Les formations
Les sessions sont organisées en cycles de formation. Chaque cycle concerne un thème
à une période calculée en nombre de jours et pour un nombre déterminé de groupes.
Chaque cycle est exécuté sur une ou plusieurs sessions. Chaque session concerne un
groupe avec un nombre de personnes, à une période et sera effectué dans un lieu de
formation.
 Les lieux de formation

Les formations peuvent se dérouler dans des locaux assurés par le fournisseur ou dans
des établissements / des centres de formation, désignés par le service Formation. Ces
centres bénéficient de délégation du budget.
 Les animateurs
Dans le cas des animateurs internes eux même font partie du personnel du ministère.
Le service des formations les désigne pour des thèmes spécifiques. Ces animateurs
bénéficieront d’un budget de vacation.
Quand les formations sont assurées par un fournisseur ou une société de formation, les
animateurs désignés par le fournisseur seront payés par le fournisseur.
20
 Les participants
Les participants sont les personnes qui bénéficieront des formations. Ils font partie du
personnel du ministère, ils peuvent provenir des différentes directions, des différentes
divisions et des différents services.
Quand le service de formation organise des cycles de formation, il envoie des
formulaires / canevas aux différentes directions leur demandant de désigner des
personnes pour bénéficier de la formation d’un thème spécifique.
Au niveau des directions, les canevas seront remplis par les informations suivantes :
noms, services et divisions des personnes. Puis ces canevas seront retournés au service
formation.
Le service de formation organise les participants dans des groupes et affecte ces
groupes aux cycles de formation dont ils vont bénéficier.
21
2.2 Spécification des besoins
L’analyse de la GIPE nous permet de mieux comprendre le processus de gestion du

personnel des administrations publiques. Son point fort est qu’elle contient toutes les
informations sur les agents et les postes budgétaires stockées dans la base de données.
Son point faible est qu’elle ne permet pas aux ministères de faire de la GRH.
Notre objectif est d’exploiter ce point fort pour la réalisation de la partie manquante de
la GIPE.
L’analyse des procédures mises en œuvres dans les ministères concernant la gestion
des appels à candidatures et la gestion de la formation nous offre une base sur laquelle
nous concevons notre application.
Dans cette partie nous allons fixer les objectifs de notre application, et élaborer le
modèle de développement ainsi que les critères d’assurance qualité.
2.2.1 Cahier des charges

Notre projet est composé de deux modules : les appels à candidatures et la
formation. Ces modules ont pour objectif commun de :
 Réduire les insuffisances du système manuel et traditionnel de gestion de
ressources humaines.
 Etablir un système de normalisation et de codification entre l’ensemble des
intervenants dans notre application.
 Réaliser une application orientée WEB, qui permet à tout ceux qui sont
concerné par l’information d’y accéder.
 Réaliser une application sécurisée, en utilisant un système d’authentification
pour chaque département, et chaque employé.
 Réaliser une application qui respecte l’architecture 3-tiers, à savoir le tiers
concernant le client, le tiers concernant le serveur Web et le tiers concernant le
serveur base de données.
22
 Réaliser une application qui respecte le modèle MVC, c'est-à-dire une

application qui sépare entre la couche logique métier ou « Modèle », la couche
présentation ou « Vue » et la couche traitement ou « contrôle ».
 Permettre d’avoir des éditions et d’imprimer les lettres.
 Permettre d’envoyer des emails.
En plus des objectifs communs, chaque module doit satisfaire des fonctionnalités
spécifiques.
En ce qui concerne le module des appels à candidatures, il doit permettre :
 Aux chefs de départements de saisir les appels à candidatures sur notre site
Web.
 A la DRH de visualiser les appels saisis et de les valider.
 Aux employés de consulter les appels validés et de s’inscrire.
 A la DRH de visualiser les inscriptions et de prendre la décision convenable
(accepté pour entretien, condition non remplies, dossier incomplet…).
 A la DRH de générer le contenu des lettres et des emails automatiquement
selon la nature de la décision.
 A la DRH de modifier ce contenu avant l’envoi.
 A la DRH d’affecter au poste celui qui le mérite le plus, les autres sont
automatiquement non admis. Et ceci est effectué pour chaque appel.
En ce qui concerne le module de la formation, il doit permettre :

 L’automatisation de la procédure des recueils des besoins.
 L’automatisation de la procédure de gestion des formations lancées.
 L’automatisation de la procédure de déroulement des sessions par la DRH.
 L’automatisation de la procédure d’évaluation.
23
2.2.2 Assurance qualité

L’assurance qualité dans notre application se manifeste dans la mise en œuvre d’un
ensemble approprié de dispositions préétablies et systématiques destinées à donner
confiance en l’obtention de la qualité requise. Le système d’assurance qualité suivi
dans notre projet se présente comme suit :
 Qualité du service : à travers les procédures mises en places dans notre
application sous forme de services, par exemple le service des inscriptions,
celui des recueils des besoins, la génération automatique des sessions et des
groupes pour chaque programme. Ces services ont pour objectifs de faciliter la
tâche à l’utilisateur et non pas à la compliquer. En plus de cela, elle permet en
cas de blocage d’avoir des solutions de recours par exemples les e-mails et les
lettres de relance.
 Qualité du processus : elle se manifeste dans la gestion du projet depuis la
phase de spécification jusqu’au développement et mise en œuvre de
l’application. Ainsi, nous avons accordé beaucoup d’importance à la conduite
du projet. Ceci à travers la planification des tâches à réaliser avec une
estimation de l’effort de chaque étape en jour/homme. En effet, nous avons
donné beaucoup de temps à la compréhension de la GIPE et la GRH, et nous
avons tenu à organiser les tâches entre nous avec une spécification du contenu
de chaque tâche. En ce qui concerne la production de notre application, elle a
été faite en respectant le modèle incrémental, autrement dit les deux modules
ont été conçu ensemble mais la conception détaillée et la réalisation ont été fait
séquentiellement. Et enfin, il ne faut pas oublier de citer le pilotage et
l’encadrement qui ont été assuré par nos deux encadrant.
 Qualité du produit : À partir de la collecte des informations depuis les
responsables des administrations publiques, nous avons dégagé les besoins et
nous les avons reformulé sous forme de facteurs de qualité intervenant dans
notre application. Ces facteurs différent suivant le point de vue utilisateur ou
développeur.
24
En ce qui concerne l’utilisateur, il a besoin de :

 La conformité : c'est-à-dire l’aptitude à répondre aux spécifications. Notre
application reflète parfaitement les besoins spécifiés au préalable par les
administrations publiques, ceci étant assuré par l’encadrement permanent des
responsables de FORINFO.
 La fiabilité : c'est-à-dire le degré auquel le programme exécute les fonctions
demandés avec la précision requise. Dans notre application, la fiabilité est
assurée par les algorithmes de calculs qui permettent de générer le CPS, les
sessions et les groupes. Elle est assurée également par l’annulation des
transactions déjà effectuées au préalable et par l’envoi des lettres et des e-mails
au cas où la procédure se bloque.
 L’efficacité : c'est-à-dire l’aptitude du programme à s’exécuter avec une
utilisation optimale des ressources. Cela se manifeste clairement dans la
procédure de la pagination. En effet, dans notre application chaque page
contient 5 enregistrements, et dans le cas où la table contient plus, la servlet
charge uniquement ces 5 enregistrements dans la première page, et si on clique
sur la page suivante, la servlet charge les 5 enregistrements suivants et ainsi de
suite jusqu’à la dernière page. Ceci permet d’optimiser le temps de chargement
des données.
 L’intégrité : c'est-à-dire le degré de contrôle d’accès au logiciel par des
personnes non autorisés. Ceci est assuré grâce à une authentification de la DRH
et une autre pour départements. Les agents se connectent en utilisant leur
numéro DRPP et leur code CIN.
 La maniabilité : c'est-à-dire la facilité d’utilisation. Notre application vise, avant
tout, de simplifier les tâches aux utilisateurs c’est pour cela qu’ils sont guidés
tout au long de leur utilisation de notre logiciel en spécifiant un espace DRH et
espace département.
25
En ce qui concerne le développeur, il demande :

 La portabilité : c’est à dire la capacité de s’exécuter dans n’importe quel
système d’exploitation. Ceci est réalisé grâce au langage JAVA de
l’environnement J2EE.
 La couplabilité : c'est-à-dire la capacité d’être intégrée avec d’autres
applications existantes. La base de donnée utilisée dans notre application
possède la faculté d’être intégrée avec celle de la GIPE en utilisant les tables
de correspondance, comme elle peut être utilisée toute seule ceci dépend des
besoins du client.
 La réutilisabilité et la maintenabilité : Grâce au standard MVC, nous avons
réalisé des classes qui assurent les fonctionnalités de base comme l’ajout, la
modification, la suppression et la recherche. Ces classes peuvent être utilisées
indépendamment de la table ou de la procédure et à n’importe quel moment. En
plus de cela nous pouvons facilement modifier ces classes et les faire évoluer.
Conclusion
Notre existant est divisé en deux types : logiciel qui est la GIPE, et procédural qui
concerne la gestion des appels à candidatures et de la formation. L’analyse de cet
existant permet d’abord de mieux comprendre les procédures utilisées par les
ministères et par la suite de cerner les fonctionnalités à intégrer dans les deux modules
de notre application.
Ces modules, selon le cahier de charge, doivent être développés sur le Web en utilisant
la technologie J2EE. Ils doivent aussi respecter l’architecture 3-tiers et le standard
MVC. En plus, les deux modules doivent respecter un certain nombre de critères
assurance qualité tels que la portabilité, la maintenabilité et la réutilisabilité.
26
27
CHAPITRE 3 : Conception des modules
Introduction................................................................ 27
3.1 Conception des traitements................................. 27
3.1.1 Module des appels à candidatures.............. 27
3.1.2 Module de la formation............................... 31
3.2 Conception de la base de données...................... 36
3.2.1 Le dictionnaire des données........................ 36
3.2.2 Les règles de gestion.................................... 37
3.2.3 Modèle conceptuel de données................... 38
3.2.4 Modèle physique de données...................... 39
Conclusion.................................................................. 40
28
Introduction
Dans ce chapitre nous présentons la conception des deux modules de notre
application à savoir : les appels à candidatures et la formation. Cette conception est
axée sur deux parties : traitements et données. Après une collecte de données
manipulées au niveau du système étudié, nous détaillons les différents schémas
conceptuels associés à chacun des deux modules.
3.1 Conception des traitements

Après avoir présenté les deux modules dans la section 2.1, nous passons
maintenant à la modélisation des traitements par les diagrammes d’UML. Il s’agit du
diagramme des cas d’utilisation, des diagrammes de séquence et des diagrammes de
collaboration.
3.1.1 Module des appels à candidatures
Cas d’utilisation des appels à candidatures

Ce diagramme représente le dialogue entre les acteurs et le système de manière
abstraite. Dans notre cas, il existe 3 acteurs à savoir la DRH, le chef de département et
l’agent.
Les cas d’utilisation intégrés dans ce modèle se présentent comme dans la figure 3.1 :
29
30
Traitement des entretiens

<<utilise>>
<<utilise>>
Traitement des inscriptions
<<utilise>>
<<utilise>>
<<utilise>> identification
Informations sur l'appel
Traitement des appels
DRH <<utilise>> <<utilise>>
statistiques
historique
Departement
inscription
Agent
Figure 3.1 : Diagramme des cas d’utilisation des appels à candidatures
La figure 3.1 présente les cas d’utilisations suivants :

 Informations sur les appels : Les chefs de départements saisissent les
informations sur les appels à candidature. Ils visualisent aussi le résultat des
appels saisis.
 Traitement des appels : La direction des ressources humaines examine les appels
saisis par les différents départements et les valide.
 Inscription : les appels étant validés. Les agents et les chefs de départements
peuvent ainsi s’inscrire.
 Traitement des inscriptions : La DRH visualise les inscriptions, et détermine les
candidats choisis pour passer les entretiens.
 Traitement des entretiens : La DRH se charge de saisir les informations sur les
entretiens. Après le déroulement de ces entretiens la DRH choisi le candidat
admis pour le poste, les autres sont automatiquement non admis.
31
 Identification : chaque cas d’utilisation nécessite une identification : login et mot

de passe dans le cas de la DRH et des chefs de départements, DRPP et CIN dans
le cas de l’agent.
Diagrammes de séquence
Un diagramme de séquence montre les interactions qui surviennent dans une
séquence de temps d’un scénario donné. Nous nous limitons dans cette présentation
aux deux scénarios suivants : « informations sur les appels à candidature », et
« inscription ».
Identification Appel à Inscription

candidature
: Departement
S'identifier
Valider
Créer nouveau appel
choisir un appel
demander les résultats
afficher les résultats
Figure 3.2 : Diagramme de séquence pour le scénario « informations sur les appels »
32
Après authentification du chef de département, ce dernier peut créer un nouvel

appel à candidature, il peut aussi choisir un appel pour visualiser le résultat des
inscriptions.
Identification Appels à Inscription

: Agent candidature
Entrer DRPP
Valider
Selectionner l'appel
S'inscrire
Voir l'état d'inscription
Figure 3.3 : Diagramme de séquence pour le scénario « inscription »
Dans ce scénario, l’agent se connecte, sélectionne un appel à candidature, et s’inscrit.

Cette inscription se fait par chargement des informations depuis la base de données
GIPEORD.
L’agent peut aussi se connecter pour consulter les résultats d’une inscription déjà
établie.
33
Diagramme de collaboration
Les diagrammes de collaboration montrent les flots de données entre les objets
ainsi que les liens qui existent entre ces objets. Nous allons nous intéresser au scénario
du « traitement des inscriptions » par la DRH.
Valider
1: S'identifier
Identification 2: Choisir l'appel
: DRH Appels à
candidatures
3: Consulter
Examiner
Inscription
4: Envoyer Emails et
lettres de réponses
: Agent
Figure 3.4 : Diagramme de collaboration pour le scénario «traitement des inscriptions»
Dans ce scénario, La DRH se connecte, sélectionne un appel à candidature, et

consulte les inscriptions. Ensuite, elle choisi les personnes admises pour un entretien,
les autres ayant des conditions non remplies ou bien des dossiers incomplets.
Enfin, la DRH se charge d’envoyer à tous ces agents des emails et des lettres selon la
décision prise.
3.1.2 Module de la formation
34
Cas d’utilisation de la gestion de la formation

Dans ce module nous avons relevé aussi trois acteurs à savoir la DRH, le chef de
département et l’agent.
Les cas d’utilisation intégrés dans ce modèle se présentent comme sur la figure 3.5.
<<utilise>>
Annonce des besoins

<<utilise>>
<<utilise>>
Identification_form
<<utilise>>
Analyse des pré_inscriptions <<utilise>>
MAJ des inscriptions

DRH
<<utilise>>
Annonce des thèmes <<utilise>>
Définition des besoins
MAJ du planning
Pré_inscription
Agent Département
Figure 3.5 : Diagramme des cas d’utilisation de la formation
Passons maintenant à la description de chaque cas d’utilisation :

 Annonce des besoins : la DRH annonce un nouveau programme et saisi ses
modules ainsi que les thèmes inclus dans chaque module.
 Pré-inscription : une fois le besoin est identifié les agents et les départements
peuvent effectuer des pré-inscriptions dans les thèmes proposés dans le cadre
d’un programme.
 Analyse des pré-inscriptions : la DRH génère un CPS dans lequel elle effectue
une synthèse des pré-inscriptions effectuées.
35
 Annonce des thèmes : La DRH annonce la liste des thèmes retenus dans un
marché particulier et fixe le nombre de groupes autorisé pour chaque
département.
 Mise à jour des inscriptions : chaque département détermine la liste définitive des
candidats et l’envoie à la DRH.
36
 Mise à jour du planning : la DRH établit un planning dans lequel elle organise les
sessions et les personnes participantes dans chaque session.
Diagrammes de séquence
Nous prenons l’exemple des scénarios suivants : «définition des besoins», et
«analyse des pré-inscriptions».
Identification_form Programme Module Thème Inscription

: Agent
S'identifier
Valider
choisir un programme
Voir les modules
Selectionner un thème
S'inscrire
Figure 3.6 : Diagramme de séquence pour le scénario «définition des besoins»
Après authentification de l’agent, il choisi un programme et consulte la liste des

thèmes inclus dans ce programme. Ensuite il sélectionne un thème pour s’inscrire.
37
Identification_form Programme Thème Inscription CPS

: DRH
S'identifier
Valider
Choisir un programme
Voir les thèmes
afficher les inscrits et le nombre de groupes
Génerer le CPS
Modifier le nombre de groupes
Figure 3.7 : Diagramme de séquence pour le scénario «analyse des pré-inscriptions»
Dans ce scénario, la DRH se connecte, choisi un programme et consulte les

inscriptions. Ensuite elle génère le CPS pour modifier le nombre de groupes.
Diagramme de collaboration
Dans notre cas nous allons nous intéressé au scénario : « annonce des besoins » par
la DRH.
38
Valider
1: S'identifier
Identification_form 2: Créer nouveau programme
: DRH
Programme
3: Saisir les modules
Module
Thème
4: Saisir les thèmes
: Département
5: Envoi des emails et des lettres
Figure 3.8 : Diagramme de collaboration pour le scénario «annonce des besoins »
Dans ce scénario, La DRH se connecte pour annoncer ses besoins en matière de

formation. Pour faire ceci, elle crée d’abord un nouveau programme, saisit ses
modules ainsi que les thèmes inclus dans chaque module.
Ensuite, la DRH se charge d’envoyer des e-mails et des lettres de notification aux
différents départements.
39
3.2 Conception de la base de données

Pour la conception de la base de données, nous commençons par établir le
dictionnaire de données, ensuite nous listons les règles de gestions pour aboutir enfin
aux modèles conceptuels et physiques des données.
3.2.1 Le dictionnaire des données

Dans le but d’établir un modèle de données, il est nécessaire de faire un inventaire
complet des données qui entrent en jeu.
Le tableau de la figure 3.9 présente un extrait du dictionnaire de données, il est décrit
dans son intégrité dans l’annexe 1.
Nom Libellé Type Utilisé par

RefPro Référence du programme I Programme
DesThe Désignation du thème T Thème
RefAge Référence de l’agent I Agent
DesMod Désignation du module T Module
DatEch Date échéance D Programme
DatDeb Date début D Session
DatFin Date fin D Session
LieSes Lieu Session T Session
RefMar Référence du marché I Marché
DatNot Date de notification D Marché
DelMar Délai du marché I Marché
RefIns Référence d’inscription I Inscription
EtaIns Etat d‘inscription T Inscription
ResDep Responsable département T Département
Figure 3.9 : Extrait du dictionnaire de données
NB : Tous les champs sont non calculables
40
3.2.2 Les règles de gestion
Une fois le dictionnaire de données établi, nous pouvons mettre au point le Modèle
conceptuel de données suivant les spécifications de la méthode MERISE. Ceci étant
dit, la liste des règles de gestion s’avère d’une importance majeure :
 Un animateur peut assurer des formations en un ou plusieurs thèmes.

 Un programme peut être exécuté dans le cadre de zéro ou plusieurs marchés.
 Un marché est exécuté par un et un seul prestataire.
 Un marché peut concerner un ou plusieurs thèmes.
 Un marché est bénéfique pour un ou plusieurs groupes.
 Un groupe appartient à un et un seul marché.
 Un groupe peut bénéficier de la formation en un ou plusieurs thèmes dans le
cadre d’un marché, ce qui correspond à une ou plusieurs sessions.
 Une session correspond à la formation d’un et d’un seul groupe en un et un seul
thème.
 Une session se déroulera dans un et un seul local (lieu de formation).
 Une session est assurée par un et un seul animateur.
 Un participant peut être affecté à un ou plusieurs groupes à condition que les
différents groupes ne disposent pas de thèmes communs.
 Un participant a un et un seul grade.
 Un participant appartient à une et une seule catégorie (fonctions).
 Un participant est affecté à un et un seul département.
 A un département peut être affecté un ou plusieurs participants.
 Une catégorie peut avoir un besoin en formation en un ou plusieurs thèmes.
 A une session correspond une et une seule évaluation.
 Un participant peut faire objet d’une et une seule évaluation de son assiduité
dans le cadre d’une session.
 Un participant peut acquérir des compétences en un ou plusieurs thèmes.
41
 Une demande d’inscription ne concerne qu’un seul participant et en un seul

thème et dans le cadre d’un programme.
 Un participant peut avoir zéro ou plusieurs demandes d’inscription.
3.2.3 Modèle conceptuel de données

Dans la figure 3.10 nous présentons le MCD des deux modules à savoir : les appels
à candidatures et la formation. Les entités et les associations représentées prennent en
compte l’ensemble des informations contenues dans le dictionnaire de données. Par
ailleurs, les cardinalités sont justifiées par les règles de gestion.
42
Marché 1,n
1,n
RefMar Module
ObjMar RefMod
DatNot Contient DesMod
Prestataire DelMar NbrMod
1,n
RefPre 1,n PriMod
NomPre
1,1
AdrPre
Thème_Mar Theme
VilPre 1,n
1,1
TelPre AniThe RefThe
1,1
FaxPre IntGrh DesThe
EmaPre 1,n ConThe
correspond
PubThe
Detail_pro 1,nObjThe
NbrDem
NbrRet 1,n
1,n 1,n PriThe 0,n
NbrGro Session
Programme DurThe
RefSes
RefPro NbrPer Avoir 1,1
Des_Effectif LieSes
ObjPro
DatDeb
NbrPar DatPro
0,n DatFin
Inscription_form 1,n
1,n EtaIns
Departement Date
1,n
RefDep Date 0,n
DesDep Formation_groupe
Agent
EmaDep
RefAge
FaxDep
CinAge
ResDep 0,n
1,n NomAge
PreAge
FonAge
Appartient GraAge
1,1
TelAge
VilAge
AdrAge
1,n EmaAge 1,n
Entretien
RefEnt
ComEnt
Inscription_appel
DatEnt
HerEnt DatIns
Appel de candidature ResIns
ResEnt
RefApl 0,n
RefPos
0,n
DatEch
PapIns
DatApl
EtaApl
ComPos
QuaPos
Figure 3.10 : MCD des deux modules : formation et appels à candidatures
3.2.4 Modèle physique de données

D’après le MCD présenté auparavant nous avons généré le modèle physique de
données associé tout en respectant les règles de transformation d’un MCD en MPD.
43
MARCHE
REFMAR int MODULE
OBJMAR text REFMOD int
DATNOT datetime DESMOD text
DELMAR int REFMOD = REFMOD NBRMOD int
PRESTATAIRE PRIMOD int
THEME_MAR
REFPRE int
REFTHE int
NOMPRE text
ANITHE text REFTHE = REFTHE
ADRPRE text
INTGRH text
VILPRE text THEME
TELPRE int REFPRE = REFPRE
CORRESPOND REFTHE int
FAXPRE int REFMOD int
REFPRE int
EMAPRE text DESTHE text
REFPRO int
DETAIL_PRO
REFTHE = REFTHE CONTHE text REFTHE = REFTHE
REFPRO int AVOIR
PUBTHE text
REFTHE int REFTHE = REFTHEOBJTHE text REFTHE int
REFPRO = REFPRO
NBRDEM int REFSES int
DES_EFFECTIF NBRRET int REFSES = REFSES
REFPRO = REFPRO
REFDEP text PRITHE int SESSION
REFTHE int NBRGRO int REFSES int
PROGRAMME DURTHE int REFTHE = REFTHE
NBRPAR int LIESES text
REFPRO int NBRPER int DATDEB datetime
OBJPRO text
REFPRO = REFPRO DATFIN datetime
DATPRO datetime INSCRIPTION_FORM
REFTHE int
REFAGE int
REFDEP = REFDEP DATE = DATE REFPRO int
DATE datetime
DATE
ETAINS text
DATE datetime REFSES = REFSES
REFAGE = REFAGE
AGENT
REFAGE int
DEPARTEMENT REFDEP text
REFDEP text REFAGE = REFAGE FORMATION_GROUPE
CINAGE text
DESDEP text NOMAGE text REFSES int
EMADEP text PREAGE text REFAGE int
FAXDEP int FONAGE text
RESDEP text REFDEP = REFDEP
GRAAGE text
TELAGE int
VILAGE text
ADRAGE text
EMAAGE text
REFAGE = REFAGE
REFAGE = REFAGE
APPEL_DE_CANDIDATURE
ENTRETIEN REFAPL int
INSCRIPTION_APPEL
REFAPL int REFPOS text
DATECH datetime REFAPL = REFAPL REFAPL int
REFAGE int
REFENT int PAPINS text REFAGE int
REFAPL = REFAPL DATINS timestamp
COMENT text DATAPL timestamp
ETAAPL bit RESINS bit
DATENT datetime
HERENT datetime COMPOS text
RESENT bit QUAPOS text
Figure 3.11 : MPD des deux modules : formation et appels à candidature
Conclusion
44
Dans ce chapitre nous avons présenté la conception des traitements des deux
modules du projet à travers les diagrammes d’UML. Le diagramme des cas
d’utilisation contient trois acteurs principaux qui sont : la DRH, le chef de département
et le candidat.
Nous avons également présenté la persistance de la base de données physique en
utilisant le modèle conceptuel de données. Ce modèle tourne autour d’une entité
principale qui est la table Agent de la base de données GIPE.
Le chapitre suivant sera consacré à la description des différentes phases de la mise
en œuvre de l’application.
45
CHAPITRE 4 : Réalisation de l’application
Introduction.............................................................................. 42
4.1 Environnement technique................................................. 42
4.1.1 Architecture choisie et outils d’implémentation....... 42
4.1.2 Modèle MVC ............................................................... 44
4.2 Réalisation du module des appels à candidatures........... 46
4.3 Réalisation du module de la formation............................ 57
4.4 Tests et mise au point........................................................ 65
Conclusion................................................................................ 65
46
Introduction
Les résultats de développements des deux modules de l’application seront exposés
dans ce chapitre. Nous y trouverons une présentation de l’environnement technique
utilisé, des échantillons des écrans de saisie et quelques états de sortie.
4.1 Environnement technique
Dans cette présentation technique, nous passons en revue l’ensemble des

technologies et langages de programmation qui ont permis la mise en œuvre de notre
application. La présentation prendra en compte les deux modules précédemment
conçus.
4.1.1 Architecture choisie et outils d’implémentation
47
Figure 4.1 : Architecture 3-tiers
L’architecture 3-tiers (voir figure 4.1) permet de séparer les objets d’une
application Web sur trois parties :
- Serveur d’applications : pour effectuer les traitements de l’application
- Serveur de bases de données : pour stocker et lire les données
- Browser : pour permettre au client d’accéder à l’application
Cette architecture présente plusieurs caractéristiques techniques. En effet, elle

utilise le Transactionnel objet, optimise les ressources systèmes (connexion réseau,
SGBD…etc.), et permet de gérer d’une manière fixe la sécurité et le contrôle d'accès à
chaque composant. L’architecture 3-tiers assure la sécurité de communication
Client/Serveur par le protocole SSL, elle permet l'accès aux bases de données par des
objets métiers et donne aussi à l’utilisateur la possibilité d'implémenter une sécurité
plus fine aux niveaux des objets métiers : sécurité programmatique (objet de Contexte
MTS).
Concernant les outils d’implémentation, nous avons utilisé :

Tomcat comme serveur d’applications Web
Ce serveur comporte deux avantages (voir Annexe2) :
- Il est compatible J2EE ce qui signifie que l’ensemble des développements
réalisés pour Tomcat pourront être porté sur des serveurs d’applications
d’entreprise.
- Les développements se font en java ce qui assure un niveau élevé de
portabilité : il sera possible de déployer le code qui tourne sur Tomcat sur la
plupart des systèmes d’exploitations (Linux, AS400, Solaris, HPUX, AIX,
Windows, Netware, Mac OS X, OS390…). Ce haut niveau de portabilité
favorise la réutilisation.
Oracle comme serveur de bases de données
Ce choix nous a été imposé du fait que notre base de données doit utiliser des
tables contenues dans une base de données existante implémentée avec Oracle.
48
JDBC pour la connexion entre l’application et la base de données

JDBC (Java Data Base Connectivity) est une API fournie avec Java (depuis sa
version 1.1) qui a été développée de telle façon à permettre à un programme de se
connecter à n'importe quelle base de données en utilisant la même syntaxe, c'est à
dire que l'API JDBC est indépendante du SGBD. De plus, JDBC bénéficie des
avantages de Java, dont la portabilité du code, ce qui lui vaut en plus d'être
indépendant de la base de données, d'être indépendant de la plate-forme sur
laquelle elle s'exécute.
4.1.2 Modèle MVC
Le modèle MVC (Modèle Vue Contrôleur) permet de séparer entre les trois
couches de base de n’importe quelle application Web à savoir : la couche présentation
(ou Vue), la couche métier (ou Modèle) et la couche application (ou Contrôleur).
Pour implémenter ce modèle nous avons utilisé les technologies JSP et Servlets
offertes par la plate-forme J2EE (Annexe2). La figure 4.2 présente le schéma
d’implémentation de ce modèle :
49
Figure 4.2 : Schéma d’implémentation du modèle MVC
Voici une description des différentes étapes présentées dans la figure 4.2 :
1. Un navigateur lance une requête sur un serveur d'applications Web. La réception de

cette requête est assurée par une servlet.
2. La servlet soustraite la partie traitement de cette requête au modèle. Le modèle est

assuré par un ensemble de classes java. Ces classes java accèdent au système
d'information afin de récupérer les données requises par le traitement de la requête. La
plate-forme J2EE prévoit que le modèle respecte les spécifications EJB.
3. La servlet récupère du modèle les données qui devront être renvoyées à l'utilisateur
et les dépose dans un objet accessible par la JSP.
4. La servlet soustraite l'affichage des données en provenance du modèle à une JSP.
5. La JSP récupère les données en provenance de la servlet dans un objet.
6. La page HTML généré par la servlet est renvoyée au navigateur.
Le modèle MVC présente plusieurs avantages parmi lesquels nous trouvons :
50
- La maintenance : Elle devient plus aisée. En effet, une remise en cause de la charte
graphique de l'application n'aura pas d'impact sur l'application puisque seuls les pages
JSP seront à modifier (les parties servlet et modèle étant indépendant de la charte
graphique). De la même manière, une modification de la structure du système
d'information n'aura pas d'impact sur la partie infographie.
- La sécurité : Elle est garantie avec les servlets. En effet, une servlet ne produit pas
des erreurs fatales sur le serveur d'applications Web par des erreurs de manipulation
mémoire. Son code est compilé, il n'est donc pas possible, en utilisant des failles de
sécurité du serveur d'applications Web d'accéder à des informations sensibles
hébergées dans le code (contrairement aux cgi perl, aux scripts ASP, JSP ou PHP3).
En plus, une servlet ne souffre pas de l'interprétation de Meta caractères (comme les
" |, >, >>, ... " de perl) qui permettent aux " bidouilleurs " d'interagir avec le
gestionnaire de fichier.
4.2 Réalisation du module des appels à candidatures
4.2.1 Architecture du site

L’accès au site Web du module des appels à candidatures est assuré par 3 types
d’utilisateurs : les candidats, les chefs de département et la DRH. Les candidats
peuvent soit s’inscrire dans les appels à candidatures, ou voir les résultats d’une
inscription effectuée auparavant.
Les chefs de département quant à eux, peuvent saisir les appels à candidatures et voir
les admis. Tandis que la DRH valide les inscriptions, convoque les candidats pour les
entretiens et choisi ceux qui méritent plus le poste. La figure 4.3 permet d’expliciter
l’arborescence du site.
51
Figure 4.3 Architecture du site des appels à candidatures
4.2.2 Réalisation du module
Le module des appels à candidature offre aux administrations publiques un

service qui leur permet de choisir (après inscription et entretien) un employé pour lui
affecter un poste vacant ou nouvellement crée. Ce service est accédé par trois types
d’utilisateurs : Les chefs de départements, la DRH (Direction des Ressources
Humaines) et les candidats.
La première page Web qui s’affiche est destinée aux candidats. Ces derniers ne
peuvent accéder qu’aux deux premières fonctionnalités à savoir : « Appels à
candidature » et « Voir les résultats ». Tandis que les deux autres fonctionnalités :
52
« Espace DRH » et « Espace département » sont protégés avec un login et un mot de

passe.
Figure 4.4 : Page des appels à candidatures
Pour respecter le déroulement de la procédure, nous allons commencer par

l’explication des fonctionnalités offertes aux chefs des départements. Puis, nous allons
revenir à l’écran ci-dessus pour expliquer en détail les fonctionnalités des candidats.
Enfin, nous allons terminer avec la DRH.
 Chef de département :
Les chefs de départements ont la possibilité d’effectuer deux fonctionnalités à savoir :

- Saisir les demandes
- Voir les résultats
53
Ils peuvent ainsi visualiser les demandes qui ont été déjà saisies et validées par la
DRH. L’affichage de ces demandes se fait par pages, l’utilisateur peut passer d’une
page à une autre en utilisant soit les liens « suivant » et « précédent » soit le menu
déroulant « Aller à la page ».
Saisie des appels à candidatures
Figure 4.5 : Les appels à candidature saisis par le département
Et pour ajouter une nouvelle demande il suffit de cliquer sur le bouton « Ajouter »,
la figure 4.6 s’affiche :
54
Figure 4.6 : Saisie des appels à candidature par le département
Lorsque le chef de département fini la saisie des informations relatives à sa

demande, il doit valider afin que ces informations soient insérées dans la table
« appel_candidature » de la base de données. Il faut dire ici que certaines informations
sont générées automatiquement par l’application comme : la date de la demande, son
statut, sa référence et la direction.
Le chef de département doit savoir aussi le résultat de sa demande et les informations sur
les candidats qui ont été retenus par la DRH. Ceci est assuré par la deuxième fonctionnalité :
55
Figure 4.7 : Les résultats des appels à candidatures
Pour voir des informations sur le titulaire du poste correspondant à la demande

dont la référence est : 15 par exemple il suffit de la cocher et de cliquer ensuite sur le
bouton, la figure 4.8 s’affiche :
56
Figure 4.8 : Le titulaire du poste
 Les candidats :
Après la saisie de l’appel à candidature par le chef de département et sa validation

par la DRH, le candidat peut le visualiser dans son écran pour s’inscrire.
57
Figure 4.9 : S’inscrire dans un appel à candidature
Lorsque le candidat décide de s’inscrire dans un appel, il doit le cocher et

cliquer sur le bouton « s’inscrire », la page ci-dessous s’affiche.
Si l’administration concernée possède déjà une table existante qui contient les
informations relatives à ses employés. Alors le candidat peut charger ses informations
en entrant seulement le « N° DRPP » et le « CIN ». Dans ce cas l’application cherche
dans une table de correspondance les informations sur le candidat et les affiche, et
pour les zones de texte non affichées l’application donne la main au candidat pour les
saisir. Lorsque le formulaire est validé les informations sont automatiquement insérées
dans la table « inscription » de la base de données.
58
Figure 4.10 : Le formulaire d’inscription
Le menu résultat ressemble à celui du chef de département. Lorsque l’appel à

candidature auquel le candidat a été inscrit devienne attribué, il peut alors voir le
titulaire du poste et vérifier s’il a été retenu ou non.
 DRH :
La DRH peut valider les appels à candidatures, en plus de l’ajout, la modification

et la suppression de ces appels.
Elle a également la possibilité de consulter les différentes inscriptions pour les valider
ou voir les informations sur les entretiens.
59
Figure 4.11 : Visualisation des inscriptions
Après avoir cliqué sur le bouton « valider », la figure 4.12 apparaît. La DRH
peut alors soit refuser le candidat pour des conditions non remplies soit l’aviser dans
le cas de pièces incomplètes soit l’accepter pour entretien et dans ce cas elle doit
remplir le formulaire qui contient les informations sur cet entretien à savoir : la date,
l’heure, le lieu et la comité.
60
Figure 4.12 : La validation des inscriptions
Après l‘entretien, le candidat est soit accepté pour le poste ou bien non admis, et
dans les deux cas il sera avisé par des lettres et des emails.
61
Figure 4.13 : Aperçu d’un email
62
4.3 Réalisation du module de la formation
4.3.1 Architecture du site de la formation

A l’instar du premier module, l’accès au site Web du module de la formation est
assuré par 3 types d’utilisateurs : d’abord les agents qui peuvent consulter les modules,
les thèmes et les programmes proposés par la DRH et effectuer des inscriptions dans
des cycles de formations.
Les chefs de département consultent les inscriptions de leurs agents, les valident pour
un programme et les retiennent pour un marché. Ils peuvent aussi consulter les
plannings de sessions pour tous leurs agents. Tandis que la DRH saisit les thèmes, les
modules et les programmes, élabore un CPS, annonce les thèmes retenus dans des
marchés, désigne les effectifs par département et génère les sessions et les groupes
pour chaque marché. La figure ci-dessous permet d’expliciter l’arborescence du site :
63
Figure 4.14 Architecture du site de la formation
4.3.2 Réalisation du module de la formation

Le module de la formation offre aux administrations publiques un service qui leur
permet de gérer leurs cycles de formations. Ce module permet de gérer les procédures
du recueil des besoins, lancement des formations, déroulement des sessions, ainsi que
l’évaluation des formations. Dans ce qui suit, nous allons présenter quelques écrans de
l’application en suivant la logique de la procédure de la formation.
 Recueil des besoins

Au début la DRH annonce ses besoins en matière de thèmes groupés par module.
Ces thèmes sont décrits par des informations comme la désignation du thème, le
contenu, les objectifs, la durée et le public cible. La figure suivante montre la page qui
permet de mettre à jour ces thèmes :
64
Figure 4.15 Mise à jour des thèmes
Pour ajouter un nouveau thème il suffit de cliquer sur le bouton «Ajouter », un

formulaire de saisie qui ressemble à celui de la figure 4.16 s’affiche :
Figure 4.16 Ajout d’un nouveau thème
Lorsque les besoins en matière de thèmes de formations sont définis, la DRH peut
procéder alors à l’opération de lancement d’un nouveau programme. Cette opération
est réalisée avec un bouton «Ajouter » qui existe dans l’écran de mise à jour des
programmes (voir figure 4.17).
65
Figure 4.17 Mise à jour des programmes
66
Objet du programme : Formation en informatique
Figure 4.18 Mise à jour des thèmes d’un programme
Le bouton « Voir les thèmes » de la figure 4.17 mène vers une page qui permet de
visualiser et d’effectuer les opérations d’ajout, modification et suppression sur les
thèmes contenus dans un programme (voir figure 4.18).
Après le lancement du programme, la DRH doit imprimer des lettres et envoyer des
e-mails aux chefs de départements pour qu’ils commencent l’opération d’inscription
au programme. La figure 4.19 montre un exemple d’e-mail. Le numéro, la date de
lancement et la date d’échéance du programme ainsi que les e-mails des chefs des
départements sont générés automatiquement.
67
Figure 4.19 Exemple d’e-mail
La figure 4.20 montre un exemple de lettre de notification aux chefs de départements,

c’est un fichier PDF.
68
Figure 4.20 Exemple de lettre de notification
L’opération de l’inscription peut se faire soit par le candidat, soit par le chef de
département. Mais seules les inscriptions qui sont validées par les chefs de
départements qui sont envoyées à la DRH. Pour ajouter une inscription il faut choisir
un thème contenu dans un programme (voir figure 4.21) et remplir un formulaire de
saisie (voir figure 4.22). Le bouton « chargement » permet à l’agent de charger ses
informations à partir d’une base de données existante GIPE ou autre
.
69
Figure 4.21 Choix d’un thème
70
Figure 4.22 Formulaire d’inscription
Lorsque les inscriptions sont envoyées à la DRH. Cette dernière peut visualiser le CPS
généré (figure 4.23).
Figure 4.23 le cahier de prescription des spécifications (CPS)
71
72
4.4 Tests et mise au point
Pour garantir la crédibilité de notre application, nous avons effectué un certain

nombre de tests sur deux phases : d’abord des tests de chaque composant de
l’application (tests unitaires), ensuite des tests d’intégration ont été effectuées pour
mesurer l’interopérabilité entre ces composants.
4.4.1 Tests unitaires
Ces tests permettent de vérifier le bon fonctionnement de chacun des composants

de l’application. Ils consistent à suivre l’exécution de chacune de leurs fonctionnalités
et à vérifier que le résultat du test correspond bien aux spécifications de cahier de
charges. Dans notre cas, il est très important de vérifier, entre autres, l’envoi des
emails, les éditions et les résultats de la recherche multicritère.
4.4.2 Tests d’intégration
Après la phase des tests unitaires, les différents composants sont regroupés pour
constituer un système homogène, les tests d’intégration font l’objet de l’étape suivante
qui consiste à vérifier la cohérence entre les différents composants.
En effet, une erreur dans un composant ne doit pas entraîner une panne du système.
Par ailleurs, cette phase aide à mieux personnaliser les messages affichés par notre
application (erreurs, confirmation de modification ou suppression, changement de mot
de passe, …). Ainsi, les tests d’intégration permettent de garder un fonctionnement
correct même si un autre module est ajouté à notre application.
Conclusion
Nous avons présenté dans ce chapitre une vue globale sur les deux modules
réalisés à savoir : les appels à candidatures et la formation. Et ceci à travers une
description de quelques services offerts par notre application tels que : la mise à jour
des programmes par la DRH, la saisie et la validation des inscriptions par les chefs de
départements, ainsi que l’envoi des e-mails et des lettres …etc.
73
CONCLUSION GENERALE
Notre tâche était de concevoir et réaliser une application destinée aux

administrations publiques qui utilise des tables de la base de données du progiciel
GIPE.
Nous avons réalisé deux modules qui rentrent dans le cadre de la gestion des
ressources humaines à savoir : la gestion des appels à candidatures et de la formation.
Ces modules ont été développés sur le Web en utilisant la technologie J2EE. Ils
respectent l’architecture 3-tiers et le standard MVC.
Le module des appels à candidatures offre aux administrations publiques un service
qui leur permet de choisir (après inscription et entretien) un employé pour lui affecter
un poste vacant ou nouvellement crée.
Concernant Le module de la formation, il permet aux directions des ressources
humaines de gérer leurs cycles de formations, depuis la procédure du recueil des
besoins jusqu’à l’évaluation des formations, en passant par l’affectation des marchés et
le déroulement des sessions.
Les deux modules réalisés respectent un certain nombre de critères assurance qualité
tels que la portabilité, la maintenabilité et la réutilisabilité. Nous avons donné une
grande importance à la logistique du transfert d’informations entre les différents
intervenants dans notre application, en utilisant les e-mails et les éditions.
Notre projet reste ouvert. D’abord d’autres modules en relation avec la gestion des
ressources humaines peuvent être intégrés comme : la gestion de carrière, des
examens, des congés, des heures supplémentaires, …etc. Ensuite nous pouvons penser
à un outil prévisionnel qui permettra au décideur de calculer les répercussions à long
terme des paramètres opérationnels de gestion des ressources humaines.
74
BIBLIOGRAGHIE
[LAR2000] : Larne Perkowsky, L’intro JSP, CampusPress, 2000

[CLA2000] : Claude Delannoy, Programmer en JAVA, Eyrolles, 2000
[BOI2000] : J-B. Boichat, Apprendre Java et C++ en parallèle, Eyrolles, 2000
[HAG2000] : P. Haggar, Mieux programmer en java, Eyrolles, 2000
[PAT2000] : A.Patzer, Programmation Java côté serveur, Eyrolles, 2000
[CHA99] : P. Chan, Le dictionnaire officiel Java 2, Eyrolles, 1999
[CH98] : P. Chaleat & D. Charnay, Programmation HTML et javascript, Eyrolles, 1998
[FAR2000] : N. McFarlane, Javascript professionnel, Eyrolles, 2000
[LOC97] : David Lockman, ORACLE 8 développement de BD, CampusPress, 1997
[TAS2000] : A. Tasso, Le livre de Java premier langage, Eyrolles, 2000
[JF1] : www.javafr.com
[J4L2] : www.java4less.com
[CS3] : www.codes-sources.com
[DEV4] : www.developpez.com
[JSF5] : www.javascriptfr.com
[DA6] : www.developers-assosiation.org
[JSC7] : http://java.sun.com/J2EE
[JAO8] : http://jakarta.apache.org
[JT9] : www.jsptut.com
[CCM10] : www.commentcamarche.net
[SIF11] : www-sop.inria.fr
[ORS12] : www.orsys.fr
[SP13] : www.Supinf-Projects.com
[JS14] : www.javaside.com
75
Annexe 1 : Dictionnaire de données
La première annexe sera dédiée au dictionnaire de données des deux modules, il regroupe
l’ensemble des données avec leurs descriptions, leurs types, leurs natures, sans oublier les
tables qui leur sont associées. Les données sont groupées par tables, et les tables sont listées
selon leur ordre alphabétique.
76
Nom Libellé Type C ou NC Utilisé par

RefAge Référence de l’agent I NC Agent
CinAge Carte d’identité nationale de l’agent I NC Agent
NomAge Nom de l’agent T NC Agent
PreAge Prénom de l’agent T NC Agent
AdrAge Adresse de l’agent T NC Agent
VilAge Ville de l’agent T NC Agent
TelAge Téléphone de l’agent I NC Agent
EmaAge Email de l’agent T NC Agent
FonAge Fonction de l’agent T NC Agent
GraAge Grade de l’agent T NC Agent
RefApl Référence de l’appel I NC Appel_candidature
DesPos Désignation du poste T NC Appel_candidature
DatEch Date d’échéance D NC Appel_candidature
PieIns Pièces d’inscription T NC Appel_candidature
DatApl Date d’appel D NC Appel_candidature
EtaApl Etat d’appel T NC Appel_candidature
ComPos Compétences requises T NC Appel_candidature
QuaPos Qualifications du poste T NC Appel_candidature
GraPos Grade du poste T NC Appel_candidature
DirPos Direction du poste T NC Appel_candidature
RefDep Référence du département I NC Département
DesDep Désignation du département T NC Département
EmaDep Email du département T NC Département
FaxDep Fax du département I NC Département
TelDep Téléphone du département I NC Département
ResDep Responsable du département T NC Département
MotPas Mot de passe du département T NC Département
TaiDep Taille du département I NC Département
77
NbrIns Nombre d’effectif inscrit I C Département
Nom Libellé Type C on NC Utilisé par

RefEnt Référence de l’entretien I NC Entretien
LieEnt Lieu de l’entretien T NC Entretien
HerEnt Heure de l’entretien H NC Entretien
ComEnt Comité de l’entretien T NC Entretien
DatEnt Date de l’entretien D NC Entretien
ResEnt Résultat de l’entretien T NC Entretien
RefIns Référence d’inscription I NC Inscription
DatIns Date d’inscription D NC Inscription
RefMar Référence du marché T NC Marché
ObjMar Objet du marché T NC Marché
DatNot Date de notification D NC Marché
DelMar Délai du marché I NC Marché
MarGen Sessions du marché généré B NC Marché
GroGen Groupes du marché généré B NC Marché
RefMod Référence du module I NC Module
DesMod Désignation du module T NC Module
NbrPer Nombre de personnes par groupe I NC Module
PriJou Pris par jour du thème I NC Module
RefPre Référence du prestataire I NC Prestataire
DesPre Désignation prestataire T NC Prestataire
AdrPre Adresse prestataire T NC Prestataire
VilPre Ville prestataire T NC Prestataire
TelPre Téléphone prestataire I NC Prestataire
FaxPre Fax prestataire I NC Prestataire
EmaPre Email prestataire T NC Prestataire
IntDrh Interlocuteur DRH T NC Prestataire
RefPro Référence du programme I NC Programme
DatPro Date du programme D NC Programme
78
DatEch Date échéance D NC Programme
Nom Libellé Type C ou NC Utilisé par

EtaPro Etat du programme T NC Programme
ObjPro Objet du programme T NC Programme
RefSes Référence de la session I NC Session
LieSes Lieu session T NC Session
HorSes Horaire session T NC Session
DatDeb Date début de session D NC Session
DatFin Date fin de la session D NC Session
RefThe Référence du thème I NC Thème
DesThe Désignation du thème T NC Thème
ConThe Contenu du thème T NC Thème
ObjThe Objet du thème T NC Thème
DurThe Durée du thème I NC Thème
PubThe Publique ciblé du thème T NC Thème
NB :
C : champ calculable
NC : champ non calculable
79
Annexe 2 : Outils de réalisation
Cette annexe sera consacrée aux outils techniques que nous avons utilisés dans la phase de
réalisation de l’application. Nous présentons alors la plate forme J2EE (Java 2 Enterprise
Edition), les servlets, le langage JSP (Java Server Page), le serveur Web « Apache » ainsi que
le serveur d’applications Web « Tomcat » qui constitue un moteur d’exécution des servlets et
des pages JSP.
80
1. La plate-forme J2EE (Java 2 Enterprise Edition)
J2EE est à la fois une spécification technique mature et une industrie dans laquelle
les éditeurs et le monde du Libre se livrent une compétition dont l'utilisateur est le
bénéficiaire en matière choix.
Tout d'abord, Java, qui est à la base de J2EE, est aujourd'hui une technologie majeure
adoptée par l'ensemble de l'industrie logicielle à l'exception de Microsoft. Java
revendique désormais, 8 années après son apparition, plus de développeurs que le
langage Visual Basic. Avant de traiter plus en détails les propriétés de Java coté
serveur avec J2EE, il est important de noter que Java est une technologie très présente
sur le poste client ainsi que sur les périphériques tels que les téléphones portables (78
millions de téléphones vendus), les voitures, les routeurs, les cartes à puces (300
millions de cartes déployées) ou encore les assistants numériques. Toutes ces
technologies embarquées sont regroupées sous le nom de J2ME (Java 2 Micro
Edition). L'évolution de Java est aujourd'hui gérée par le Java Community Process
(JCP), consortium dans lequel siègent tous les acteurs de ce monde Java (plus de 700
membres).
Enfin, le mouvement du Libre est un acteur majeur du développement Java avec de
nombreuses implémentations Open Source.
La plate-forme Java est découpée en trois « éditions »:

 Java 2 Micro Edition (J2ME) : cette plate-forme est dédiée aux périphériques qui
embarquent une machine virtuelle Java. Il peut s'agir de téléphones mobiles, de
voitures, de cartes à puce, d'assistants numériques, et autres dispositifs aux
environnements limités en mémoire, en puissance de calcul ou en accès au réseau.
81
 Java 2 Standard Edition (J2SE) : il s'agit de la technologie de base de Java,

anciennement appelée JDK (Java Development Kit) ou JRE (pour Java Runtime
Environment). Il s'agit du socle de J2EE puisqu'un serveur d'applications nécessite
une JVM de type J2SE.
 Java 2 Enterprise Edition (J2EE) : est une extension de J2SE qui lui rajoute des
technologies pour le développement d'applications d'entreprise (des API) ainsi que
la notion de serveur d'application. J2EE et la notion de serveurs d'application
s'inscrivent dans la démarche d'architecture multi-niveaux aussi appelée
architecture « 3 tiers ». L'objectif d'une telle architecture est de masquer la
complexité d'intégration et de « webification » d'applications existantes (bases de
données, ERP, systèmes mainframe, application maison, …etc.) tout en fournissant
une meilleure qualité de service en recyclant tout ce qui peut l'être (connexions
SGBD, données, ressources, ...) au travers de pools et de caches. Un serveur
applicatif met également en œuvre des systèmes de mise en grappe (clustering) qui
utilisent plusieurs « instances » à des fins de reprise sur erreur.
Cette architecture permet également de répondre à des problématiques de sécurité
avec des topologies réseau qui nécessitent, par exemple, la mise en place d'une
zone démilitarisée (DMZ). J2EE est en quelque sorte le standard pour ces serveurs
d'applications comme LDAP est le standard pour les annuaires d'entreprises.
Le marché de J2EE sur l'année 2002 représente plus de 2 milliards de dollars et il est
en constante croissance. Il s'agit réellement d'une industrie J2EE pour laquelle plus de
trente produits se livrent une compétition autour de valeurs ajoutées. Différents
cabinets d'analystes estiment que J2EE est un standard utilisée pour 90% des serveurs
d'applications. Les technologies d'infrastructure, sous-ensembles de J2EE, telles que
JDBC pour les bases de données relationnelles, J2EE Connector Architecture (J2EE
CA) pour les ERP, mainframes, ou Java Messaging Service (JMS) pour les
82
architectures orientées messages asynchrones sont adoptées et supportées par de

nombreux éditeurs qui fournissent des produits qui implémentent ces spécifications.
2. les servlets
Une servlet est un programme java très similaire aux CGI. Elle se déclenche sur
demande d'un navigateur. Elle interagit avec des bases de données ou d'autres
programmes afin de fournir une réponse http au navigateur. Applet et Servlet, Un
applet est un programme java qui s'exécute dans un navigateur. Pour s'exécuter il
nécessite la présence d'une machine virtuelle java (Java Virtual Machine - JVM).
L'applet est une technologie " cliente ". Une servlet est un programme java qui tourne
sur un serveur. Tout comme le navigateur a besoin d'une JVM pour exécuter l'applet,
le serveur a besoin d'une JVM pour exécuter la servlet. La servlet est une technologie
"serveur ".Toutes les fonctionnalités offertes par les CGI sont accessibles dans les
servlets : une servlet peut récupérer des données en provenance d'un formulaire
HTML, elle peut accéder aux informations stockées dans l'entête http de la requête du
navigateur, il peut déposer et demander des cookies,...Contrairement aux CGI un
programme servlet est chargé une seule fois en mémoire. Il est capable de traiter des
requêtes provenant de plusieurs navigateurs en même temps. Une servlet est un
programme qui offre de bonne garantie en matière de sécurité:
 une servlet est écrite en java, elle ne peut pas produire des erreurs fatales sur le
serveur d'applications Web par des erreurs de manipulation mémoire.
 le code qui s'exécute sur le serveur est compilé, il n'est donc pas possible, en
utilisant des failles de sécurité du serveur d'applications Web d'accéder à des
83
informations sensibles hébergées dans le code (contrairement aux cgi perl, aux
scripts ASP, JSP ou PHP3).
 Une servlet ne souffre pas de l'interprétation de Meta-caractères (comme les " |, >,
>>, ... " de perl) qui permettent aux "bidouilleurs" d'interagir avec le gestionnaire
de fichiers.
Une servlet est la spécialisation de la classe java javax.servlet.HttpServlet. Afin

d'initialiser une servlet un serveur d'applications Web charge la classe du serveur, il
crée une instance de cette classe en appelant le constructeur à zéro argument puis il
déclenche la méthode init(ServletConfig). Les spécifications servlet garantissent aux

développeurs que cette méthode ne sera exécutée qu'une seule fois par le serveur
d'applications web. Lorsque la servlet est initialisée elle peut traiter les requêtes en
provenance des navigateurs, pour ceci la méthode service (HttpServletRequest,
HttpServletResponse) des servlets est déclenchée. Lorsque la servlet doit être
déchargée la méthode destroy () de la servlet est déclenchée. Plusieurs types de
requêtes HTTP peuvent être émis par un navigateur (GET, POST,...). La méthode
service de HttpServlet achemine le traitement d'une requête HTTP vers la méthode
adaptée. Une requête XXXX de HTTP est acheminée vers la méthode doXXXX
(HttpServletRequest, HttpServletResponse) de java (ie, le traitement de la requête
HTTP GET est assurée par la méthode doGet). Les informations en provenance du
navigateur sont accessible via la classe HttpServletRequest (paramètres des
formulaires, type de navigateur, referer,...). Les informations renvoyées aux
navigateurs doivent l'être par l'intermédiaire de la classe HttpServletResponse (type
MIME de la réponse, entête de la réponse, corps de la réponse, cookies,...).
84
3. les pages JSP
Il est possible pour une servlet de récupérer une requête HTTP en provenance d'un
navigateur, de générer une requête dynamiquement, en interrogeant le système
d'informations si nécessaire, et de renvoyer une réponse contenant du HTML. Le
problème avec cette approche est que la construction de la page doit être faite par la
servlet, ce qui veut dire qu'un infographiste qui voudrait modifier l'apparence de la
page renvoyée devrait modifier le code java de la servlet et le recompiler. Avec cette
approche la génération de contenu dynamique nécessite des connaissances en
programmation.
On comprend alors la nécessité de séparer la partie traitement de la requête HTTP de

l'utilisateur (logique applicative, logique transactionnelle, règles métiers) de la partie
renvoie de la page à l'utilisateur. Pour ceci, la plate-forme J2EE utilise le paradigme
Modèle-Vue-Contrôleur (Model-View-Control, MVC). Dans ce paradigme le modèle
représente le système d'information, il est constitué de composants java. La vue
représente la page HTML renvoyée à l'utilisateur, elle est composée de JavaServer
Page (JSP). Le contrôle est la glue entre les deux, il est composé d'un servlet.
Au moment du développement un JSP est très différent d'un servlet puisque c'est un
document texte composé de HTML pour les parties statiques du document, et de tags
85
spéciaux ou de code java, pour les parties dynamiques du document. Un JSP peut donc
être développé par un infographiste à partir de ses outils classiques de développement.
Au moment de l'exécution un JSP est transformé en servlet par un pré- processeur et
compilé en une classe java de manière à pouvoir être exécuté par le serveur
d'applications Web.
4. le serveur Web (Apache)
Le serveur Web d’une application J2EE (Web tiers) rend disponible la logique d'une
application sur le Web.
4.1 Rôles du serveur Web

- C’est le serveur Web qui gère la communication avec les clients Web et qui répond à
leurs requêtes.
- Un serveur Web traite des requêtes HTTP. Dans le cadre d’une application J2EE, le
serveur Web (Web tiers) gère les relations entre les clients Web et l’application.
- Le serveur Web produit typiquement du contenu HTML ou XML, bien qu’il puisse
générer d’autres types de contenu. L’architecture J2EE préconise d’implémenter la
logique métier dans le serveur d’EJB mais il est possible d’implémenter la logique
métier directement sur le serveur Web.
4.2 Fonctions du serveur Web

- Mise à disposition de la logique métier sur le Web : le serveur gère les relations
entre les clients Web et la logique métier de l’application.
- Création dynamique de contenu : le serveur Web génère dynamiquement du
contenu, dans n’importe quel type de format: HTML, images, sons, vidéo,…
86
4.3 Présentation et collecte des données

Le serveur Web transforme les requêtes http PUT et GET dans une forme
compréhensible par la couche métier de l’application et présente les résultats :
- contrôle du flux de navigation : la logique implantée dans le serveur Web détermine
quel écran de l’application envoyer au client. En effet c’est souvent le serveur Web qui
adapte la présentation et l’enchaînement des écrans en fonction des capacités du client.
- maintien des informations d’état : le serveur Web dispose d’un mécanisme simple et
flexible pour conserver des informations durant toute la durée d’une session utilisateur.
- support de plusieurs clients : par le biais des types MIME, un serveur Web peut
envoyer de l’information vers n’importe quel type de client et étendre les capacités de
publication.
- implémentation de la logique métier.
5. le moteur de servlets et de JSP (Tomcat)
Tomcat est un projet de l'Apache Software Foundation (ASF). Il est aussi

l'implémentation de référence des technologies "servlet java" et "Java Server Page".
Outre sa gratuité, ce serveur d'applications Web présente deux avantages :
 il est compatible J2EE ce qui veut dire que l'ensemble des développements réalisé
pour Tomcat pourront être porté sur des serveurs d'applications d'entreprise.
 les développements se font en java ce qui assure un niveau élevé de portabilité : il
sera possible de déployer le code qui tourne sur Tomcat sur la plupart des systèmes
d'exploitations, (Linux, AS400, Solaris, HPUX, AIX, Windows, Netware, OS390).
Ce haut niveau de portabilité favorise la réutilisation, atout des technologies objets.
En quelques mots Tomcat est un moteur d'exécution pour les servlets et les JSP. Il peut
87
être intégré au très populaire serveur Web Apache mais aussi à IIS. Le serveur Web est
alors en charge de toute la partie statique du site Web, alors que Tomcat gère la partie
dynamique (requêtes sur les servlets et les JSP).
Annexe 3 : Exemples de codes sources
Dans cette annexe nous présentons l’implémentation de quelques classes importantes comme
l’ajout, la modification, la suppression et la recherche. Nous présentons aussi des algorithmes
comme celui de la génération des sessions et celui de la génération des groupes pour un thème
particulier.
88
1. Classe ‘enregistrement’
Cette classe permet de stoker les informations correspondantes à un enregistrement

d’une table de la base de données. Elle contient des méthodes SetXX et GetXX qui
servent respectivement à lire et à écrire dans la classe.
public class enregistrement

{ private String[] nomschamps;
private String[] valschamps;
private int taille;
public enregistrement(int taille)

{ this.taille=taille; this.nomschamps=new String[taille];
this.valschamps=new String[taille];
}
public void set_nomchamps(int index,String nomchamps)

{ this.nomschamps[index]=nomchamps; }
public void set_valchamps(int index,String valchamps)

{ this.valschamps[index]=valchamps; }
public String get_nomchamps(int index) {return this.nomschamps[index];}
public String get_valchamps(int index) {return this.valschamps[index];}
public String get_valchamps(String nomchamps)

{ int index=0;
for(int i=0;i<this.taille;i++)
{ if (this.nomschamps[i].equals(nomchamps)) {index=i;break;} }
89
return this.get_valchamps(index);
}
public int get_taille() { return this.taille; }

}
90
2. Classe ‘tab_enregistrement’
Souvent le résultat d’une recherche est un ensemble d’enregistrements. La classe

‘tab_enregistrement’ permet justement de stoker et de lire les informations de ces
enregistrements grâce aux méthodes : ‘set_enregistrement’ et ‘get_enregistrement’.
public class tab_enregistrement

{ private enregistrement[] tab;
int taille;
public tab_enregistrement(int taille)

{ this.taille=taille;
this.tab=new enregistrement[taille];
for(int i=0;i<taille;i++) tab[i]=null;
}
public void set_enregistrement(int index,enregistrement enreg)

{ this.tab[index]=enreg; }
public enregistrement get_enregistrement(int index) {return this.tab[index];}
public int get_taille() { return this.taille; }

}
91
3. Classe ‘ajout’
Cette classe permet d’effectuer l’ajout d’un enregistrement. Elle est une classe
générique qui peut être utilisée pour insérer dans n’importe quelle table de la base de
données en utilisant sa méthode ‘inserer’. Elle contient également la méthode
‘enregistrement_existe’ qui sert à vérifier l’existence de l’enregistrement avant son
insertion.
public class ajout

{ private String nomtable;
private Connection con;
public ajout(String nomtable,Connection con)

{ this.nomtable=nomtable; this.con=con; }
public boolean enregistrement_existe(String nomclé,String valclé)

{ boolean flag=false;
Statement stmt=null;
ResultSet select=null;
try
{ stmt = this.con.createStatement();
select = stmt.executeQuery("select * from "+this.nomtable
+" where "+nomclé+"='"+valclé+"';");
if (select.next()) flag=true;
}
catch(Exception e) {}
return flag;
}
public boolean inserer(enregistrement enreg)

try
String list_noms=null;
String list_vals=null;
for(int i=0;i<enreg.get_taille();i++)
{ if (list_noms==null) list_noms = enreg.get_nomchamps(i);
else list_noms =
list_noms+","+enreg.get_nomchamps(i);
if (list_vals==null)list_vals="'"+enreg.get_valchamps(i)+"'";
else list_vals = list_vals+",'"+enreg.get_valchamps(i)+"'";
}
stmt.execute("insert into "+this.nomtable+" ("+list_noms
+") values ("+list_vals+");");
flag=true;
}
catch (Exception e) {}
return flag;
}
}
92
4. Classe ‘suppression’
Comme la classe ‘ajout’, ‘suppression ‘ est également une classe générique qui
permet de supprimer un ou plusieurs enregistrements de n’importe quelle table de la
base de données.
public class suppression

public suppression(String nomtable,Connection con)

{ this.nomtable=nomtable; this.con=con; }
public boolean enregistrement_existe(String nomclé,String valclé)

{// code de la méthode « enregistrement_existe »de la classe « ajout » }
public boolean effectuer_suppression(String nomclé,String valclé)

try
stmt.execute("delete from "+this.nomtable+" where
"+nomclé+"='"+valclé+"';");
flag=true;
}
catch (Exception e) {}
return flag;
}
public int suppression_multiple(String nomclé,String valsclé)

{ int nb_enreg_suppr=0;
String[] valsclé_tab=split(valsclé,',');
for(int i=0;i<valsclé_tab.length;i++)
{ boolean flag=enregistrement_existe(nomclé,valsclé_tab[i]);
if(flag)
{ effectuer_suppression(nomclé,valsclé_tab[i]);
nb_enreg_suppr++;
}
}
return nb_enreg_suppr;
}
}
93
5. Classe ‘recherche’
Cette classe est utilisée pour effectuer la recherche multicritère indépendamment

de la table. Sa méthode ‘set_condition’ permet de construire la close Where de la
requête ‘select’, tandis que la méthode ‘effectuer_recherche’ exécute cette requête et
stocke le résultat dans l’attribut ‘resultat’ de la classe.
public class recherche

private enregistrement criteres;
private String no_page;
private String nb_pages;
private String nb_enregistrements;
private tab_enregistrement resultat=null;
private int nb_lignes;
private String nomclé;
public recherche(Connection con,String nomtable,enregistrement

criteres,String
no_page,int nb_lignes,String nomclé)
{ this.con=con;
//…
}
public boolean test_like(String s)

{ boolean res=false;
if (s.charAt(s.length()-1)=='*') res=true;
return res;
}
public String set_condition()

{ String condition=null;
for(int i=0;i<criteres.get_taille();i++)
{ if(!(criteres.get_valchamps(i).equals("")))
{ String val=criteres.get_valchamps(i);
String nom=nomtable+"."+criteres.get_nomchamps(i);
if(condition==null)
{ if (!test_like(val)) condition=nom+"='"+val+"'";
else condition=nom+" like "+val.replace('*','%')+"'";
}
else
{ if(!test_like(val))condition=condition+" and
+nom+"='"+val+"'";
else condition=condition+" and "+nom+" like '"+val.replace
('*','%') +"'";
}
}
}
94
return condition;
}
public int effectuer_recherche() //retourne le nombre d'enregistrements

{
Statement stmt =null;
ResultSet res=null;
int count=0;
resultat=new tab_enregistrement(nb_lignes);
try
{ stmt = con.createStatement();
res =stmt.executeQuery("select * from "+nomtable+" where
"+this.set_condition()+" order by "+nomclé+" desc;");
if (!res.next()) { this.nb_enregistrements="0";return 0;}

count=1; while(res.next()) count++;
this.nb_enregistrements=String.valueOf(count);
set_nb_pages(); set_no_page();
Integer N=Integer.valueOf(no_page); int n=N.intValue();
res.absolute((n-1)*nb_lignes+1);
for(int rang=0;rang<nb_lignes;rang++)
{ enregistrement enreg=new enregistrement(criteres.get_taille());
for(int i=0;i<enreg.get_taille();i++)
{ enreg.set_nomchamps(i,criteres.get_nomchamps(i));
enreg.set_valchamps(i,res.getString(criteres.get_nomchamps(i)));
}
resultat.set_enregistrement(rang,enreg);
if(!res.next()) break; else continue;
}
}
catch(Exception e) {}
return count;
}
public tab_enregistrement get_resultat() { return this.resultat; }
public void set_nb_pages()

{ Integer I=Integer.valueOf(nb_enregistrements); int i=I.intValue();
int nb_pages=i/nb_lignes;
if (nb_lignes*nb_pages<i) nb_pages++;
this.nb_pages=String.valueOf(nb_pages);
}
public String get_nb_pages() { return this.nb_pages; }
public void set_no_page()

{ Integer I=Integer.valueOf(no_page); int i=I.intValue();
Integer N=Integer.valueOf(nb_pages); int n=N.intValue();
if (i>n) i--;
this.no_page=String.valueOf(i);
}
public String get_no_page() { return this.no_page; }
public String get_nb_enregistrements() { return this.nb_enregistrements; }

}
95
6. Classe ‘generer_sessions’
Cette classe sert à générer les sessions d’un thème donné. Elle permet de calculer,
pour chaque session, la date de début et la date de fin en tenant compte de la durée du
thème, des jours fériés et de l’horizon entre les sessions.
public class generer_sessions

{ private String RefThe;
private String RefMar;
private String RefPro;
private String LieSes;
private String DatDeb;
private String HorSes;
private String horizon;
public generer_sessions (String RefThe,String RefMar,String RefPro,String

LieSes,String DatDeb,String HorSes,String horizon,Connection con)
{ this.RefThe=RefThe;
//…
}
public String get_date(Date d)

{ GregorianCalendar calendar = new GregorianCalendar();
calendar.setTime(d);
int year=calendar.get(Calendar.YEAR);
int month=1 + calendar.get(Calendar.MONTH);
int day=calendar.get(Calendar.DAY_OF_MONTH);
return year + "-" + month + "-" + day;
}
public boolean generer()

{ int horizon=Integer.parseInt(this.horizon);
try
{ SimpleDateFormat sdf = new SimpleDateFormat("yy-MM-dd");
Date DatDeb=sdf.parse(this.DatDeb);
Date DatFin;
GregorianCalendar calendar = new GregorianCalendar();
calendar.setTime(DatDeb);
jour_ferier j_fer=new jour_ferier(con);

calendar=j_fer.get_true_calendar(calendar);
DatDeb=calendar.getTime();
Statement stmt = con.createStatement();

ResultSet res=stmt.executeQuery("select * from detail_pro where
RefPro='"+this.RefPro+"' and RefThe='"+this.RefThe+"';");
res.first();
96
int GroRet=res.getInt("GroRet"); int DurThe=res.getInt("DurThe");
for(int i=1;i<=GroRet;i++)
{ if(!this.HorSes.equals("jour"))
{ calendar=j_fer.add (calendar, -1+2*DurThe); }
else
{ calendar=j_fer.add (calendar, DurThe-1); }
DatFin=calendar.getTime();
Statement stmt1 = con.createStatement();

ResultSet res1=stmt1.executeQuery("select max(RefSes) from session");
res1.first();
int RefSes=res1.getInt("max(RefSes)")+1;

stmt2.execute("insert into session (RefSes, LieSes,
DatDeb,DatFin,HorSes,RefThe,RefMar) values ('"+RefSes+"',
'"+this.LieSes+"','"+get_date(DatDeb)
+"','"+get_date(DatFin)
+"','"+this.HorSes+"','"+this.RefThe+"','"+this.RefMar+"'
);");
calendar=j_fer.add (calendar, horizon);
DatDeb=calendar.getTime();
}

stmt3.execute("update theme_mar set SesGen='oui' where
RefMar='" + this.RefMar+"' and RefThe='"+this.RefThe+"';");
return true;
}
catch (Exception e) {return false;}
}
}
97
7. Classe ‘generer_groupes_monoregions’
Lorsque les sessions sont générées, la DRH doit procéder à la formation des
groupes. Cette classe permet de réaliser cette opération selon un scénario monorégion.
C'est-à-dire que les groupes sont formés de façon à ce que les personnes du même
département se trouvent dans la même session.
Il existe aussi une classe similaire dont le nom est ‘generer_groupes_multiregions’
qui permet de former des groupes contenant des personnes de différents départements.
public class generer_groupes_monoregions

{ private String RefThe;
private String RefMar;
private String RefPro;
public generer_groupes_monoregions (String RefThe,String RefMar,String RefPro)

{ this.RefThe=RefThe; this.RefMar=RefMar;
this.RefPro=RefPro;
}
public boolean generer_groupes(Connection con)

{
try
{ Statement stmt1 = con.createStatement();
ResultSet res1=stmt1.executeQuery("select RefDep,count(*) as
nbre from inscription_form where RefThe='"+this.RefThe+"' and
RefPro='"+ this.RefPro +"' and EtaIns2='inscrit' group by
RefDep order by nbre desc;");

ResultSet res2=stmt2.executeQuery("select * from session where
RefThe='"+ this.RefThe+"' and RefMar='"+this.RefMar+"' order by RefSes;");
Statement stmt = con.createStatement();

ResultSet res=stmt.executeQuery("select NbrPer from detail_pro
where RefPro='"+this.RefPro+"' and RefThe='"+this.RefThe+"';");
res.first();
int NbrPer= res.getInt("NbrPer");
res2.first(); int i=0;
while(res1.next())
{ String RefDep=res1.getString("RefDep");
ResultSet res3=stmt3.executeQuery("select * from
98
inscription_form where RefPro='"+this.RefPro+"' and

RefThe='"+this.RefThe+"'and RefDep='"+RefDep+"' and
EtaIns2='inscrit' order by RefIns;");
while(res3.next())
{ Statement stmt10 = con.createStatement();
ResultSet res10=stmt10.executeQuery("select
max(RefSesIns) from formation_groupe");
res10.first();
int RefSesIns=res10.getInt("max(RefSesIns)")+1;

stmt4.execute("insert into formation_groupe
values('"+RefSesIns+"','"+res2.getString("RefSes")
+"','"+res3.getString("RefIns")+"');");
i++;
if(i>=NbrPer) {res2.next();i=0;}
}
}
return true;
}
catch (Exception e) {return false;}
}
}
99

Pfe Version Finale

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Pfe Version Finale

Hochgeladen von

Copyright:

Verfügbare Formate

REMERCIEMENTS

Nous tenons à remercier Monsieur Régragui, Directeur de FORINFO, pour

Nos remerciements vont ensuite à Monsieur A. El Faker, notre encadrant à

LISTE DES ABREVIATIONS

LISTE DES FIGURES

Figure 3.1 : Diagramme des cas d’utilisation des appels à candidatures……………….. 28

CHAPITRE 1 : Contexte du projet…………………………………………… 8

CHAPITRE 2 : Analyse des besoins…………………………………………... 14

CHAPITRE 3 : Conception des modules…………………………………….. 26

CHAPITRE 4 : Réalisation de l’application…………………………………. 41

4.2 Réalisation du module des appels à candidatures…………………….. 46

ANNEXE 1 : Dictionnaire de données………………………………………... 68

ANNEXE 2 : Outils de réalisation …………...……………………….…….... 72

ANNEXE 3 : Exemples de codes sources…………………………………….. 80

FORINFO est une société privée spécialisée dans l’informatique et la formation du

CHAPITRE 1 : Contexte du projet

1.1 Présentation de FORINFO

FORINFO, société de conseil et d'ingénierie informatique, a été créée en 1991, par

Consciente que la valeur ajoutée de ses prestations réside essentiellement dans la

Intervenant également, en matière du conseil en Management de la Qualité,

1.1.1 Activités de la société FORINFO

 Département Audit & Conseil

Formé d’ingénieurs informaticiens et d’experts en organisation et en management,

- Plan de Développement Informatique

- Progiciel Intégré pour l’Administration Publique «IAP.2000»

- Etude de Convergence de Solution Standard

- Intégration du Système d’Information

- Plan Assurance Qualité

 Département Recherche & Développement

Renforcé de concepteurs et de développeurs de hauts niveaux, cette entité peut se

- Editeur de progiciels standards intégrés pour le secteur public

- Réalisation des applications informatiques

- Conception, Réalisation, Mise en place et maintenance des systèmes

- Mise en place des solutions de conversion ou de migration.

Cette entité veille à développer les compétences de la société, améliorer ses

 Centre de formation FORINFO

1.1.2 FORINFO en chiffres

FORINFO en chiffres, c’est :

 une quinzaine d’ingénieurs et de collaborateurs qualifiés, à temps plein, à votre

 un réseau de vingt sept experts en management public et informaticiens de

 près d’une quarantaine de projets d’étude de convergence, de développement et

 éditeur d’une dizaine de progiciels intégrés, dans le cadre de l’IAP.2000,

 plus de 12 ans d’expérience dans l’informatisation des systèmes d’information

 300 m2 de locaux, sur deux niveaux, au cœur de la capitale administrative

 10 salles, dont 4 dédiées à la formation, dûment équipées en matériel didactique

 SSII dont le capital social est de 500.000,00 Dh

1.2 Description du projet

CHAPITRE 2 : Analyse des besoins

2.1 Analyse de l’existant

 Dernière situation des postes budgétaires : Ce menu donne la possibilité

Le module « actes de gestion » offre les fonctionnalités suivantes :

Les fonctionnalités de ce module peuvent être résumés comme suit :

2.1.2 Gestion des appels à candidatures

 Les chefs de département envoient les appels à candidatures à la DRH.

 Les candidats peuvent s’inscrire dans n’importe quel appel de candidature

2.1.3 Gestion de la formation

 Les marchés de formation

 Les lieux de formation

2.2 Spécification des besoins

L’analyse de la GIPE nous permet de mieux comprendre le processus de gestion du

2.2.1 Cahier des charges

 Réaliser une application qui respecte le modèle MVC, c'est-à-dire une

En ce qui concerne le module de la formation, il doit permettre :

 L’automatisation de la procédure d’évaluation.