Vous êtes sur la page 1sur 68

2017 - 2018

TELECOMMUNICATIONS

Conception et développement d’une


solution de gestion de candidature
Orange Developer Center

Réalisé par: Islem Soussou

Encadrant ESPRIT: Nejla Rejeb

Encadrant Entreprise: Karim Gharbi

1
Signature des encadrants

Mr Karim Gharbi

Mme Nejla Rejeb

i
Dédicaces

A mes chers parents qui n’ont jamais cessé de m’épauler,


A mon épouse qui me soutient inconditionnellement,
A mes frères que j'aime beaucoup,
A toute ma famille,
A tous ceux qui m'aiment,
A tous ceux qui ne cessent de m'encourager,
Je dédie ce travail modeste.

ii
Remerciements

Je tiens à écrire ces quelques lignes en signe de gratitude

à tous ceux qui, de près ou de loin, ont contribué à l'aboutissement de ce travail.

Je remercie très vivement mes encadreurs, Monsieur Karim Gharbi et Madame

Nejla Rejeb de m'avoir accueilli, de leur disponibilité malgré leurs multiples engagements,

leurs critiques, leurs conseils judicieux qu'ils n'ont jamais cessé de me

prodiguer tout au long de ce stage et qui n'ont épargné aucun effort dans l'encadrement

de ce projet et pour leur grande rigueur.

Je tiens à remercier vivement mes collègues de travail et mes amis.

Toute ma reconnaissance à tous les enseignants d’ESPRIT et les membres du jury d’avoir

accepté de juger mon modeste travail.

iii
Résumé
La sélection des meilleurs profils est un enjeu majeur pour les entreprises. Ces dernières se
retrouvent face à une problématique difficile à résoudre : comment dénicher les meilleurs talents ?
Comment trouver les meilleurs candidats en moins de temps ?
Au cours de notre projet, nous avons pour objectif de réaliser une plateforme de gestion des
candidatures pour l’Orange Developer Center et automatiser la sélection des meilleurs candidats.
Ce rapport va retracer les différentes étapes du parcours réalisé, étude fonctionnelle, étude
technique et finir par la conception.
Mots clés: Architecture MVC, Application Web, Dashboard

Abstract
The selection of the best profiles is a major challenge for companies. The latter are faced
with a difficult problem to solve: how to find the best talent? How to find the best candidates in less
time?
During our project, we aim to create a platform for managing applications for the Orange
Developer Center and automate the selection of the best candidates.
This report will trace the different stages of the realized course, functional study, technical
study and finish with the design.
Keywords: MVC architecture, Web Application, Dashboard

iv
Sommaire
Introduction Générale ........................................................................................................................................ 1
Chapitre 1 : Etat de l’art................................................................................................................................. 2
Introduction : ..................................................................................................................................................... 3
I. Cadre de projet : ............................................................................................................................................. 3
1. Entreprise d'accueil : ................................................................................................................................. 3
2. Présentation de Projet : .............................................................................................................................. 5
II. Etude de l'existant : ....................................................................................................................................... 5
1. Problématique :...................................................................................................................................... 5
2. Solutions sur le Marché : ........................................................................................................................... 5
2.1. HumanSourcing : ................................................................................................................................ 5
2.2. Flatchr :............................................................................................................................................... 5
2.3. KiosKemploi : .................................................................................................................................... 6
2.4. Solution proposée : ............................................................................................................................. 6
III. Méthodologies de Conception : .................................................................................................................. 7
1.Etude comparative : .................................................................................................................................... 7
2. Méthodologie choisie : .............................................................................................................................. 9
3. Le processus de modélisation : ................................................................................................................ 11
Conclusion : ..................................................................................................................................................... 11
Chapitre 2 : Analyse et spécification des besoins........................................................................................ 12
Introduction : ................................................................................................................................................... 13
1. Identification des acteurs : ........................................................................................................................... 13
2. Identification des besoins : .......................................................................................................................... 14
2.1. Besoins Fonctionnels ............................................................................................................................ 14
2.2. Besoins non Fonctionnels ..................................................................................................................... 15
3. Diagramme de cas d'utilisation générale : ................................................................................................... 16
4. Diagrammes de cas d'utilisation et descriptions textuelles : ........................................................................ 17
4.1: Diagrammes de cas d'utilisation détaillés de l'acteur Client :............................................................... 17
4.2: Diagrammes de cas d'utilisations détaillés de l’administrateur : .......................................................... 18
5. Diagrammes de séquence système : ............................................................................................................ 21
5.1: Diagrammes de séquence système pour l'acteur Client : ...................................................................... 21
5.2: Diagrammes de séquence système pour l'acteur Administrateur : ....................................................... 24
Conclusion : ..................................................................................................................................................... 27
Chapitre 3 : Conception ................................................................................................................................ 28
Introduction : ................................................................................................................................................... 29
I. Etude technique : .......................................................................................................................................... 29
II. Architecture mise en place :........................................................................................................................ 30
1. Architecture de la solution :................................................................................................................. 30
1.1: Couche présentation des données : ................................................................................................... 31
v
1.2: Couche métier : ............................................................................................................................... 31
1.3: Couche accès aux données : ............................................................................................................ 31
2. Architecture MVC : ................................................................................................................................. 31
III. Diagramme de déploiement : ..................................................................................................................... 32
IV. Diagramme de classe :............................................................................................................................... 33
V. Diagramme de séquence d'objet : ............................................................................................................... 34
VI. Diagramme d'activité : .............................................................................................................................. 37
Conclusion : ..................................................................................................................................................... 38
Chapitre 4 : Réalisation ................................................................................................................................ 39
Introduction ..................................................................................................................................................... 40
I. Environnement de travail : ........................................................................................................................... 40
1. Environnement matériel : ........................................................................................................................ 40
2. Environnement logiciel : ..................................................................................................................... 41
2.1: WampServer : ................................................................................................................................... 41
2.2: HTML :............................................................................................................................................. 41
2.3: JavaScript : ....................................................................................................................................... 41
2.4: PHP : ................................................................................................................................................ 42
2.5 : Framework Laravel : ....................................................................................................................... 42
II. Processus de développement : .................................................................................................................... 43
1. Développement de l’application : ............................................................................................................ 43
2. Schéma global : ....................................................................................................................................... 43
III. Scenarios et tests : ..................................................................................................................................... 44
1. Page d’accueil :........................................................................................................................................ 44
2. Inscription :.............................................................................................................................................. 45
3. Authentification : ..................................................................................................................................... 46
4. Espace Administrateur : .......................................................................................................................... 47
5. Gestion des offres : .................................................................................................................................. 48
6. Gestion des actualités : ............................................................................................................................ 49
7. Gestion des départements : ...................................................................................................................... 50
8. Gestion des Tests de compétences : ........................................................................................................ 51
9. Gestion des candidatures : ....................................................................................................................... 54
10. Consultation des Statistiques : ............................................................................................................... 55
Conclusion et perspectives .............................................................................................................................. 56
Netographie ..................................................................................................................................................... 57

vi
Liste des Figures

Figure 1: Organisme d’accueil .......................................................................................................................... 4


Figure 2: Le système d’information soumis à deux types de contraintes .......................................................... 9
Figure 3: Le processus de développement en Y .............................................................................................. 10
Figure 4: Diagramme de cas d'utilisation générale .......................................................................................... 16
Figure 5: Diagramme de cas d'utilisation « Postuler Offres » ......................................................................... 17
Figure 6: Diagramme de cas d'utilisation « Gérer Candidats » ....................................................................... 18
Figure 7: Diagramme de cas d'utilisation « Gérer Candidatures » .................................................................. 19
Figure 8: Diagramme de cas d'utilisation « Gérer Actualités » ....................................................................... 20
Figure 9: Diagramme de séquence « Inscription » .......................................................................................... 21
Figure 10: Diagramme de séquence « Postuler » ............................................................................................ 22
Figure 11: Diagramme de séquence « Consulter actualités » .......................................................................... 23
Figure 12: Diagramme de séquence « Ajouter une offre » .............................................................................. 24
Figure 13: Diagramme de séquence « Modifier un département » ................................................................. 25
Figure 14: Diagramme de séquence « Refuser une candidature »................................................................... 26
Figure 15: Architecture du projet .................................................................................................................... 29
Figure 16: Architecture de l’application .......................................................................................................... 30
Figure 17: Les éléments du Framework MVC ................................................................................................ 31
Figure 18: Diagramme de déploiement ........................................................................................................... 32
Figure 19: Diagramme de classe ..................................................................................................................... 33
Figure 20: Diagramme de séquence objet « Inscription » ............................................................................... 34
Figure 21: Diagramme de séquence objet « Postuler » ................................................................................... 35
Figure 22: Diagramme de séquence objet « Valider candidature » ................................................................. 36
Figure 23: Diagramme d'activité « Statistiques » ............................................................................................ 37
Figure 24: Diagramme d'activité « Supprimer une offre » .............................................................................. 38
Figure 25: Laptop HP 840 G3 ......................................................................................................................... 40
Figure 26: Logo WampServer ......................................................................................................................... 41
Figure 27: Logo HTML ................................................................................................................................... 41
Figure 28: Logo Javascript .............................................................................................................................. 41
Figure 29: Logo PHP ....................................................................................................................................... 42
Figure 30: Logo Laravel Framework............................................................................................................... 42
Figure 31: Schéma global ................................................................................................................................ 43
Figure 32: Interface d'Accueil ......................................................................................................................... 44
Figure 33: Interface d'inscription..................................................................................................................... 45
Figure 34: Interface d'authentification............................................................................................................. 46
Figure 35: Interface espace administrateur ...................................................................................................... 47
Figure 36: Interface gestion des offres ............................................................................................................ 48
Figure 37: Interface publication des offres ...................................................................................................... 48
Figure 38: Interface gestion des actualités ...................................................................................................... 49
Figure 39: Interface Ajouter actualité.............................................................................................................. 49
Figure 40: Interface gestion des départements ................................................................................................ 50
Figure 41: Interface ajouter un département.................................................................................................... 50
Figure 42: Interface Accès espace de tests ...................................................................................................... 51
Figure 43: Interface Menu Questions .............................................................................................................. 51
Figure 44: Interface Menu ajout Question ....................................................................................................... 52
Figure 45: Interface Menu Réponses ............................................................................................................... 53
Figure 46: Interface ajout Réponses ................................................................................................................ 53
Figure 47: Interface gestion des candidatures ................................................................................................. 54
Figure 48: Interface planification rendez-vous ................................................................................................ 54
Figure 49: Interface consultation des statistiques ............................................................................................ 55

vii
Liste des tableaux

Tableau 1: Fiche d'identité d'Orange Tunisie .................................................................................................... 3


Tableau 2: Tableau de comparaison des différentes méthodologies de gestion de projet ................................. 8
Tableau 3 : Diagramme de cas d'utilisation "Postuler Offres" ........................................................................ 17
Tableau 4 : Diagramme de cas d'utilisation "Gérer Candidats" ...................................................................... 18
Tableau 5 : Diagramme de cas d'utilisation "Gérer Candidatures" ................................................................. 19
Tableau 6 : Diagramme de cas d'utilisation "Gérer Actualités" ...................................................................... 20

viii
Lexique

CV : Curriculum Vitae
SAAS : Software As A Service
UML : Unified Modeling Language
MVC : Modele-Vue-Controleur
HTTP : HyperText Transfer Protocol
RUP : Rational Unified Process
2TUP : Two Tracks Unified Process
XP : eXtreme Programming
HTML : HyperText Markup Language
PHP : Hypertext Preprocessor
SGBD : Système de Gestion de Base de Données
MYSQL : My Structured Query Language
CSS : Cascading Style Sheets
QCM : Question à Choix Multiples

ix
Introduction Générale

A
ujourd'hui, le recrutement a changé et en conséquence, la conception du recrutement
a évolué. Pour faire face à ces nombreuses tensions observées sur le marché de
l'emploi, les entreprises sont désormais dans l'obligation de répondre rapidement
aux nouveaux enjeux liés à ce processus.

Le recrutement est au cœur des préoccupations des entreprises en raison de la raréfaction de


certains profils de spécialistes ou d'experts. L'acquisition d'une main d'œuvre compétente et motivée
participe au succès social et économique de l'entreprise, des équipes de travail, du personnel
d'encadrement.

L'enjeu de la capacité à attirer des personnes qualifiées et à prendre les bonnes décisions en
matière de sélection est un facteur de réussite dans un environnement compétitif.

Une tendance forte du recrutement est l’inbound recruiting via un site carrière qui est une
application web, qui consiste à imaginer un tunnel de conversion pour capter les meilleurs profils et
les transformer en candidats. Ainsi, un inconnu est converti d’un simple visiteur en futur
collaborateur.

C’est dans cette vision que Orange Developer Center a voulu réaliser une solution de
recrutement qui lui soit propre. Orange Developer Center nous a donc proposé de concevoir cette
application au cours de notre stage de fin d’études à l’Ecole Supérieure Privée d’Ingénierie et de
Technologie ESPRIT.

Dans ce rapport, nous allons commencer par présenter l’environnement d’accueil et le cadre de
l’élaboration de notre projet. Ensuite, on citera les besoins fonctionnels et non fonctionnels de notre
projet à partir de ce qui existe dans la société et les solutions existant dans le marché. Partant de la
spécification, nous concevrons l'application à travers les différents diagrammes UML (Unified
Modeling Language). Enfin, nous décrirons l'implémentation de notre application tout en présentant
quelques imprimés écran des interfaces.

1
Chapitre 1 : Etat de l’art

Sommaire
Introduction……………………………………………..3
I. Cadre du projet………………………………………..3
II.Etude de l’existant……………………………………5
III.Méthodologie de Conception………………………..7
Conclusion …………………………………………….11

2
Introduction :
Ce chapitre a pour objectif de présenter l’état de l’art. Il commence tout d’abord, par la
présentation du cadre de projet. Après, il s’intéresse à l’étude de l’existant et traite la
problématique. Et enfin, il se termine par présenter les solutions sur le marché.

I. Cadre de projet :
1. Entreprise d'accueil :
Orange, l’un des principaux opérateurs de télécommunications dans le monde, a été créé
en 1994 puis racheté par le groupe France Télécom en 2000. Elle comptait fin 2015 près
de 262,9 millions de clients dans le monde répartis dans 32 pays. En Juillet 2009, étant le
deuxième opérateur privé de télécommunications en Tunisie, Orange a obtenu la licence
de téléphonie mobile sous le Nom d'Orange Tunisie. Le 05 mai 2010, Orange Tunisie
démarre officiellement sur le marché tunisien en lançant ses activités commerciales et
offrant ses services. Quelques années plus tard, le 30 Mars 2016, elle a lancé le réseaux 4G
après avoir bénéficier de l'exclusivité sur la licence 3G.
Tableau 1: Fiche d'identité d'Orange Tunisie

Nom de l'organisme Orange Tunisie

Création Octobre 2009

Date de lancement Commerciale 05 Mai 2010

Capital 78.450.200 TND

Direction Thierry Millet (DG)


Marouane Mabrouk (président du conseil d'administration)
Activité Téléphonie mobile
Téléphonie fixe
Internet
Siège social Immeuble Orange, Centre Urbain Nord, 1003 Tunis

N° de téléphone +216 3001 3001


N° de Fax +216 71 961 808
Site Web www.orange.tn

3
La figure suivante étale la structure d’Orange Tunisie avec un focus sur la direction d’accueil.

Direction Financière

Direction Réseaux et Services

Direction PMO

Direction Marketing et Communication

Direction Commerciale Entreprise

Département RSE et Innovation


Direction Régulation et Opérations
numérique
Direction Générale

Département Progression Stratégique,


Direction Relations Extérieures
partenariats & RP

Département Médias et
Direction Juridique
Communication Externe

Direction Administration, Achats et


Logistiques

Direction Services Clients

Direction Ressources Humaines

Direction Systèmes d'Informations

Direction Commerciale Grand Public

Figure 1: Organisme d’accueil

4
2. Présentation de Projet :
Notre travail a pour objectif la conception et le développement d'une application
permettant la gestion des ressources humaines de l’organisme d’accueil. Ce projet permet de
donner une nouvelle vision de relation client tout en donnant la possibilité d'interagir avec les
candidats. Aussi, il permet de pousser des offres d’encadrement ou de formation en bon moment
d'une manière numérique et personnalisée. Cette nouvelle relation client est basée sur l'intégration
des atouts du monde digital.

II. Etude de l'existant :

1. Problématique :
Le système actuel est basé sur des manières traditionnelles soit par le traitement manuscrit
ou bien sur Excel ; ainsi que l’interaction entre le personnel et les différents intervenants se passe
par contact direct ou bien par téléphonie. Or ce processus est obsolète par rapport à l’ère
numérique.

2. Solutions sur le Marché :

Dans cette section, nous allons aborder les différentes solutions disponibles sur le marché
citons en exemple les outils tels que HumanSourcing, Flatchr, KiosKemploi et pleins d’autres
[1]. Nous n’indiquerons pas les prix vu que sa varie des options choisies lors de l’acquisition.

2.1. HumanSourcing :
C’est un outil prédominant du secteur avec plusieurs milliers d’utilisateurs à travers le
monde. Il permet de stocker les CV selon des critères définis afin de pouvoir les consulter
ultérieurement. Il permet à toute offre de se propager via les plateformes de recrutement et aussi
via les réseaux sociaux.
2.2. Flatchr :
C’est une solution SaaS proposant des outils comme la multi-diffusion, viviers,
cooptation,…
Elle permet la gestion des candidatures simple et permet de les diffuser sur plus d’une centaine
de sites d’emploi.

5
2.3. KiosKemploi :
C’est un outil disponible en plusieurs langues intuitif et simple d’utilisation. Il offre des
services dont la diffusion dans plusieurs sites d’emploi et permet la notification par mail et le tri
par critères prédéfinis des CV.
2.4. Solution proposée :
En assurant la confidentialité des données et en respectant la charte et l’image de la
marque, nous aurons pour but de concevoir une solution adaptée aux besoins de Orange
Developer Center.
Pour y arriver, nous utiliserons les technologies disponibles sur le marché du logiciel libre.
Avec ces outils, nous concevrons une interface centrale pour les candidats et les responsables
munie d’une base de données qui stockera les données et les fournira lorsque c’est demandé ainsi
que des fonctionnalités de mailing, de tests de compétences et de rendez-vous.

6
III. Méthodologies de Conception :

1.Etude comparative :
Pour bien gérer un projet, il est primordial de choisir la démarche méthodologique adéquate. Dans
cette partie, nous allons proposer une comparaison entre les différentes méthodologies de
conception, et nous choisirons par la suite la méthodologie qui répondra à nos attentes.

Il est possible de classer les démarches de gestion de projet en trois grandes familles[2] :

 Les processus séquentiels : souvent utilisé pour le développement de logiciel. Tel


que leur nom l’indique, ces méthodes ne sont pas itératives. Nous pouvons citer en
exemple le modèle en cascade, le cycle en V, le cycle en spirale…

 Les méthodes de processus unifié : contrairement aux processus séquentiels, cette


catégorie est celle des méthodes génériques, itératives et incrémentales. Nous
trouvons dans cette famille la méthode RUP « Rational UnifiedProcess » [3] ou 2TUP
« TwoTracksUnifiedProcess ».

 Les méthodes agiles : non seulement itératives et incrémentales mais aussi


adaptatives. Les plus fréquemment utilisées sont Scrum, XP «
eXtremeProgramming ».

7
Nous allons maintenant comparer les différentes méthodes dans le tableau qui suit.

Tableau 2: Tableau de comparaison des différentes méthodologies de gestion de projet

Méthodologie Descriptif Avantages Inconvénients


Cascade -Un processus -Les phases du projet -Non itératif : en cas
d’implémentation sont explicitement d’erreur pas de
séquentiel, souvent définies dans ce possibilités de
utilisé dans le processus correction
processus de -Pas d’incrément : un
développement de produit fini
logiciel. fonctionnel est obtenu
tard comparé au début
du projet
XP -Tente de réduire les -Un niveau de qualité -Méthodologie dure à
coûts de changement élevé. accomplir.
d’exigences en faisant -La satisfaction du -Développement basé
plusieurs cycles courts client est augmentée. sur le code au lieu
de mise en place au -La conception est d’être basé sur la
lieu d’un seul. simple. conception.
-Dans cette -Manque de
méthodologie, les documentation sur la
changements sont un conception.
aspect naturel.
Scrum -Méthodologie basée -Permet de livrer un -Convient mieux aux
sur les principes des produit de qualité petites équipes.
méthodologies agiles. suivant un temps -Si une exigence n’est
-Projet décomposé en planifié. pas définie, les coûts
sprints à la fin duquel -Feedback en continu du projet et le temps
nous avons un du client. alloué ne pourront pas
livrable. -Mise en place rapide être proprement
-Méthodologie et facilité de estimés.
contient différentes correction des erreurs
rôles. possibles.
-Economie de temps
et d’argent.
2TUP -Son principe -La technologie est -Superficiel sur les
fondateur est que une partie à part phases du
toute évolution entière dans le développement citons
imposée peut se processus de la maintenance et la
décomposer et se développement. capture des besoins.
traiter parallèlement -Prend en -N’impose aucun
suivant 2 axes considération le modèle de document.
fonctionnel et changement continu
technique. dans les projets.
-La réalisation -La séparation des
consiste à fusionner aspects technique et
les résultats des fonctionnel du projet.
branches du processus
précédemment
indiquées.

8
Suite à l’étude comparative effectuée plus haut, nous arrivons aux conclusions suivantes :

- Etant une méthodologie non itérative, la méthodologie « Cascade » ne répond pas à


nos besoins. Nous avons en effet besoin de tester et de corriger nos erreurs au fur et
à mesure du cycle.

- Le processus « XP » [4] est essentiellement centré sur le développement. Il néglige


la phase de conception et le côté technique. Cette méthodologie ne convient pas à
notre projet dont la technologie est importante.

- « Scrum » [5] sollicite une équipe de développement composée de 3 personnes au


minimum (product owner, scrum master, développeur) et exige un prototype à la fin
de chaque sprint. Etant seul sur ce projet, Scrum est écarté.

- Le processus « 2TUP » [6] donne autant d’importance aux besoins fonctionnels que
techniques. De plus c’est une méthodologie itérative. Pour ces raisons c’est celle que
nous avons choisi.

2. Méthodologie choisie :
Le processus 2TUP fait la distinction entre les aspects techniques et les aspects
fonctionnels. Il débute avec une étude préliminaire consistant principalement à caractériser les
acteurs qui vont interagir avec le système en vue de construction, les messages qui trafiquent
entre les acteurs et le système, à manifester le cahier des charges et à concrétiser le contexte (le
système est une boîte noire, les acteurs l'entourent et sont reliés à lui, sur l'axe qui lie un acteur
au système on met les messages que les deux s'échangent avec le sens).

Figure 2: Le système d’information soumis à deux types de contraintes

9
La branche fonctionnelle : étudie précisément le métier de l’entreprise. Elle constitue
généralement une idée de ce que réalisera le système en terme de métier au futur pour le moyen
et le long terme.
Les fonctions du système d’information sont en effet indépendantes des technologies utilisées.
Cette branche comporte les étapes suivantes :

 La frontière entre le système et son environnement, capture des besoins


fonctionnels.

 L’analyse des besoins focalisée sur le métier des différents utilisateurs.

La branche technique : cette étape recense les contraintes et les composants nécessaires
pour la conception du système ainsi que les technologies et les outils permettant la bonne
réalisation. Elle tient compte de l’investissement pour le court et moyen terme.
Cette branche est composée des étapes suivantes :

 La capture des besoins techniques.



 L’étape de conception générique.


La branche du milieu : c’est la fusion des résultats des 2 branches. Cette fusion permet

d’obtenir un processus en forme de Y.
Cette branche est constituée des étapes suivantes :

 La conception préliminaire.

 La conception détaillée.

 Le codage.

 L’intégration ou recette.

Notre choix s’est porté sur cette méthodologie parce qu’elle permet une étude parallèle des
besoins techniques et fonctionnels du projet ce qui nous permet de déterminer si un besoin
fonctionnel est réalisable techniquement ou pas avant de passer à la partie réalisation.

Figure 3: Le processus de développement en Y

10
3. Le processus de modélisation :
En tenant compte des objectifs fixés pour la réalisation du projet, nous remarquons que
nous devons concevoir une application modulaire et qui devra garder l’aspect ouvert pour les
améliorations progressives. De ce fait, il est très important de se munir d’un langage universel
pour la modélisation afin de structurer la conception et de qualifier les échanges. Désormais, le
processus 2TUP s'appuie sur le langage de modélisation UML tout au long du cycle de
développement qui s’adapte à toutes les méthodes objet ainsi qu’à la représentation architecturale
du système.

UML est un langage de modélisation unifié permettant la modélisation d’une application


logicielle de façon standard dans le cadre de la conception orienté objet.

Ses principaux avantages sont :


-Universel.

- Adopté par les grandes entreprises ainsi que par plusieurs processus de développement.

- Notation unifiée.

- Compréhension facile.

- Risques d’erreurs minimes.

- N’est pas restreint au domaine informatique.

Conclusion :
Dans de ce premier chapitre nous avons présenté le contexte dans lequel notre projet a
été effectué. Nous avons commencé par présenter l’organisme d’accueil. En second lieu nous
avons introduit notre problématique annoncée. Finalement, nous avons choisi la méthodologie à
adopter.
Nous allons dans le chapitre prochain traiter les deux branches fonctionnelle et technique de la
méthodologie choisie 2TUP, en spécifiant et analysant les besoins auxquels nous devrons
satisfaire.

11
Chapitre 2 : Analyse et
spécification des besoins

Sommaire
Introduction……………………………………………….....13
1.Identification des acteurs ……………………………….....13
2.Identification des besoins …………….…………………...14
3.Diagramme de cas d'utilisation générale…………………..16
4.Diagrammes de cas d'utilisation et descriptions textuelles...17
5.Diagrammes de séquence système…………………………21
Conclusion………………………………………………....…27

12
Introduction :
Après la présentation du cadre général de notre projet, ce chapitre sera consacré à la
spécification et d’analyse des besoins. Nous allons énumérer les besoins à satisfaire et qui
représentent les fonctionnalités à réaliser dans notre application.
La phase initiale du développement constitue l’identification des acteurs et des besoins de notre
application. Nous distinguerons les besoins fonctionnels qui représentent les fonctionnalités attendues
de notre application et les besoins non fonctionnels pour éviter le développement d’une application
non satisfaisante, de même trouver un accord commun entre les spécialistes et les utilisateurs pour
réussir le projet.

1. Identification des acteurs :


Avant d’élaborer les besoins fonctionnels, il faut commencer par définir les principaux
acteurs (utilisateurs).

Les acteurs sont des entités externes qui interagissent avec le système, comme une
personne humaine ou un robot. Une même personne (ou robot, ...) peut jouer le rôle de plusieurs
acteurs pour un système, c'est pourquoi les acteurs devraient être décrits par leur rôle, ce rôle
décrit les besoins et les capacités de l'acteur. Un acteur agit sur le système (accès de
lecture/écriture). L'activité du système a pour objectif de satisfaire les besoins de l'acteur. Les
acteurs sont représentés par un pictogramme humanoïde sous-titré par le nom de l'acteur. Les
acteurs sont classifiés en 3 catégories : les acteurs principaux (ex: visiteur, candidat, etc), les
acteurs secondaires (ex: administrateur, opérateur de maintenance, etc), les autres systèmes
(serveur, etc).

Les acteurs potentiels de notre système sont décrits comme suit :


Client : Toute personne qui a accès à l'application dont il a la possibilité de s'inscrire,
recevoir les notifications des nouvelles offres, consulter les actualités, tester ses

compétences et postuler pour les offres qui l’intéresse.


Administrateur : Cet acteur a l'accès à toutes les fonctionnalités de l'application tel
que la gestion des responsables, la gestion des départements, la gestion des offres, la

gestion des actualités et la Consultation des candidatures.

13
2. Identification des besoins :
2.1. Besoins Fonctionnels
On consacrera cette partie à la description des exigences fonctionnelles des différents acteurs
de l’application.

 
Candidat :


- L’inscription : le candidat doit s’enregistrer avec ses informations personnelles et doit
ajouter les fichiers résumé et photo.
- L'authentification : le candidat doit saisir ses identifiants attribués pour pouvoir accéder à
son espace.
- La modification/mise à jour de son profil : le candidat peut modifier ses informations
personnelles lors de changement ou obtention de nouvelles compétences.

- Postuler aux offres proposées : le candidat peut postuler pour l’offre qui lui convient de
mieux après lecture des informations associées au poste.

- Tests de compétences : pour valider sa candidature à l’offre le client doit passer un test
sous forme de quiz relatif à la nature de chaque offre.

- Accès aux News : le candidat peut lire les dernières actualités relatives à Orange
Developer Center.

 
Administrateur :

- L'authentification : l'administrateur doit s'authentifier pour accéder à toutes ses
fonctionnalités.
- Gestion des offres : l'administrateur a la possibilité de consulter, ajouter, modifier,
attribuer une date d’expiration et supprimer des offres.

- Gestion des départements : l'administrateur peut gérer les départements (consulter,


ajouter, modifier ou supprimer un département).

- Gestion des actualités : ajouter des nouvelles actualités avec le titre, la description et
l'image correspondante à chaque nouveauté. Il a le droit également à modifier ou
supprimer une actualité.

14
- Consultation des candidats : l'administrateur peut consulter la liste des clients déjà
inscris tout en pouvant mettre à jour, modifier et supprimer les profils.

- Gestion des candidatures : l’administrateur peut consulter les candidatures, voir les
résultats des tests de compétences et ainsi approuver ou refuser la demande ; en cas
d’acceptation de candidature planifier une date d’entretien.
- Gestion des tests de compétences : l'administrateur peut créer, modifier et
supprimer les tests (créer des questions et des réponses dont une question peut avoir un
nombre infini de réponses).

- Consultation des statistiques : l'administrateur peut consulter la liste des clients


connectés sur l’application et les informations relatives à leurs utilisations de pages, type
de média de connexion.

2.2. Besoins non Fonctionnels


Les besoins non fonctionnels sont les contraintes sous lesquelles le système doit rester
opérationnel. Il doit répondre à plusieurs exigences parmi lesquelles nous citons :
✓ Contraintes ergonomiques
• Convivialité et facilité d’utilisation : Il faut assurer une certaine facilité de
manipulation et d’accès à l’information pour l’utilisateur. L’interface doit
être bien structurée, claire et simple pour l’utilisateur.
• L’interface doit être compatible avec n'importe quelle dimension d’écran que ce
soit en hauteur ou en largeur, facile à manipuler, et compréhensible.
• Le choix des noms des champs de l’interface doit être explicite et significatif.
✓ Contrainte technique :
• Les erreurs doivent être signalées par des messages d’erreurs clairs et
significatifs.
• Le code développé doit être clair et facile à maintenir.

15
3. Diagramme de cas d'utilisation générale :

Chaque usage effectué par les acteurs est représenté par un cas d’utilisation. Chacun de
ces cas représente une fonctionnalité qui a pour objectif produire le résultat attendu. Ainsi, le
diagramme de cas d’utilisation décrit l’interaction entre le système et l’acteur en subvenant aux
besoins de l’utilisateur et tout ce que doit faire le système pour l’acteur. Ci-dessous, nous allons
présenter le diagramme de cas d’utilisation générale.

Figure 4: Diagramme de cas d'utilisation générale

16
4. Diagrammes de cas d'utilisation et descriptions textuelles :
4.1: Diagrammes de cas d'utilisation détaillés de l'acteur Client :
 
Diagramme de cas d'utilisation « Postuler Offres » :


Figure 5: Diagramme de cas d'utilisation « Postuler Offres »

- Description textuelle :

Tableau 3 : Diagramme de cas d'utilisation "Postuler Offres"

Cas Cas d’utilisation « Postuler Offres »


Acteur Candidat
Précondition Le candidat accède à l’application
Le candidat s’est authentifié correctement à l’application
Post-condition Offres mis à jour
Scénario 1. Le système affiche la page d’accueil
Nominal 2. Le système affiche la liste des nouveautés
3. Le client choisit l’offre affichée et désirée
Scénario Authentification erronée
Alternatif

17
4.2: Diagrammes de cas d'utilisations détaillés de l’administrateur :
 
Diagramme de cas d'utilisation « Gérer Candidats » :


Figure 6: Diagramme de cas d'utilisation « Gérer Candidats »

- Description textuelle :
Tableau 4 : Diagramme de cas d'utilisation "Gérer Candidats"

Cas Cas d’utilisation « Gérer Candidats »


Acteur Administrateur
Précondition L’administrateur est connecté et s’est authentifié correctement à
l’application
Un candidat est ajouté ou supprimé
Un candidat est modifié
Post-condition Liste des candidats mis à jour
Scénario 1.L’administrateur accède à son espace
Nominal 2.L’administrateur complète/modifie les champs du candidat
3.Le système affiche la liste des clients à modifier
4.Le système affiche la liste des clients à supprimer
Scénario Authentification erronée de l’administrateur
Alternatif L’administrateur ne sélectionne aucun utilisateur à supprimer

18
 
Diagramme de cas d'utilisation « Gérer Candidatures » :


Figure 7: Diagramme de cas d'utilisation « Gérer Candidatures »

- Description textuelle :
Tableau 5 : Diagramme de cas d'utilisation "Gérer Candidatures"

Cas Cas d’utilisation « Gérer Candidatures »


Acteur Administrateur
Précondition L’administrateur est connecté à l’application
Une nouvelle candidature est ajoutée
Post-condition Liste des candidatures mis à jour
Scénario 1.L’administrateur accède à son espace
Nominal 2.Le système affiche la page d’accueil
3.L’administrateur choisit la rubrique gestion des candidatures
4.Le système affiche la liste des candidatures respectives aux
offres
5.L’administrateur visionne les informations (résultat tests, CV)
6.L’administrateur exécute son verdict
7.En cas d’approbation, le système affiche le calendrier pour
prise de rendez vous
8.Le système envoi une notification au candidat
Scénario Authentification erronée
Alternatif

19
 
Diagramme de cas d'utilisation « Gérer Actualités » :

Figure 8: Diagramme de cas d'utilisation « Gérer Actualités »

- Description textuelle :

Tableau 6 : Diagramme de cas d'utilisation "Gérer Actualités"

Cas Cas d’utilisation « Gérer Actualités »


Acteur Administrateur
Précondition L’administrateur est connecté à l’application
Une nouvelle actualité est ajoutée
Une actualité existante est modifiée
Une actualité est supprimée
Post-condition Liste des actualités mis à jour
Scénario 1.L’administrateur accède à son espace
Nominal 2.Le système affiche la page d’accueil
3.L’administrateur choisit la rubrique gestion des actualités
4.Le système affiche les fonctionnalités de mis à jour des
actualités
5.L’administrateur saisit les données d’ajout d’une nouvelle
actualité
6.Le système affiche la liste des actualités à modifier
7.Le système affiche la liste des actualités à supprimer
Scénario Authentification erronée
Alternatif L’administrateur ajoute une actualité déjà existante
Le système affiche un message d’erreur suite non-respect de
type de données ajoutées/modifiées
L’administrateur ne coche aucune actualité à supprimer

20
5. Diagrammes de séquence système :
Lors de cette étape, nous décrivons le comportement dynamique du système ainsi que les
différentes interactions entre les acteurs et le système de notre projet. En effet, nous allons
illustrer les principaux scénarios possibles du système au moyen de diagrammes de séquence qui
mettent en évidence l’ensemble ordonné de messages échangés par les objets. Les diagrammes
de séquences sont la représentation graphique des interactions entre les acteurs et le système selon
un ordre chronologique relatif à la formulation UML.

5.1: Diagrammes de séquence système pour l'acteur Client :


 
Diagramme de séquence « Inscription »

Ces diagrammes de séquence représentent le processus d'inscription. Il représente les interactions


entre l'acteur et le système. Le processus commence lorsque le candidat accède à l'application et
demande de s'enregistrer. Une page d'inscription s’affiche et le candidat est mené à saisir ses
données personnelles pour pouvoir accéder à son espace personnel par la suite. Cette opération
se fait pour n’importe quelle personne cible qui accède à l'application.

Figure 9: Diagramme de séquence « Inscription »

21
 
Diagramme de séquence « Postuler à une offre »

Le schéma suivant représente les diagrammes de séquence de processus « Postuler ». Tout


utilisateur doit passer par cette opération pour postuler aux différentes offres de l’Orange

Developer Center.

Figure 10: Diagramme de séquence « Postuler »

22
 
Diagramme de séquence « Consulter actualités »

Le diagramme de séquence ci-dessous modélise le processus consultation des actualités. Il


représente les interactions entre le prospect et le système. Depuis la page d'accueil le prospect
aura la possibilité de choisir la rubrique actualités.

Figure 11: Diagramme de séquence « Consulter actualités »

23
5.2: Diagrammes de séquence système pour l'acteur Administrateur :
 
Diagramme de séquence « Ajouter une offre »

Ce diagramme modélise le processus d'ajout d'une nouvelle offre. Il représente les


interactions entre l’administrateur et le système.

Une page d'ajout s'affiche, l’administrateur ajoute une nouvelle offre en remplissant les
données de cette dernière avec une description textuelle, la lier à un département spécifique, la lier à
une série de tests de compétences et à une date d’expiration.

Figure 12: Diagramme de séquence « Ajouter une offre »

24
 
Diagramme de séquence « Modifier un département »

Ce diagramme de séquence modélise le processus de modification d'un département déjà


existant. Il représente les interactions entre les différents acteurs : une page de gestion des
départements s'affiche après l'authentification de l’administrateur puis en choisissant le
département concerné parmi la liste, l’administrateur effectuera sa tâche et validera.

Figure 13: Diagramme de séquence « Modifier un département »

25
 
Diagramme de séquence « Refuser une candidature »

Ce diagramme de séquence modélise le processus de suppression d'une candidature déjà


existante. Il représente les interactions entre l’administrateur et le système. Le système affichera
la liste des candidatures liés à une offre. Le responsable vérifie le résultat des tests de
compétences, lis le CV et en cas de refus choisis la candidature à supprimer.

Figure 14: Diagramme de séquence « Refuser une candidature »

26
Conclusion :
Dans ce chapitre, nous avons approfondi le niveau de vision du projet et nous a permis de bien
comprendre les tâches à réaliser. Entre autre, on a pu prévoir les problèmes à rencontrer et essayer
de chercher des solutions pour les surmonter.

Nous avons essayé de mettre en valeur les besoins fonctionnels et techniques du projet et les
différents scénarios d'utilisation de l’application.

Le chapitre suivant va mieux clarifier le bon fonctionnement de notre projet à travers la


conception de tous les modules.

27
Chapitre 3 : Conception

Sommaire
Introduction………….….……………………………….29
I. Etude technique………………………………………..29
II. Architecture mise en place……………………………30
III. Diagramme de déploiement………………………….32
IV. Diagramme de classe………………………………...33
V . Diagramme de séquence objet …….………………...34
VI. Diagramme d’activité……………..………………....37
Conclusion…………………………..……………...……38

28
Introduction :
Dans ce chapitre, nous allons présenter la phase de conception de notre projet. Cette partie
a pour rôle de réaliser ce qui a été analysé en le concevant dans un premier lieu, le mettant en
œuvre par la suite et le déployant vers la fin.

Tout d'abord, pour rapprochent encore plus de la réalité physique, nous commençons par
la présentation de diagramme de déploiement. Ensuite, on s'intéresse à la modélisation
dynamique qui traite l'interaction entre les différents objets à travers les diagrammes de séquences
objet. Puis nous présenterons le diagramme de classe objet. Enfin, nous exposons le diagramme
d'activité afin d'identifier le comportement de notre système.

I. Etude technique :
L’architecture de notre application est de type client-serveur où un ordinateur interagit
avec d’autres sur internet ; alors l’architecture la plus adaptée et adoptée pour notre projet est
celle composée de 3 parties :


Une interface web : c'est l'application à travers laquelle l'administrateur ou/et les

candidats pourrons accéder à leurs fonctionnalités.

Un serveur web : C'est le serveur HTTP qui englobe toutes les fichier php, HTML et
Java script . Il assure la communication entre les différents composants de notre projet

tel que l'interface web et la base de donnée Mysql.

Un serveur base de donnée SGBD : On utilise le logiciel MySql, qui contient toutes nos
tables de notre projet, il permet de lire, écrire, modifier, trier, transformer ou même

imprimer les données stockées.

Figure 15: Architecture du projet

29
II. Architecture mise en place :

1. Architecture de la solution :

Notre application est composée de trois couches « 3 tiers ». Il s'agit d'une structure logique
d'architecture applicative qui vise à modéliser une application comme un empilage de trois
couches logicielles (étages, niveaux, tiers…).

Le rôle de chaque couche est :

 La présentation des données : correspondant à l'affichage, la restitution sur le poste de


travail et le dialogue avec l'utilisateur.

 Le traitement métier des données : correspondant à la mise en œuvre de l'ensemble des


règles de gestion et de la logique applicative.

 L'accès aux données persistantes : correspondant aux données qui sont destinées à être
conservées momentanément ou définitivement.

Figure 16: Architecture de l’application

30
1.1: Couche présentation des données :

Elle correspond à la partie visuelle de l’application qui est en interaction directe avec les
utilisateurs. On parle d'interface homme machine. Elle peut être réalisée par une application
graphique ou textuelle. Elle est composée est du code HTML5 et JavaScript.

1.2: Couche métier :

Appelée aussi la couche logique, elle correspond à la partie fonctionnelle de l'application, celle
qui implémente la « logique », et qui décrit les manipulations que l'application traite sur les
données en fonction des requêtes des utilisateurs, réalisées à partir de la couche présentation.

1.3: Couche accès aux données :

C’est la partie gérant l'accès aux données du système et leurs persistances. Ces données peuvent
être propres au système, ou gérées par un autre système.

2. Architecture MVC :
Le patron de conception Modèle-Vue-Contrôleur est un patron de conception architectural [7],
qui organise l'interface utilisateur d'une application en trois composants :

 Un modèle (contenant aussi bien des données que des opérations)

 Une vue (responsable de la présentation aux utilisateurs)

 Un contrôleur, dont le rôle est de gérer les évènements et la synchronisation entre la Vue
et le Modèle

Figure 17: Les éléments du Framework MVC

31
III. Diagramme de déploiement :
Le diagramme de déploiement permet d'illustrer l'architecture physique du système et de
montrer la relation entre ses différentes composantes. Voici le diagramme de déploiement de
notre projet.

Figure 18: Diagramme de déploiement

32
IV. Diagramme de classe :
Le diagramme de classes est le plus important de la modélisation orientée objet, il est le
seul obligatoire lors d'une telle modélisation et permet de monter la structure interne. Il fournit
une représentation abstraite des objets et aspects temporels et dynamiques du système qui vont
interagir pour réaliser les cas d'utilisation.

Une classe est un ensemble de fonctions et de données (attributs) qui sont interreliées par un
champ sémantique. Les classes sont utilisées dans la programmation orientée objet. Elles
permettent de modéliser un programme et ainsi de découper une tâche complexe en plusieurs
petits travaux simples.

Figure 19: Diagramme de classe

33
Ce diagramme présente les différentes classes de notre projet qu'on va utiliser. Chaque
classe est composée d'un ensemble de fonctions et de données (attributs) qui sont liées ensemble
par un champ sémantique.

Les classes peuvent être liées entre elles grâce au mécanisme d'héritage qui permet de mettre en
évidence des relations de parenté. D'autres relations sont possibles entre des classes, chacune de
ces relations est représentée par un arc spécifique dans le diagramme de classes.

V. Diagramme de séquence d'objet :


Le diagramme de séquence d'objet permet de mieux expliquer les différentes interactions
entre l'acteur et les objets de notre projet. Nous allons présenter quelques diagrammes les plus
pertinentes en mettant en évidence l'ensemble ordonné des messages échangées entre les
différents objets.
 
 Diagramme de séquence d'objet pour l'acteur client :
 
Diagramme de séquence d’objet « Inscription »

Figure 20: Diagramme de séquence objet « Inscription »

34
Le candidat accède à l’application. Pour accéder à toutes les fonctionnalités offertes, il
doit s'enregistrer. Il demande le formulaire d'enregistrement et saisie ses données personnelles
pour pouvoir les utiliser par la suite dans la phase d'authentification.

Une fois le formulaire est rempli, le système vérifie ses données. Si elles sont valides,
automatiquement une requête d'ajout d'un nouveau client s'exécute, et ce dernier sera sauvegardé
dans la base de données et la page d'authentification s'affiche.

 
Diagramme de séquence d’objet « Postuler »

Figure 21: Diagramme de séquence objet « Postuler »

35
Après authentification et affichage des détails de l’offre choisie, le candidat commence
par cliquer sur « postuler » puis on lui demande à vérifier son profil pour effectuer des mises à
jour s’il a obtenu des nouvelles compétences ou que son profil est incomplet ; puis confirme pour
passer à l’étape suivante de passer le test de compétence relative à l’offre qui correspond à des
questions avec des choix aléatoires et termine par valider.
 
Diagramme de séquence d'objet pour l'acteur Administrateur :


Diagramme de séquence d’objet « Valider Candidature »

Toute candidature à une offre fait l’objet d’une étude du recruteur/administrateur pour
qualifier le candidat et ainsi procéder à l’étape d’entretien physique par rendez-vous selon
planning.

Figure 22: Diagramme de séquence objet « Valider candidature »

36
VI. Diagramme d'activité :
Les diagrammes d'activité permettent de mettre l'emphase sur les traitements. Ils sont donc
adéquats à la représentation du cheminement de flots de contrôle et de flots de données. Ils
permettent ainsi de modéliser le procédé d'une méthode ou l’enchainement d'un cas d'utilisation.

 
Diagramme d'activité Statistiques :

Pour accéder au différents statistiques, l’administrateur est appelé à saisir son login et son
mot de passe. Si les identifiants ne sont pas validés, l’administrateur est appelé à saisir des
identifiants valides. Sinon, il accède à l’interface d’accueil de l’application. Par la suite, il doit
choisir le menu « statistiques ». Le système vérifie la disponibilité de données. Si les données ne
sont pas disponibles, un message d’erreur s’affiche pour indiquer la non disponibilité des
données. Sinon, le rapport s’affiche. L’administrateur peut, de ce fait, le consulter et il a même
la possibilité de l’exporter sous différents formats.

Figure 23: Diagramme d'activité « Statistiques »

37
 
Diagramme d'activité Supprimer une offre :

La figure ci-dessous illustre le diagramme d’activité pour le cas d'utilisation Supprimer
une offre. Il décrit d'une manière plus simple le déroulement de flux et des événements entre
les différentes étapes de cas d'utilisation.

Figure 24: Diagramme d'activité « Supprimer une offre »

Conclusion :
Dans ce chapitre, nous avons approfondi le niveau de vision du projet. Nous avons terminé
la phase de conception. Dans le chapitre suivant, nous allons passer à la phase réalisation nous
présenterons les différentes technologies que nous avons utilisé. Aussi nous mettrons quelques
captures écrans des interfaces graphiques.

38
Chapitre 4 : Réalisation

Sommaire
Introduction……………………………………………..40
I.Environnement de travail……………………………...40
II.Processus de développement…………………………43
III.Scénarios et tests………………………………….…44

39
Introduction
Après avoir finalisé l’étape de la conception, nous entamons la partie réalisation qui a
pour objectif d’exposer la mise en œuvre de notre application. Pour ce faire, nous commençons
tout d’abord par la présentation de l’environnement de développement et décrire, par la suite,
notre processus de développement et pour finir, nous présenterons un bilan de réalisation et un
récapitulatif sur les stratégies de tests adoptés.

I. Environnement de travail :
Dans cette partie, nous présentons notre environnement matériel et logiciel et nous
concluons par lister les outils et les langages utilisés.

1. Environnement matériel :
Pour réaliser notre application, nous avons utilisé :
* Un micro-ordinateur ayant les configurations suivantes :

- Marque : HP 840 G3
- Processeur Intel(R) Core(TM) i5 CPU vPro @ 2.40 GHz
- Mémoire RAM de 8.00 Go et un disque de 500Go.
- Système d’exploitation 64 bits

Figure 25: Laptop HP 840 G3

40
2. Environnement logiciel :
2.1: WampServer :

Pour qu'on puisse développer notre application web de gestion d'une façon dynamique, il
est primordial d'utiliser un serveur web. Wampserver étant un environnement comprenant deux
serveurs (Apache et MySQL), nous a permis de simuler localement grâce à ses fonctionnalités
comme son interpréteur des scripts PHP et phpMyAdmin pour l'administration Web des bases
MySQL.

Figure 26: Logo WampServer

2.2: HTML :

Pour structurer le contenue (textes, images, liens, etc.) des pages de notre application web
de gestion, nous avons utilisé le langage descriptif HTML. C'est un langage utilisé pour créer des
pages web et réaliser de l'hypertexte à base d'une structure de balisage.
Afin de générer des documents HTML, on a utilisé l'éditeur de code source Notepad++.

Figure 27: Logo HTML

2.3: JavaScript :

Pour améliorer l'ergonomie des interfaces de notre application web, nous avons utilisé le
code JavaScript afin de créer des petits scripts sur les page HTML et ajouter un effet,
généralement, des messages de contrôle des champs. L'exécution de code se fait de sorte qu'il
n'est pas obligatoire de recharger une nouvelle fois la page. Il est effectué par le navigateur web
de l'utilisateur, en d'autres termes c'est l’ordinateur qui recevra le code et qui l'exécutera.

Figure 28: Logo Javascript

41
2.4: PHP :

C'est un langage informatique utilisé sur l'internet qui est principalement utilisé pour
produire un site web dynamique. Il est courant que ce langage soit associé à une base de
données tel que MySQL[10].
Exécuté du côté serveur (l'endroit où est hébergé le site) il n'y a pas besoin aux visiteurs d'avoir
des logiciels ou plugins particulier. Néanmoins, les webmasters qui souhaitent développer un
site en PHP doivent s'assurer que l'hébergeur prend en compte ce langage. Lorsqu'une page
PHP est exécuté par le serveur, alors celui-ci renvois généralement au client (aux visiteurs du
site) une page web qui peut contenir du HTML, XHTML, CSS, JavaScript ...

Figure 29: Logo PHP

2.5 : Framework Laravel :

Laravel est un framework web libre (open-source) écrit en PHP respectant le principe
modèle-vue-contrôleur et entièrement développé en programmation orientée objet [10]. Laravel
est distribué sous licence MIT, avec ses sources hébergées sur GitHub [11].
Laravel fournit des fonctionnalités [12] en termes de routage de requête, de mapping objet-
relationnel (un système baptisé Eloquent implémentant Active Record), d'authentification, de vue
(avec Blade), de migration de base de données, de gestion des exceptions et de test unitaire.

Figure 30: Logo Laravel Framework

42
II. Processus de développement :

1. Développement de l’application :

Le processus de développement commence par l’application. Elle sera utilisée par


l'administrateur et les candidats, chacun, a ses propres fonctionnalités et ses propres identifiants.
Cette application permettra de communiquer avec la base de données et échanger des données
pour faciliter la gestion des candidatures, des actualités, des candidats, et l’obtention des
statistiques.

2. Schéma global :
Afin de simplifier la vue globale de notre solution, nous illustrons le schéma ci-dessous
décrit l’architecture globale du projet.

Figure 31: Schéma global

43
III. Scenarios et tests :
1. Page d’accueil :

C’est la première page lors du premier accès à l’application, pour profiter des fonctionnalités mises
à disposition.

Figure 32: Interface d'Accueil

44
2. Inscription :

La première étape pour les utilisateurs est l’inscription depuis l’interface ci-dessus en saisissant ses
informations personnelles selon des critères bien précis.

Figure 33: Interface d'inscription

45
3. Authentification :
L'authentification est la procédure qui consiste, pour un système informatique, à vérifier l'identité
d'un utilisateur afin de lui autoriser l’accès.

Chacun, a son espace personnel et il devra saisir ses identifiant pour y accéder à ses
fonctionnalités.

ci-dessous une présentation de l'interface authentification

Figure 34: Interface d'authentification

46
4. Espace Administrateur :

Cette interface présente l'espace de gestion pour l'administrateur. A travers cette espace, il pourra
choisir depuis la barre de menu à gauche, l'une des fonctionnalités qui lui sont affectées.

Comme affiché, l'administrateur aura l'accès à la gestion des départements, la gestion des offres,
la gestion des tests de compétences, la gestion des actualités, la consultation des listes des
candidatures et la consultation des statistiques.

Figure 35: Interface espace administrateur

47
5. Gestion des offres :

Cette fonctionnalité permet à l'administrateur de gérer/consulter toutes les offres pour création,
modification, recherche et suppression.

Figure 36: Interface gestion des offres

Pour ajouter/publier une nouvelle offre, l’administrateur accède à cette interface ci-dessous et
ensuite saisir le titre, le département concerné, la date d’expiration et la description.

Figure 37: Interface publication des offres

48
6. Gestion des actualités :

L'une des principales fonctionnalités de l'administrateur est la gestion des actualités. Cette gestion
repose sur l'ajout, consultation ou suppression d'une actualité.

Figure 38: Interface gestion des actualités

Chaque fois que l'administrateur ajoute une nouvelle actualité, il choisit un titre, une description
et une date de publication liée à cette dernière. Les données saisies peuvent être de formats
différents.

Figure 39: Interface Ajouter actualité

49
7. Gestion des départements :

L’administrateur peut créer des départements relatifs aux activités de l’Orange Developer Center,
les modifier et les supprimer en cas de besoin.

Figure 40: Interface gestion des départements

Lors de l’ajout d’un nouveau département, l’administrateur doit spécifier un nom distinctif et
ensuite valider la création.

Figure 41: Interface ajouter un département

50
8. Gestion des Tests de compétences :

Pour créer des tests de compétences, l’administrateur doit créer des questions depuis le Menu

« QCM ».

Figure 42: Interface Accès espace de tests

Depuis le menu « Toutes les questions », l’application lui permet d’ajouter de nouvelles
questions, de les éditer et de les supprimer.

Figure 43: Interface Menu Questions

51
Lors de l’ajout d’une nouvelle question, l’administrateur est obligé de lier la question à une offre,
de saisir le texte de la question, de rédiger des réponses dont une sera la juste et même avoir la
possibilité d’ajouter des extraits de code.

Figure 44: Interface Menu ajout Question

52
Les réponses peuvent être modifiées/supprimées en cas de besoin depuis l’interface « Toutes les
Réponses » et même ajouter de nouvelles réponses pour des questions déjà existantes.

Figure 45: Interface Menu Réponses

Pour ajouter une réponse, suite au clic sur l’action « Ajouter », l’administrateur choisit la question
associée, saisit la réponse et coche si c’est la réponse juste ou non et termine par enregistrer.

Figure 46: Interface ajout Réponses

53
9. Gestion des candidatures :

La même démarche sera effectuée par le responsable du centre en tant qu’administrateur dans le
but de gérer les candidatures. Il a la vision des offres, des résultats des tests, des CV des candidats
et ainsi selon son choix il valide ou refuse ou supprime complètement la candidature.

Figure 47: Interface gestion des candidatures

Dès validation de la candidature, le recruteur est amené à planifier un rendez-vous selon son
planning qui sera communiqué par mail au candidat après enregistrement.

Figure 48: Interface planification rendez-vous

54
10. Consultation des Statistiques :
Pour afficher les statistiques et les informations des visiteurs, l’administrateur accède à la
rubrique « Statistiques » comme affiché ci-dessous et ainsi mieux connaitre les habitudes des
visiteurs et optimiser ou modifier en conséquences.

Figure 49: Interface consultation des statistiques

55
Conclusion et perspectives

A
u terme de ce rapport, nous avons pu dresser le bilan complet de notre travail qui se
situe dans le cadre de notre projet de fin d'études. Ce travail a consisté à concevoir et à
réaliser une application web de gestion des candidatures de Orange Developer Center.

La réalisation de cette application permettra au centre de mieux gérer les demandes


nombreuses des aspirants développeurs pour intégrer le centre en faisant la sélection initiale selon
les compétences testées des connaissances. Le responsable sera en mesure de publier des offres ou
campagnes de recrutement visibles sur le net, d’ajouter les actualités et les évènements du centre
et aussi de mieux gérer son agenda via le système de prise de rendez-vous.

Ce fut une expérience très enrichissante durant laquelle nous avons parcouru les
différentes étapes de réalisation d’une application informatique, de la compréhension du métier au
développement en passant par les étapes d’analyse et de conception.

Ce stage de fin d’étude nous a ainsi donné l’occasion de concrétiser les notions théoriques
acquises durant notre cursus universitaire à ESPRIT : d’approfondir nos compétences et découvrir
le milieu professionnel avec tout ce qu’il implique comme sécurité et veille technologique.

Notre application est aujourd’hui achevée et répond à tous les besoins initialement énoncés.
Toutefois, il reste quelques parties à améliorer que nous citons tels que :

- Intégrer une fonctionnalité de messagerie ou (chat) entre les différents


utilisateurs.
- Intégrer un module e-learning.
- Ajouter Newsletter pour les inscrits.

56
Netographie

[1] https://www.cersa.org/logiciel-de-recrutement/ consulté le 08/07/2017


[2] https://fr.wikipedia.org/wiki/Cycle_de_d%C3%A9veloppement_(logiciel) consulté le 18/11/2017
[3] https://fr.wikipedia.org/wiki/Two_Tracks_Unified_Process consulté le 18/11/2017
[4] https://fr.wikipedia.org/wiki/Extreme_programming consulté le 18/11/2017
[5] https://fr.wikipedia.org/wiki/Scrum_(m%C3%A9thode) consulté le 18/11/2017
[6] https://fr.scribd.com/doc/49697489/Processus-de-Developpement-Y-Processus-2TUP consulté le
18/11/2017
[7] https://fr.wikibooks.org/wiki/Patrons_de_conception/Mod%C3%A8le-Vue-Pr%C3%A9sentateur
consulté le 21/09/2017
[8] http://www.php.net consulté le 21/08/2017
[9] https://getbootstrap.com/ consulté le 01/09/2017
[10] https://laravel.com/docs/5.3 consulté le 13/10/2017
[11] https://github.com/laravel consulté le 13/10/2017
[12] https://www.grafikart.fr/blog/ consulté le 13/10/2017

57
Résumé
Abstract
La sélection des meilleurs profils est un
enjeu majeur pour les entreprises. Ces The selection of the best profiles is a
dernières se retrouvent face à une major challenge for companies. The
problématique difficile à résoudre : latter are faced with a difficult
comment dénicher les meilleurs talents ? problem to solve: how to find the best
Comment trouver les meilleurs candidats talent? How to find the best candidates
en moins de temps ? in less time?
Au cours de notre projet, nous avons During our project, we aim to create a
pour objectif de réaliser une plateforme platform for managing applications for
de gestion des candidatures pour the Orange Developer Center and
l’Orange Developer Center et automate the selection of the best
automatiser la sélection des meilleurs candidates.
candidats. This report will trace the different
Ce rapport va retracer les différentes stages of the realized course,
étapes du parcours réalisé, étude functional study, technical study and
fonctionnelle, étude technique et finir par finish with the design.
la conception. Keywords: MVC architecture, Web
Mots clés: Architecture MVC, Application, Dashboard
Application Web, Dashboard

58