Rapport Final Recruteemnt Finale

Dédicaces
Au symbole de douceur, de tendresse, d’amour et

d’affection, ma mère pour son soutien incessant.
A mon père, pour les sacrifices qu’il a consentis pour

mon éducation.
Que ce travail soit le témoignage de l'amour que je lui avoue.
A mon cher frère Amin qui qui m'a été d'un soutien
indéniable, que dieu te procure bonne santé et une longue
vie.
A mes chers amis qui m'ont soutenue, encouragée et

m'ont surtout permis de travailler dans une atmosphère
joviale.
Soumow
1
Remerciements
C'est avec un grand plaisir que je réserve cette page en signe de gratitude
et de profonde reconnaissance à tous ceux qui m'ont aidé à la réalisation de ce
travail.
Tout d’abord, je tiens à remercier la société OXIA qui m’a accueilli. En

effet j’ai eu le plaisir et l’honneur de travailler au sein d’une aussi grande
entreprise.
J'adresse mes sincères remerciements à mon encadreur Mr Amine

Laroussi, pour sa disponibilité, sa générosité, son encadrement de qualité et pour
tous ses conseils judicieux tout au long de mon projet.
Je remercie également mon encadreur à la Faculté des sciences de Tunis,

Mr Samir Elloumi pour son aide précieux, sa qualité d'encadrement et le savoir
qu'il m'a transmis.
Mes remerciements et reconnaissances s'étendent également à toute la

famille OXIA pour leur chaleureux accueil et particulièrement Mr Khaled Ben
Driss, Directeur Technique chez OXIA, pour sa disponibilité, sa clairvoyance et
son expérience qu’il nous a fait partager, et Mr Mohamed Karim Lili,
développeur chez OXIA, pour tous ses conseils et son soutien moral incessant.
Enfin, je tiens à remercier l'équipe de développeurs, constitué de Mr

Hassen Khalifa et Mr Jed Miled, avec qui j’ai travaillé tout au long de ce projet,
nous avons formé une équipe soudée et homogène dans le but de réussir notre
projet.
2
Table des matières
CHAPITRE 1 PRESENTATION DU CADRE DU PROJET ........................................ 12
INTRODUCTION .................................................................................................................. 13
1. PRESENTATION DE L’ORGANISME D’ACCUEIL .................................................. 13
1.1. MISSION .......................................................................................................................... 13
1.2. DOMAINES DE COMPETENCES .......................................................................................... 14
1.2.1. Finance.................................................................................................................... 14
1.2.2. Solutions de Gestion d’Entreprises ......................................................................... 14
1.2.3. e-business................................................................................................................ 14
1.2.4. Télécommunications ............................................................................................... 14
2. ETUDE DE L’EXISTANT ................................................................................................ 14
3. CRITIQUE DE L’EXISTANT .......................................................................................... 15
4. SOLUTION PROPOSEE .................................................................................................. 15
5. METHODOLOGIE DU TRAVAIL ................................................................................. 16
5.1 METHODE AGILE .............................................................................................................. 16
5.1.1 Définition .................................................................................................................. 16
5.1.2 Valeurs des méthodes Agiles .................................................................................... 16
5.1.3 Principes des méthodes Agiles ................................................................................. 16
5.2 CHOIX DE LA METHODE AGILE SCRUM .......................................................................... 17
5.2.1 Définition .................................................................................................................. 17
5.2.2 Justification du choix ................................................................................................ 17
5.2.3 Mise en œuvre .......................................................................................................... 18
5.2.4 Planification .............................................................................................................. 19
5.2.5 Gestion des besoins .................................................................................................. 20
5.3 CHOIX CONCEPTUELS ....................................................................................................... 21
3
5.3.1 Choix de l’approche Objet ........................................................................................ 21
5.3.2 Langage de modélisation : UML .............................................................................. 22
5.3.3 Outils logiciel de conception .................................................................................... 22
CONCLUSION ....................................................................................................................... 23
CHAPITRE 2 SPECIFICATION DES BESOINS ........................................................... 24
INTRODUCTION .................................................................................................................. 25
1. SPECIFICATION INFORMELLE .................................................................................. 25
1.1. BESOINS FONCTIONNELS................................................................................................. 25
1.2. BESOINS NON FONCTIONNELS ......................................................................................... 26
2 IDENTIFICATION DES CAS D’UTILISATION ........................................................... 26
2.1 Définition ..................................................................................................................... 26
2.2 Diagrammes des cas d’utilisation : Framework .......................................................... 27
2.3 Diagrammes des cas d’utilisation : Workflow Recrutement ....................................... 28
3. VUE DYNAMIQUE : DIAGRAMME D’ACTIVITES .................................................. 34
3.1 DIAGRAMME D’ACTIVITE : FLUX DE TRAVAIL DE RECRUTEMENT .................................... 35
CONCLUSION ....................................................................................................................... 36
CHAPITRE 3 CONCEPTION DE LA SOLUTION ....................................................... 37
INTRODUCTION .................................................................................................................. 38
1. VUE STATIQUE : DIAGRAMME DE CLASSE ........................................................... 38
DESCRIPTION DU DIAGRAMME DE CLASSE .............................................................................. 40
2. DIAGRAMME DE SEQUENCE ...................................................................................... 42
2.1. DIAGRAMME DE SEQUENCE FRAMEWORK ....................................................................... 43
2.1.1. Diagramme de séquence : Administrateur Recrutement ......................................... 43
2.3. DIAGRAMME DE SEQUENCE WORKFLOW RECRUTEMENT ................................................ 45
2.3.1. Diagramme de séquence : Authentification............................................................. 45
2.3.2. Diagramme de séquence : Chargé Recrutement ...................................................... 47
4
2.3. Diagramme de séquence : Evaluateur ........................................................................ 53
CONCLUSION ....................................................................................................................... 54
CHAPITRE 4 REALISATION ........................................................................................... 55
INTRODUCTION .................................................................................................................. 56
1. PRESENTATION DE L’ARCHITECTURE .................................................................. 56
1.1 CHOIX DE L’ARCHITECTURE ............................................................................................. 56
1.2 STRUCTURE DE L’APPLICATION ........................................................................................ 57
1.2.1 Présentation Layer .................................................................................................... 57
1.2.2 Service Layer ............................................................................................................ 58
1.2.3. Business Layer ......................................................................................................... 58
1.2.4. Data Layer ............................................................................................................... 58
1.2.5. Framework ............................................................................................................... 58
1.3 SCHEMA DE DEPENDANCE ENTRE COUCHES ...................................................................... 58
2. ENVIRONNEMENT DE DEVELOPPEMENT ............................................................. 60
2.1. ENVIRONNEMENT MATERIEL ........................................................................................... 60
2.2. ENVIRONNEMENT LOGICIEL ............................................................................................ 60
2.2.1 Framework utilisé ..................................................................................................... 60
2.2.2 Technologies de développement .............................................................................. 62
2.2.3 Langage de développement ...................................................................................... 64
2.2.4 Logiciels utilisés ....................................................................................................... 65
3. SCENARIOS D’EXECUTION ......................................................................................... 68
3.1 INTERFACES DU FRAMEWORK .......................................................................................... 68
3.1.1 Authentification ........................................................................................................ 68
3.1.2 Interface principale ................................................................................................... 69
3.1.3 Paramétrage des acteurs du workflow Recrutement ................................................. 70
3.1.4 Paramétrage des autorisations du workflow Recrutement ....................................... 71
5
3.1.5 Interface d’aide à la saisie : Recherche F12 ............................................................. 71
3.2 PRINCIPALES INTERFACES DU WORKFLOW RECRUTEMENT .............................................. 72
3.2.1 Ecran Candidat ......................................................................................................... 72
3.2.2 Ecran Test/Entretien ................................................................................................. 75
4. GESTION DU PROJET .................................................................................................... 77
CONCLUSION ....................................................................................................................... 78
CONCLUSION GENERALE ............................................................................................... 80
ANNEXES ............................................................................................................................... 82
ANNEXE A : DIAGRAMME DE FLUX DE CANDIDAT ................................................ 83
ANNEXE B : SCHEMATIQUEMENT WORKFLOW RH .............................................. 84
ANNEXE C : UML ................................................................................................................ 85
GLOSSAIRE........................................................................................................................... 87
6
Liste des figures
Figure 1.1 : Logo de OXIA ..................................................................................................... 13
Figure 1.2 : Vue globale du processus Scrum ....................................................................... 21
Figure 1.3 : Emblème de SYBASE PowerAMC ................................................................... 22
Figure 2.1 : Diagramme des cas d’utilisation Framework .................................................. 27
Figure 2.2 : Les cas utilisation du système « Flux de travail de Recrutement » ................ 30
Figure 2.3 : Cas d’utilisation de l’acteur « Chargé Recrutement » .................................... 31
Figure 2.4 : Cas d’utilisation de l’acteur « Assistante de Direction »................................. 33
Figure 2.5 : Cas d’utilisation de l’acteur « Administrateur » ............................................. 34
Figure 2.6 : Diagramme d’activité : Flux de travail de Recrutement................................. 35
Figure 3.1 : Diagramme de classe : Flux de travail de Recrutement .................................. 39
Figure 3.2 : Diagramme de séquence : Administration ....................................................... 43
Figure 3.3 : Diagramme de séquence : Authentification ..................................................... 45
Figure 3.4 : Diagramme de séquence : Insertion Candidat ................................................. 47
Figure 3.5 : Diagramme de séquence : Affichage Candidat ................................................ 49
Figure 3.6 : Diagramme de séquence : Planification Entretien .......................................... 51
Figure 3.7 : Diagramme de séquence : Réalisation Entretien ............................................. 53
Figure 4.1 : Architecture commune d’une application ........................................................ 56
Figure 4.2 : Structure en couche du Framework OXIADOTNET ..................................... 57
Figure 4.3 : Schéma de dépendance entre couches ............................................................... 59
Figure 4.4 : Logo Microsoft .NET .......................................................................................... 60
7
Figure 4.5 : Logo Microsoft Entreprise Library 5.0 ............................................................ 61
Figure 4.6 : Microsoft Visual Studio 2010 Ultimate ............................................................. 65
Figure 4.7 : Microsoft Expression Blend 4 ............................................................................ 66
Figure 4.8 : Oracle ................................................................................................................... 67
Figure 4.9 : Tortoise SVN ....................................................................................................... 67
Figure 4.10 : Interface d’authentification ............................................................................. 68
Figure 4.11 : Interface Principale .......................................................................................... 69
Figure 4.12 : Paramétrage des acteurs du Workflow Recrutement ................................... 70
Figure 4.13 : Paramétrage des autorisations du Workflow Recrutement ......................... 71
Figure 4.14 : Fenêtre d’aide à la saisie .................................................................................. 71
Figure 4.15 : Interface Candidat ............................................................................................ 72
Figure 4.16 : Ecran Ajout Candidat : Informations Personnelles ...................................... 73
Figure 4.17 : Ecrans Ajout Candidat : Niveau Académique et Expérience ....................... 73
Figure 4.18 : Ecrans Ajout Candidat : Références et Certifications .................................. 73
Figure 4.19 : Ecrans Recherche Candidat : Informations Personnelles et Expérience .... 74
Figure 4.20 : Ecran Candidat pour offre .............................................................................. 74
Figure 4.21 : Ecran Candidat : Offre à Faire ....................................................................... 75
Figure 4.23 : Ecran Entretien non planifié ........................................................................... 76
Figure 4.24 : Ecran planifier Entretien ................................................................................. 76
Figure 4.25 : Ecran Test planifié ............................................................................................ 77
Figure 4.26 : Diagramme de Gantt ........................................................................................ 78
8
Figure A.1 : Diagramme de flux de candidat ........................................................................ 83
Figure B.1 : Schématiquement workflow RH ....................................................................... 84
Figure C.1 : Emblème officiel d’UML ................................................................................... 85
9
Introduction Générale
La gestion des ressources humaines occupe aujourd'hui une place prépondérante au

sein de l'entreprise. Sa stratégie permet ainsi aux entreprises de diminuer les risques sociaux
internes à l'organisation comme les grèves, les plans sociaux, les conflits inter salariés. Un
secteur aujourd'hui considéré comme un des maillons les plus importants de l'entreprise. Au
niveau du management général, on cherche à optimiser l'apport des ressources humaines à
partir des éléments par lesquels on agit habituellement sur celles-ci : compétence, motivation,
information, organisation, gestion des groupes.
Le but des ressources humaines est donc de maintenir une gestion efficace des
employés, autant qualitative que quantitative, pour permettre à l’entreprise de prospérer grâce
à un personnel compétent et en nombre suffisant, Ce qui fait de la performance de la fonction
RH (ressources humaines) le cœur des préoccupations actuelles des DRH (direction
ressources humaines). La mesure de la performance dépend naturellement des objectifs fixés à
la fonction.
De ce fait le recrutement, l’une des missions confiées à la fonction RH, s’annonce une
tache de plus en plus ardue, exigeant plus de fiabilité et un temps de gestion minimale avec un
taux de certitudes et d’exactitude maximale.
C’est dans ce cadre que s’inscrit notre projet de fin d’études réalisé chez « OXIA
Tunisie », intitulé : « Conception et réalisation d’une Application de flux de travail de
recrutement ».
Le présent travail se veut une contribution à la mise en place d’une application pour
automatiser les activités du service recrutement. Pour mener à bien la réalisation de cet
objectif, une étude théorique du concept « Flux de travail de Recrutement» s’impose dans le
but de cerner les principales fonctionnalités et comprendre les besoins de la société.
Afin d’illustrer la démarche de notre travail, nous vous présenterons dans ce qui suit
l’organisation générale du rapport. Le présent rapport s’articule autour de cinq chapitres :
Dans le premier chapitre, nous vous exposerons le cadre du projet à travers une
présentation de la société, une étude minutieuse de l’existant (description et critique), pour
enfin conclure avec la solution proposée et la méthodologie utilisée.
10
Le deuxième chapitre sera consacré à la spécification des besoins en termes de besoins
fonctionnels et non-fonctionnels.
Dans le troisième chapitre qui concerne le volet de la conception, on présentera les

différents diagrammes statiques et dynamiques.
Le dernier chapitre sera consacré à la réalisation. L’architecture globale de la solution,

L'environnement matériel et logiciel détaillé du travail seront présentés, ainsi que quelques
captures d’écrans de l'application développée.
Pour conclure, nous présentons les connaissances acquises durant ce stage et nous
proposons comme extension logique de ce projet un ensemble de perspectives.
11
CHAPITRE 1
PRESENTATION DU CADRE DU PROJET
12
Chapitre 1 : PRESENTATION DU CADRE DU PROJET
Introduction
Dans ce premier chapitre, nous présentons l’organisme d’accueil qui est la société
« OXIA », à travers sa Mission, les services qu’elle offre ainsi que les domaines de
compétences qui font sa renommée.
1. Présentation de l’organisme d’accueil
1.1. Mission
Figure 1.1 : Logo de OXIA
OXIA [1] est une société d’ingénierie informatique spécialiste dans les solutions
intégrées d’entreprise. Elle agit sur le marché Tunisien, Européen, et Africain. Elle combine le
savoir-faire métier et l’expertise technique avec des méthodes rigoureuses de conduite de
projet.
OXIA est présente dans les domaines de la finance, la gestion intégrée d’entreprise
(ERP), la logistique, le transport (Supply Chain), le e-business et le conseil en
télécommunication. Elle est forte d’une expertise technique dans divers domaines
technologiques : les architectures d’entreprise, la plate-forme Java, la plate-forme .NET, les
Web Services, l’intégration de systèmes (EAI) sans oublier les technologies client/serveur et
4GL traditionnelles.
13
L’offre d’OXIA s’articule autour du conseil stratégique, le conseil en organisation et

processus, le conseil technologique et la mise en œuvre de solutions progicielles et
spécifiques.
OXIA est notamment certifiée ISO9001:2000 par l’AFAQ pour l’ensemble de ses activités, et
elle est actuellement engagée dans une certification CMMI niveau 3 avec certification SEI.
1.2. Domaines de compétences
1.2.1. Finance
OXIA a acquis une forte expérience dans les domaines du leasing, du factoring et de
l’intermédiation boursière et intervient en tant que cabinet de conseil, d’ingénierie
informatique, et d’intégration de progiciels dans ces trois domaines.
1.2.2. Solutions de Gestion d’Entreprises

OXIA apporte à ses clients une approche qui vise à accroître leur compétitivité et leur
profitabilité. Nous les aidons dans la définition de leur nouveau positionnement stratégique à
travers notre offre de management consulting.
1.2.3. e-business
Une démarche méthodique et des outils performants, fruit d’un processus continu de
recherche et développement, vous permettent de tirer profit du meilleur des technologies
internet afin de mettre en œuvre vos applications B2B, B2C, A2A…
1.2.4. Télécommunications
OXIA a développé une offre de conseil et de pilotage de projets dans le domaine des
télécommunications Voix/Données, et mis l’accent sur les opportunités d’optimisation ou de
réduction des coûts télécoms de ses clients.
2. Etude de l’existant
Le « Système Ressources Humaines » exerce ses activités à travers des requêtes et des
actions offertes par le système d’information actuel OPM. Ce dernier n’offre pas des services
adéquats pour le processus Flux de travail de Recrutement.
14
La planification, la modification, la mise à jour et suivi sont assurés à travers des

fichiers Excel, des fiches papier préparées manuellement et la communication se base par
mail à travers les dossiers de Outlook.
3. Critique de l’existant
Actuellement, la méthode de gestion des recrutements dans le système des ressources

humaines présente plusieurs inconvénients :
 La manipulation avec les fichiers Excel, des fiches ; la communication avec les
dossiers Outlook, ne répond pas à un besoin vital de la Gestion ressource humaine qui
est le suivi du candidat dans tous les états du Flux de travail de Recrutement.
 Risque manifestement présent des erreurs humaines : inattention, oubli, réplication,
perte de document.
 Absence d’un système automatisé robuste pouvant couvrir les activités du Flux de
travail de Recrutement, les états des candidats, des tests et des entretiens, de leur suivi
et de leur historique.
 Absence de contrôle sur le droit d’accès aux fichiers.
 Absence de stockage de données dans des bases de données pour garantir leur sécurité
et leur intégrité.
4. Solution proposée
Dans le but d'accomplir la tache recrutement dans les meilleures des conditions
possibles, notre application vise une amélioration de la gestion des différents candidats, des
tests et des entretiens et du Flux de travail de Recrutement. Notre projet touche au service
ressources humaine ainsi que celui de développement logiciel vu qu'il met à la disposition de
la société une plateforme .net propriétaire et interne. Une interface graphique ergonomique
fondée sur une conception orientée objet engendrant une facilité de gestion tout en satisfaisant
toutes les normes d'accès en préservant les droit d'accès et les privilège de saisie, sauvegarde,
modification et mise à jour, en fait une authentification primaire et primordiale déclenche le
processus de contrôle des droits. Une configuration assez simple et compréhensible offrant à
l'administrateur un environnement complet et sécurisé de gestion de la tache recrutement.
15
5. Méthodologie du travail
La méthodologie adaptée pour la gestion de notre projet a été choisie par le directeur
technique Mr Khaled Ben Driss. Le choix s’est porté sur une méthodologie Agile : Scrum
Dans ce qui suit nous allons définir la méthodologie, pour ensuite présenter ses valeurs
et ses principes. Nous allons aussi justifier l’utilisation de la méthode Agile Scrum.
5.1 Méthode Agile
5.1.1 Définition
Les méthodes Agiles [2] sont des ensembles de pratiques appliquées principalement
sur les projets de développement informatique. Ce sont des méthodes qui se veulent plus
pragmatiques que les méthodes traditionnelles. Elles impliquent au maximum le demandeur
(client) et permettent une grande réactivité à ses demandes. Elles visent la satisfaction réelle
du besoin du client et non les termes d'un contrat de développement. La notion de méthode
agile a été officialisée en 2001 par un document, le Manifeste Agile (Agile Manifesto), signé
par 17 personnalités impliquées dans l'évolution du génie logiciel, en particulier, en tant
qu'auteur de leur propre méthode.
5.1.2 Valeurs des méthodes Agiles

Les quatre valeurs fondamentales Agiles [3] sont :
 l’interaction avec les personnes que les processus et les outils.
 un produit opérationnel qu’une documentation pléthorique.
 la collaboration avec le client que la négociation de contrat.
 la réactivité face au changement que le suivi d'un plan.
5.1.3 Principes des méthodes Agiles

Ces 4 valeurs se déclinent en 12 principes généraux [4] communs à toutes les méthodes
agiles :
 Satisfaction Client en livrant régulièrement des logiciels utiles
16
 Accepter les changements au cours de développement
 livraison fréquente de logiciel (2 à 4 semaines)
 Collaboration quotidienne entre le client et les développeurs
 Motivation des personnes
 Croire en la capacité des développeurs
 Conversation face à face
 Un logiciel fonctionnel est la meilleure façon de mesurer la progression du projet
 Les équipes doivent s'auto-organiser
5.2 Choix de la méthode Agile SCRUM
5.2.1 Définition
Scrum[5] est une méthode agile pour la gestion de projets (principalement le
développement des logiciels). Elle a été conçue pour améliorer grandement la productivité
dans les équipes auparavant paralysées par des méthodologies plus lourdes. Par contre, elle ne
couvre aucune technique d'ingénierie du logiciel, c’est pourquoi il est nécessaire de lui joindre
une méthodologie complémentaire comme l’eXtreme Programming (méthode agile) ou bien
tout simplement les méthodologies de conception d’UML.
5.2.2 Justification du choix

Le choix s’est porté sur Scrum pour plusieurs raisons :
 Présence de 2 stagiaires (en plus de moi-même) pour la réalisation de nos projets de

fin d’études. Ainsi nous avons pu former une petite équipe de développeurs.
 Le besoin de développer un nouveau Framework propriétaire à OXIA à base de la

technologie .NET et pouvoir en profiter éventuellement après pour le développement
d’autres modules. Ce projet pourrait remplacer le système d’information actuelle OPM
(développé avec Centura à base de C++).
17
 La nature des projets de fin d’études : en effet, il s’agit de répondre à des besoins en
interne, c’est ce qui facilite la communication avec le client.
5.2.3 Mise en œuvre
5.2.3.1 Définitions des rôles
La première étape est de définir les rôles au sein de l’équipe :
 Le directeur de produit (Product Owner) : Mr. Amine Laroussi, chef projet à OXIA
et ayant pour tâche de maintenir à jour le Système d’informations d’OXIA. Il est le
représentant des clients et utilisateurs. C'est à lui que revient la tâche de définir l'ordre
dans lequel les fonctionnalités seront développées ainsi que la prise des décisions
importantes concernant l'orientation du projet. Il se trouve au même bureau que
l’équipe de développeurs.
 L’équipe : elle est composée de trois développeurs dont je fais partie. Cette équipe a
eu comme tâche de réaliser le Framework dans lequel on intégrera les différentes
applications dont l’une est le Flux de travail de Recrutement.
Les tâches Framework sont :
 Création de l’interface Graphique de l’Application en WPF4.
 Intégration du Flux de travail de WF4 au Framework.
 Integration du WCF4 (Windows Communication Foundation)
 Conception et réalisation d’une fonction d’aide à la saisie.
 Documentation et Utilisation d’Enterprise Library 5 dans le

Framework.
 Documentation et Choix de design pattern pour la couche d’accès aux

données
 Le facilitateur (ScrumMaster) : ce rôle est également assuré par Mr Amine Laroussi,

il s’est chargé de protéger l'équipe de tous les éléments perturbateurs extérieurs.
18
 Les intervenants (Stakeholders) : Ce sont les personnes qui souhaitent avoir une vue
sur le projet sans réellement s'investir dedans.
o Khaled Ben Driss : Directeur Technique à OXIA, avec qui nous avons des
réunions bihebdomadaire, et qui a suivi de près l’avancement du projet.
o Imed Ayadi : Directeur Général à OXIA, avec qui nous avons eu une réunion
pour la validation des besoins du projet.
 Les clients (Customers): Ceux à qui est offerte l’application.
o Dorra Bouziri : Directeur Ressources Humaines, avec qui nous avons eu trois
réunions pour définir les besoins fonctionnelles de l’application.
o Selma Bellouma : Chargée Recrutement, avec qui nous avons eu deux

réunions pour définir les besoins directes de l’application.
5.2.4 Planification
Scrum permet de définir trois niveaux de planification :
 sprint
 release/projet
 quotidien
5.2.4.1 Les sprints
Scrum est un processus itératif : les itérations sont appelées des sprints qui durent
généralement entre 2 et 4 semaines. Chaque sprint possède un but et on lui associe une liste de
fonctionnalités à réaliser (appelées items de backlog de produit). Ces items sont décomposés
par l'équipe en tâches élémentaires de quelques heures ; les items de backlog de sprint.
Dans notre projet, nous avons opté pour des sprints de deux semaines, suffisant pour
avancer dans nos tâches respectives.
19
5.2.4.2 Releases
Il s’agit de regrouper les itérations (sprints) en unité plus grande portant généralement une
définition sémantique. Dans notre cas, on peut distinguer 3 releases :
 Documentation et définitions de besoins.
 Conception et réalisation du Framework.
 Conception et réalisation du module Flux de travail Recrutement.
5.2.4.3 Quotidien
C’est une réunion quotidienne avec notre ScrumMaster afin de faire un point sur ce
qui a été réalisé la veille, ce que nous devons à faire dans la journée. C’est aussi l’occasion de
discuter des difficultés rencontrées lors de nos tâches respectives.
5.2.5 Gestion des besoins
5.2.5.1 Backlog de produit
Après avoir récolté les besoins fonctionnels des clients, le directeur de produit établit
une liste de fonctionnalités à réaliser, appeléeBacklog de produit.
5.2.5.2 Backlog de sprint
Au départ d’un sprint, Nous choisissons quels items du Backlog de produit seront
réalisés lors de ce sprint. Les items sont décomposés alors en liste de tâches élémentaires.
Chaque tâche est estimée en heures ou en jours. On constitue ainsi le Backlog de sprint.
Pendant le déroulement du sprint, chaque équipier s'affecte des tâches du Backlog de sprint et
les réalise.
Exemple : documentation et réalisation d’un tutoriel sur Enterprise Library 5 en un seul sprint
 Item de Backlog de produit : documentation sur Enterprise Library 5 et réalisation

d’un tutoriel
 Durée du sprint : 2 semaines
 Durée de BackLog sprint : 4 heures
20
 Tâches élémentaires : étudier 5 blocks d’Enterprise Library 5, pour chaque block, il

faut :
o Se documenter
o Réaliser des tests
o Réaliser une démonstration
o Mettre à jour le tutoriel
Le schéma suivant nous donne une idée globale du processus Scrum.
Figure 1.2 : Vue globale du processus Scrum
5.3 Choix conceptuels
5.3.1 Choix de l’approche Objet

Nous avons adopté une approche objet comme mode de conception de notre système
et ce pour les raisons suivantes:
 Les concepts de base de l’approche objet sont stables, normalisés et largement

approuvés.
21
 L’approche objet permet de bénéficier d’une panoplie d’outils et de langages

performants facilitant le développement.
 La modélisation par objet correspond étroitement au monde réel. Il est par conséquent
plus souple pour les modifications.
 Contrairement à l’approche fonctionnelle, l’approche objet représente une solution

destinée à faciliter l’évolution d’applications complexes telles que notre application
”Flux de travail de Recrutement”.
5.3.2 Langage de modélisation : UML

Ayant opté pour une approche objet, le choix d’UML [voir Annexe 3] nous semble une
évidence. En effet, il est reconnu comme étant le standard industriel par excellence de la
modélisation objet. Cela est d’autant plus probant quand nous prenons connaissance qu’UML
unifie à la fois les notations et les concepts orientés objet.
5.3.3 Outils logiciel de conception

Afin de modéliser notre travail en langage UML, nous avions eu recourt à un logiciel
complet de modélisation du nom de « Power AMC » dans sa version 15.
PowerAMC, le n°1 de la modélisation de données, est un outil tout-en-un de modélisation

d'entreprise et de gestion des métadonnées destiné à documenter l'architecture d'entreprise.
Figure 1.3 : Emblème de SYBASE PowerAMC
PowerAMC est un environnement graphique de modélisation d'entreprise très simple d'emploi

qui permet d'effectuer les tâches suivantes :
 Modélisation intégrée via l'utilisation de méthodologies et de notations standards :
22
o Données (E/R, Merise)
o Métiers (BPMN, BPEL, ebXML)
o Application (UML)
o Génération automatique de code via des Template personnalisables
o SQL (avec plus de 50 SGBD)
o Java
o .NET
 Fonctionnalités de reverse engineering pour documenter et mettre à jour des systèmes

existants
 Une solution de référentiel d'entreprise avec des fonctionnalités de sécurité et de

gestion des versions très complètes pour permettre un développement multi-
utilisateurs
 Fonctionnalités de génération et de gestion de rapports automatisés et personnalisables
 Un environnement extensible, qui vous permet d'ajouter des règles, des commandes,
des concepts et des attributs à vos méthodologies de modélisation et de codage.
Conclusion
Dans ce chapitre, nous avons introduit l’entreprise d’accueil « OXIA » en présentant sa

procédure actuelle de recrutement. Nous avons ensuite procédé à une critique de l’existant et
nous avons proposé diverses solutions.
Dans le prochain chapitre, nous allons étudier la spécification de notre projet et nous allons
dresser des diagrammes de cas d’utilisation qui vont décrire les besoins de ce système ainsi
qu’un diagramme d’activité qui va mettre au point l’enchaînement du workflow recrutement.
23
CHAPITRE 2
SPECIFICATION DES BESOINS
24
Chapitre 2 : SPECIFICATION DES BESOINS
Introduction
Ce chapitre renferme une description des besoins du processus recrutement en

spécifiant ceux fonctionnels et non fonctionnels. On y étudiera en premier lieu les différents
diagrammes de cas d'utilisations pour aboutir à une description détaillée du diagramme
d'activité du flux de la tache recrutement.
1. Spécification informelle
L’objectif de ce projet est de concevoir et de réaliser une application de Flux de travail

de Recrutement permettant d’exercer les différentes activités au sein du processus
«Ressources Humaines ».
Comme toute autre application, notre application devrait répondre à certains besoins et
assurer plusieurs fonctionnalités, dégagées suite à des réunions avec les analystes métier, le
chef de projet et du responsable de la société.
1.1. Besoins fonctionnels
Les Besoins fonctionnels de notre application « Flux de travail recrutement » se présentent

comme suit :
- Gérer les candidats : création, modification, suppression.
- Gérer les tests : planification, réalisation, décision.
- Gérer les entretiens : planification, réalisation, décision.
- Gérer le suivi de l’état du candidat dans toutes les étapes : pour test, pour entretien,
retenu à chaud, rejeté, recruté.
- Faciliter la recherche du candidat, du test ou de l’entretien à travers des filtres.
- Assurer l’historique pour une meilleure gestion des statistiques de l’application.
25
1.2. Besoins non fonctionnels
Les besoins non-fonctionnels décrivent le comportement du système dans tous ses

aspects, se focalisant principalement sur les contraintes de temps de réponse de l’organisme
d’accueil (OXIA) vis à vis au client (OXIA). Le développement de l’application qui doit
respecter une architecture en couches, comprend la mise en place d’un Framework à travers
lequel il faut développer le «Flux de travail Recrutement» en tant que module tout en
garantissant l'extensibilité de l'application pour lui permettre accueillir d’autres modules,
d’autres couches, d’autres interfaces.
En fait, parmi les caractéristiques prises en charge dans l'application, on mentionne la

sécurité qui est un besoin primordiale pour préserver l’intégrité des données. On cite aussi la
maintenabilité cohérente et la moins couteuse possible. En effet, la clarté et la lisibilité du
code selon les normes de codage propre à la société, ouvre les horizons de son évolution et
amélioration aisée surtout avec des interfaces ergonomique simples à paramétrer.
En d'autres termes l'application doit faciliter à tous les coups la tache de recrutement
en supportant à la fois un flux de données large et une intervention de plusieurs utilisateurs ce
qui organise la tâche et minimise le temps de réponse des requêtes de l’utilisateur doit être le
plus optimisé que possible pour gagner en productivité.
2 Identification des cas d’utilisation
2.1 Définition
Un cas d’utilisation modélise un service rendu par le système. Il exprime les
interactions acteurs/système et apporte une valeur ajoutée notable aux acteurs.
Il représente une séquence d’actions réalisées par le système. L’identification des cas
d’utilisation se fait en cherchant :
 Les tâches que l’acteur veut que le système exécute.
 Les tâches de création, sauvegarde, modification, suppression ou consultation des

données dans le système par l’acteur.
26
 Les tâches que l’acteur fera pour informer le système des changements soudains ou
externes.
 Les informations que l’acteur doit connaître sur certains événements du système.
 L’ensemble des fonctionnalités du futur système est déterminé en examinant les

besoins fonctionnels de chaque acteur, exprimés sous forme de familles d’interactions
dans les cas d’utilisation.
Dans ce qui suit nous présentons les cas d’utilisation pour chaque acteur défini
précédemment.
2.2 Diagrammes des cas d’utilisation : Framework
Figure 2.1 : Diagramme des cas d’utilisation Framework
Ce diagramme des cas d’utilisation du Framework (figure 2.1) par l’application « Flux de
travail de recrutement » trace la relation entre notre application et le Framework qu’on a
conçu afin de satisfaire ces besoins :
27
 Utilisation de contrôles personnalisés comme le « OXIATextBox » qui hérite du

contrôle textBox de WPF et lui ajoute des méthodes propriétaires au Framework et
utilisables par la suite dans les différentes applications.
 Utilisation de la fonction d’aide à la saisie, recherche F12 : c’est une fonction qui
facilite la recherche en cliquant sur F12 dans le champ personnalisé du Framework, la
fonction de recherche affiche une liste d’attributs souhaités selon ce champ-là.
 Utilisation d’un seul « ToolBar » du Framework, dont les boutons contiennent des
méthodes qui facilitent l’utilisation et le traitement de l’application qui sera intégrée
par la suite.
 Utilisation d’un menu générique à partir de la base de donnée et utilisable par toutes
les applications du Framework.
 Les droits de l’accès sont gérés par la fenêtre authentification du Framewrok, elle gère
ainsi la gestion des profils.
 Le Framework gère l’historique de toutes les opérations effectuées dans les
applications et les stocke dans la base de données par opération, date, heure et
utilisateur.
 Le Framework gère la gestion des favoris, c’est une option donnée aux utilisateurs de
l’application intégrée dans le Framework, ils peuvent sauvegarder une opération qu’ils
voient répétitive par exemple une recherche avec un certain filtrage.
2.3 Diagrammes des cas d’utilisation : Workflow Recrutement
2.3.1 Identification des acteurs
Un acteur est un rôle joué par des entités externes qui interagissent directement avec le
système étudié. L’identification des acteurs se fait en cherchant :
- Les utilisateurs qui fournissent, utilisent ou retirent des informations du système.
- Les utilisateurs qui sont intéressés par un besoin donné.
- Les utilisateurs qui maintiennent le système.
- Les ressources externes du système.
28
- Les autres systèmes qui devront interagir avec le système.
Les spécifications fonctionnelles que nous avons dégagées nous nous ont permises d’identifier
les acteurs principaux suivants :
 Administrateur : Il est le super-utilisateur du système, il possède tous les droits et

privilèges. Il est chargé de paramétrer l’application en affectant les rôles aux différents
utilisateurs. Il se réserve aussi tous les droits d’ajout, de saisie, de mise à jour,
d’édition et de suppression des fiches des candidats, des tests et des entretiens.
 Chargé Recrutement : Personne appartenant au processus« Ressources Humaines »
et à qui est offerte l’application en premier lieu. Le chargé recrutement ajoute et met à
jour les fiches des candidats ; planifie les tests et les entretiens, suit le Flux de travail
de Recrutement dans tous ses états.
 Assistante de Direction : Personne appartenant au processus « Direction », et à
laquelle a été affectée une action. Cette personne aide ne peut que mettre à jour
l’action qui lui concerne.
 Evaluateur : Cette personne a pour tâche d’évaluer le candidat lors de l’entretien, elle
ne peut que modifier la fiche de l’entretien.
 Utilisateur : Cette personne doit pouvoir visualiser, une fois authentifiée, la liste des
candidats et les informations les concernant.
Et les acteurs secondaires suivants :
 SGBD : Le système de gestion de base de données utilisé pour le stockage des
données manipulées. Le SGBD contient aussi la liste des utilisateurs qui manipulent
l’application et la nature de leur droit d’accès.
29
2.3.1 Diagramme du système « Flux de travail de Recrutement »
Parametrer l'application
Administrateur
Gerer les candidats <<include>>
Chargé Recrutement <<include>>
Gerer les Entretiens

<<include>>
S'authentifier <SGBD>
Oracle 8i
Assistante de Direction
<<include>>
Gerer les Tests
<<include>>
<<include>>
Evaluateur
Evaluer
Consulter
Utilisateur
Figure 2.2 : Les cas utilisation du système « Flux de travail de Recrutement »
La relation entre les différents acteurs est une relation de généralisation, ceci implique
l’héritage des cas d’utilisations entre acteurs :
- L’acteur « Utilisateur » : ne peut que consulter l’application.
- L’acteur « Evaluateur » : Il ne peut que modifier la fiche entretien.
- L’acteur « Assistante de Direction » : Gérer les tests en plus des cas d’utilisation
précédemment expliqués avec l’ « Utilisateur ».
- L’acteur « Chargé Recrutement » : Il un rôle fondamentale il gère le candidat, les

tests et les entretiens.
- L’acteur « Administrateur » : c’est le super utilisateur, il peut tout faire ainsi que le
paramétrage de l’application.
Les différents cas d’utilisation seront détaillés par acteur dans la partie suivante.
30
2.3.3 Cas de l’acteur « Chargé Recrutement »
Creer Candidat
<<include>>
Modifier Canddiat
<<include>>
Gérer Candidat <<include>> Recherche Candidat
<<include>>
Supprimer Candidat
<<include>>
Décision Candidat
Planifier Test
<<include>>
Gérer Test <<include>> Réaliser Test
Chargé Recrutement <<include>>
Annuler Test
Planifier Entretien
<<include>>
<<include>> Réaliser Entretien

Gérer Entretien
<<include>>
Annuler Entretien
Figure 2.3 : Cas d’utilisation de l’acteur « Chargé Recrutement »
Description
Après son authentification, le « Chargé Recrutement » est responsable de
- Gérer le candidat
 Créer le candidat
31
 Modifier le candidat
 Rechercher le candidat
 Supprimer le candidat
 Décision du candidat : il s’agit en effet du statut du candidat à savoir pour

test, pour entretien, retenu à chaud, recruté, rejeté.
- Gérer le test
 Planifier test
 Réalisation test
 Annuler test
- Gérer l’entretien
 Planifier entretien
 Réalisation entretien
 Annuler entretien
32
2.3.4 Cas de l’acteur « Assistante de Direction »
<<include>>
Creer Candidat
Gérer Candidat
<<include>> Recherche Candidat
Assistante de Direction
Planifier Test
<<include>>
Gérer Test <<include>> Réaliser Test
<<include>>
Annuler Test
Figure 2.4 : Cas d’utilisation de l’acteur « Assistante de Direction »
Apres son authentification, l’assistante de direction est responsable de :
- Gérer candidat
 Créer candidat.
 Recherche candidat.
- Gérer test
 Planifier test.
 Réaliser test.
 Annuler test.
33
2.3.5 Cas de l’acteur « Administrateur »
Creer les autorisations
<<include>>
Gérer les autorisations
Administrateur <<include>>
Attribuer les autorisations aux profils
Figure 2.5 : Cas d’utilisation de l’acteur « Administrateur »
Description du Cas d’Utilisation « Gérer autorisations »
L’administrateur se charge d’attribuer des autorisations aux personnes concernées qui

accèdent à l’application.
L’administrateur a aussi tous les droits qu’a le chargé recrutement.
3. Vue Dynamique : Diagramme d’activités
Les diagrammes d’activités [10] permettent de mettre l’accent sur les traitements. Ils
sont adaptés à la modélisation du cheminement de flots de contrôle et de flots de données. Ils
permettent ainsi de représenter graphiquement le comportement d’une méthode ou le
déroulement d’un cas d’utilisation. Dans ce qui suit nous allons présenter le diagramme
d’activité du Flux de travail de Recrutement.
34
3.1 Diagramme d’activité : Flux de travail de Recrutement
Creer Candidat
Décision CV [CV rejeté] Rejeter Candidat sur CV

Réaliser Test [Expérience < 3]
[Expérience > 3]
[Test Réussi] Réaliser Entretien

Décision Test
[Candidat pour Entretien]

[Test echoué]
Décision Entretien Rejeter Candidat sur Entretien
Rejeter Candidat sur Test
Placer Candidat Retenu à Chaud

Recruter Candidat
Figure 2.6 : Diagramme d’activité : Flux de travail de Recrutement
Description :
Ce diagramme d’activité (figure 2.6) représente le diagramme d’activité du flux de travail de

recrutement.
Apres la création du candidat, une opération de filtrage de cv se fait pour choisir les candidats
les plus adéquats aux différents profils proposés par OXIA. Suivant le nombre d’années
d’expérience, le candidat est soit mis dans le panier pour test, soit pour entretien.
Si le candidat réussi le test, il est mis pour entretien.
Apres chaque entretien, une note est donné au candidat et une décision est prise ; le candidat
est donc soit redirigé une autre fois vers un autre entretien, soit rejeté, soit mis à chaud, soit
recruté.
35
Conclusion
Dans ce chapitre, nous avons passé en revue les différents besoins exprimés par l’entreprise.
Cela nous a permis de définir la spécification fonctionnelle et non fonctionnelle du système
visé. Dans une deuxième partie, nous avons présenté la phase d’analyse qui nous a conduits à
élaborer les diagrammes de cas d’utilisations ainsi que le diagramme d’activité du flux de
travail du recrutement. Dans le chapitre suivant nous allons concevoir notre système en se
basant sur le langage de modélisation UML.
36
CHAPITRE 3
CONCEPTION DE LA SOLUTION
37
Chapitre 3 : CONCEPTION
Introduction
Dans le présent chapitre, on se base sur le langage UML pour la conception de notre
système d’information. Pour commencer, nous présenterons une conception générale du
système contenant le digramme des classes du système. Ensuite, nous passerons à une
spécification détaillée des fonctionnalités que le système doit assurer contenant l’ensemble
des digrammes de séquences présentant les principales fonctions du système.
1. Vue statique : Diagramme de Classe
Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter les classes et
les interfaces d'un système ainsi que les différentes relations entre celles-ci. Ce diagramme
fait partie de la partie statique d'UML car il fait abstraction des aspects temporels et
dynamiques.
Une classe décrit les responsabilités, le comportement et le type d'un ensemble d'objets. Les
éléments de cet ensemble sont les instances de la classe. C’est aussi un ensemble de fonctions
et de données (attributs) qui sont liées ensembles 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.
38
OffreCandidat
- DateEntréeSouaitée : DateTime
- DateEntréeConfirmée : DateTime
- Candidat : Candidat
0..* - CreateurOffre : User 0..*
Stage
- id_stage : int User
- sujet_stage : string 1..1
1..1 0..1 0..* - user_id : string
- type_stage : string
- nom : string
- societe_stage : string
- prenom : string
- datedebut_stage : DateTime Candidat 0..* - password : string
- datefin_stage : DateTime 0..* - id_candidat : decimal - profil_id : int
1..1 - email_candidat : string 0..* - email : string
- prenom_candiat : string
- nom_candidat : string
- statut_candidat : string
Reference
- source_candidat : string 0..* 0..*
- id_reference : int - CV_candidat : byte 1..1
- nom_reference : string - LettreMotivation_candidat : byte
- societe_reference : string - DateNaissance : DateTime
- email_reference : string 0..* Test
- LieuNaissance : string
- telephone_reference : int 1..* 0..1 0..* - id_test : decimal
- sexe : string
- prenom_reference : string - situatutionfamille : string - type_test : string
- CIN_candidat : int - Date_test : DateTime
- Telephone1 : int - lieu_test : string
- Telephone2 : int - heure_test : TimeSpan EvaluateurInterne
- Bulletin : string - statut_test : string
- remarques_test : string - Poste : string
Certification - Adresse : string
- Bac : string - note_test : int
- id_certification : int - animateur_test : User
- AnneBac : int
- Categorie_certification : string 0..* - DatePlanificationTest : DateTime
- MoyenneBac : float 0..*
- Code_certification : int
1..* - NoteMathBac : float
- Attache_certification : string
- NotePhysiqueBac : float
- Type_certification : string
- NotePhiloBac : float
1..1
- NoteFrançaisBac : float
- DebutExperience : DateTime
- NbAnneeExperience : int Entretien
- StageOxia : string - entretienid : decimal 1..1
Diplome - SIVP : string - dateentretien : DateTime
0..1 0..*
- id_diplome : int 1..* - DateCreationCandidat : DateTime - lieuentretien : string
- Nom_diplome : string 1..* - heureEntretien : TimeSpan
- Institution_diplome : string - StatutEntretien : string Evaluateur_Externe
- Annee_diplome : int - NoteEntretien : string
- Pays_diplome : string 1..* 0..* - EvaluateurExterne_id : decimal
- RemarquesEntretien : string
- Nom_EvalExterne : string
- DecisionEntretien : string
- Prenom_EvalExterne : string
- DatePlanificationEntretien : DateTime
1..1 - EntrepriseEvalExterne : string
- PosteEvalExterne : string
0..*
MotsCles 0..*
- id_motscles : int 0..*
- description_motscles : string
1..1
Profil
0..1
- id_Profil : decimal BA
- description_profil : string 1..1 0..1 BU 1..1 - bA_Id : int
Figure 3.1 : Diagramme de classe : Flux de travail de Recrutement

- bU_Id : int 1..1
- descriptionBA : string
- descriptionBU : string 1..1 0..1 - abreviationBA : string
- abreviationBU : string - directeurBA : User
- directeurBU : User
39
Description du diagramme de classe
La classe Candidat
Elle définit le candidat par son identifiant, nom, prénom, date de naissance, lieu de naissance,
sexe, CIN email, statut, source, cv, lettre de motivation et d’autres attributs.
Cette classe est lié à la classe User afin de préciser l’utilisateur qui a créé le candidat ; elle est
également lié à la classe diplôme, stage, référence, certification, mots clés, offre candidat,
profils, test et entretien.
La classe User
Elle définit l’utilisateur OPM (OXIA Project Manager) à travers user_id, nom, prénom,
password, profil_id et email. La table qui représente cette classe existe déjà dans la base de
données de OXIA.
La classe Test
Elle définit le Test que subit le candidat au cours du flux de travail de recrutement et cela par
un id, type, date, lieu, statut, remarques, note, animateur et date de planification. Elle est en
liaison avec la classe Candidat et la classe User pour préciser l’utilisateur qui planifie le Test
ainsi que l’animateur du Test.
La classe Entretien
Elle définit l’entretien que subit le candidat au cours du flux de travail de recrutement et cela
par un id, date, lieu, statut, note, remarques, décision et date de planification. Elle est en
liaison avec la classe Candidat, Evaluateur interne et Evaluateur externe.
La classe EvaluateurInterne
La classe EvaluateurInterne hérite de la classe User car l’évaluateur interne est un utilisateur
de OXIA. On lui ajoute l’attribut poste.
La classe EvaluateurExterne
Elle est définit par un id, nom, prénom, entreprise et poste. Elle est en liaison avec la classe
Entretien.
40
La classe MotsCles
Elle est définit par id et description. Elle est en liaison avec la classe Candidat. Elle représente
les mots clés du candidat.
La classe Diplôme
Elle définit les diplômes du candidat par un id, nom, institution, année et pays.
La classe Certification
Elle définit les certifications du candidat par un id, catégorie, code, type et un booléen pour
voir si la certification est attachée ou pas au compte OXIA.
La classe Reference
Elle définit les références du candidat par id, nom, prénom, société, email et téléphone.
La classe Stage
Elle définit les stages du candidat par id, sujet, type, société, date début et date fin du stage.
La classe OffreCandidat
Elle définit l’offre du candidat, les attributs sont date entrée souhaitée, date entrée confirmée,
candidat et créateur. Elle est en liaison avec la classe Candidat et la classe User.
La classe BA
Elle définit la classe BA(Business Area) par un BA_id, descriptionBA, abreviationBA et

directeurBA. La table qui représente cette classe existe déjà dans la base de données de
OXIA.
La classe BU
Elle définit la classe BU (Business Unit) par un BU_id, descriptionBU, abreviationBU. La

table qui représente cette classe existe déjà dans la base de données de OXIA.
La classe Profil
Elle définit les profils potentiels que peut avoir le candidat, ces profils sont selon les BA BU.
41
2. Diagramme de séquence
Les diagrammes de séquences sont la représentation graphique des interactions entre les
acteurs et le système selon un ordre chronologique dans la formulation UML (Unified
Modeling Language).
On montre ces interactions dans le cadre d'un scénario d'un diagramme des cas d'utilisation.
Dans un souci de simplification, on représente l'acteur principal à gauche du diagramme, et
les acteurs secondaires éventuels à droite du système. Le but étant de décrire comment se
déroule les actions entre les acteurs ou objets.
Plusieurs types de messages (actions) peuvent transiter entre les acteurs et objets :
 Message simple : le message n'a pas de spécificité particulière d'envoi et de réception.

 Message avec durée de vie : l'expéditeur attend une réponse du récepteur pendant un
certain temps et reprend ses activités si aucune réponse n'a lieu dans un délai prévu.
 Message synchrone : l'expéditeur est bloqué jusqu'au signal de prise en compte par le
destinataire. Les messages synchrones sont symbolisés par des flèches barrées.
 Message asynchrone : le message est envoyé, l'expéditeur continue son activité que le
message soit parvenu ou pris en compte ou non. Les messages asynchrones sont
symbolisés par des demi-flèches.
Par la suite, on va choisir les scénarios les plus importants et on va les modéliser par des
diagrammes de séquences.
42
2.1. Diagramme de séquence Framework
2.1.1. Diagramme de séquence : Administrateur Recrutement
Figure 3.2 : Diagramme de séquence : Administration
43
Acteur : Administrateur.
But : Paramétrage du workflow Recrutement.
Enchaînement nominal :
L’administrateur introduit les paramètres souhaités : les autorisations par rôle et les acteurs de
l’application.
Ces paramètres passent par les différentes couches de l’application.
En effet, à partir de l’interface de paramétrage les données passent par la classe

« RecrutementProcessComponent »s dans la couche « UIProcessComponents », par la suite,
par la couche service WCF. Ils passent après par la classe
« ParametrageBusinessComponent » dans la couche « BusinessComponent », enfin par la
classe « ParametrageDAO » pour lancer la requête vers la base de données.
La requête s’effectue avec sucée, un « MessageBox » s’affiche à l’utilisateur indiquant le

succès de l’opération.
Enchaînement Alternatif :
Dans le cas où la requête échoue, un « MessageBox » s’affiche à l’utilisateur indiquant que

l’opération a échoué.
44
Couche
Service WCF
Ecran Authentification :AuthentificationProcessComponent :ServiceAutentification :Authentification Business Component :UserDAO SGBD
Utilisateur
Introduire (login,password)
GetUserbyIDPC(login,password) GetUserByIdBC(login,password)
GetUserByIdS(login,password) GetUserById(login,password)
Exécution Requete Select()
Verification
alt Opération Réussie
Authentification Réussie
Opération Echouée
2.3.1. Diagramme de séquence : Authentification
Authentification Echouée
2.3. Diagramme de séquence Workflow Recrutement
Figure 3.3 : Diagramme de séquence : Authentification

45
Acteur : Utilisateur.
But : S’authentifier par un login et un password.
1. Consulter l’application.
2. Introduire le login et le password.
3. Vérifier le login et le password dans la base de données en passant par les différentes
couches de l’application.
4. Accepter le login et le password
Le système cherche dans la base de données, ne trouve pas de correspondance et retourne à

l'utilisateur un message d'erreur.
46
Couche
Workflow WF
:UI Candidat :RecrutementProcessComponents :WorkFlow Recrutement :Candidat Business Components :Candidat DAO SGBD
chargé recrutement
InsertionCandidat()
InsertCandidatPC()
2.3.2.1 Insertion Candidat
InsertCandidatS() SendReplyCandidat()
InsertCandidatDAO()
Exécution Requete Insert()
alt Insertion Réussie

Insertion Réussie Insertion Réussie
ReceiveCandidat()
Insertion Réussie
Insertion Réussie
Insertion Echouée
Insertion Echouée
2.3.2. Diagramme de séquence : Chargé Recrutement
Insertion Echouée
Insertion Echouée
Insertion Echouée
Insertion Echouée
Figure 3.4 : Diagramme de séquence : Insertion Candidat

47
Acteur : Chargé Recrutement.
But : Insérer un candidat.
La chargée recrutement introduit les informations concernant le candidat : nom, prénom, date
de naissance, diplôme, etc…
Ces informations seront stockés dans l’entité business « Candidat » de la couche

« BusinessEntities », ensuite, l’entité candidat passera par les différentes couches de
l’application dont la couche Workflow qui assurera le dialogue avec la couche DAO et la base
de donnée.
En effet, à partir de l’interface d’insertion les données passent par la classe

« RecrutementProcessComponents » dans la couche « UIProcessComponents », par la suite,
par la couche Workflow service WF. Ils passent après par la classe
« CandidatBusinessComponent » dans la couche « BusinessComponent », enfin par la classe
« CandidatDAO » pour lancer la requête insert vers la base de données.


l’opération a échoué
48
Couche
Service WCF
:UI Candidat :RecrutementProcessComponents :Service Recrutement :Candidat Business Component :Candidat DAO SGBD
chargé recrutement
AfficherCandidat()
AfficherCandidatPC()
2.3.2.2 Affichage Candidat
AfficherCandidatS() AfficherCandidatBC() AfficherCandidatDAO()

Exécution Requete Select()
Opération Réussie
Opération Réussie
Opération Réussie
Opération Réussie
Opération Réussie
Opération Echouée
Opération Echouée
Opération Echouée
Opération Echouée
Opération Echouée
Opération Echouée
Figure 3.5 : Diagramme de séquence : Affichage Candidat

49
But : Afficher le candidat.
La chargée recrutement choisit le type d’affichage de la liste des candidats par statut :
candidat soumis, pour test, pour entretien, retenu à chaud, pour décision, recruté, rejeté ou
tous les candidats.
Pour afficher la liste des candidats, cette demande doit passer par les différentes couches de
l’application.
En effet, à partir de l’interface de présentation, les données passent par la classe

par la couche service WCF. Ils passent après par la classe « CandidatBusinessComponent »
dans la couche « BusinessComponent », enfin par la classe « CandidatDAO » pour lancer la
requête insert vers la base de données.


50
Couche
Workflow WF
:UI Entretien :RecrutementProcessComponents :Workflow Recrutement :Entretien Business Component :EntretienDAO SGBD
chargé recrutement
PlanifierEntretien()
InsertCandidatPC()
InsertCandidatS() InsertCandidatBC()
InsertCandidatDAO()
2.3.2.3 Planification Entretien
Exécution Requete Insert()

Insertion Réussie Insertion Réussie
Insertion Réussie
Insertion Réussie
Insertion Réussie
Opération Echouée
Insertion Echouée
Insertion Echouée
Insertion Echouée
Insertion Echouée
Insertion Echouée
Figure 3.6 : Diagramme de séquence : Planification Entretien

51
But : Planifier un Entretien.
La chargée recrutement introduit les informations nécessaires à la planification de l’entretien :

candidat, date, heure, lieu et évaluateur.
La planification est en fait l’insertion de nouvel entretien dans la base de donnée, pour ce
faire, un passage par toutes les couches de l’application est obligatoire surtout le passage par
la couche Workflow Service WF qui va créer une instance du workflow sur laquelle va se
faire le flux du travail.
En effet, à partir de l’interface de planification, les données passent par la classe

par la couche workflow service WF. Ils passent après par la classe
« EntretienBusinessComponent » dans la couche « BusinessComponent », enfin par la classe
« EntretienDAO » pour lancer la requête insert vers la base de données.


52
Couche
Workflow WF
:UI Fiche Entretien :RecrutementProcessComponents :Workflow Recrutement :Entretien Business Entities :EntretienDAO SGBD
Evaluateur
RéalisationEntretien()
ModifierEntretienPC()
ModifierEntretienS() SendReplyEntretien()
ModifierEntretienDAO()
Exécution Requete Update()

Opération Réussie Opération Réussie
ReceiveEntretien()
2.3. Diagramme de séquence : Evaluateur
Opération Réussie
Opération Réussie
Opération Echouée
Opération Echouée
Opération Echouée
Opération Echouée
Opération Echouée
Opération Echouée
Figure 3.7 : Diagramme de séquence : Réalisation Entretien

53
Acteur : Evaluateur.
But : Réaliser un Entretien.
L’évaluateur introduit les informations nécessaires à la fiche de l’entretien ainsi que la note
qu’il a attribué au candidat.
L’évaluation est en fait la modification d’un entretien existant dans la base de données.
Néanmoins, on doit passer par toutes les couches de l’application pour faire les modifications
nécessaires.
En effet, à partir de l’interface de réalisation de l’entretien, les données passent par la classe
par la couche service WCF. Ils passent après par la classe « EntretienBusinessComponent »
dans la couche « BusinessComponent », enfin par la classe « EntretienDAO » pour lancer la
requête insert vers la base de données.


l’opération a échoué
Conclusion
Dans ce chapitre, nous avons réalisé les principaux diagrammes représentatifs du déroulement
de notre application ainsi que ses aspects statiques et comportementaux. Ceci nous a permis
de déterminer la façon à travers laquelle nous allons réaliser une application répondant aux
besoins déjà spécifiés.
Dans le chapitre suivant nous présenterons les étapes de réalisation de notre application ainsi
que quelques interfaces représentatives de notre travail.
54
CHAPITRE 4
REALISATION
55
Chapitre 4 : REALISATION
Introduction
Après l’étude conceptuelle du système, nous passons à l’étape suivante; celle du

développement. Nous commençons par présenter les outils matériels et logiciels qui nous
ont permis de développer notre système, ensuite nous allons présenter une vue globale sur
ce dernier, et enfin une présentation de ses principales fenêtres.
1. Présentation de l’architecture
1.1 Choix de l’architecture
Pour la conception de l’architecture, nous avons suivi le guide des bonnes pratiques de
Microsoft pour la conception des architectures d’applications [11]. L’architecture suivante
(figure 4.1) présente le modèle de référence exhaustive pour toute application à développer
avec le langage .NET.
Figure 4.1 : Architecture commune d’une application

1.2 Structure de l’application
Parmi toutes ces couches, pour le besoins de notre application, nous avons implémenté les
couches suivantes :
 Presentation Layer
 Service Layer
 Business Layer
 Data Layer
 Framework.
Figure 4.2 : Structure en couche du Framework OXIADOTNET
1.2.1 Présentation Layer

La couche Présentation est constituée de deux composants :
UI Components : C'est le composant visuel de l'interface. Elle permet d'afficher les

informations à l'utilisateur. Ce sont par exemple les pages ASP.NET, les WinForms, dans
notre cas des interfaces conçues en WPF.
57
UI Process Components : Il permet dans la plupart des cas, l'interaction de l'utilisateur avec le
système qui suit un processus connu. Par exemple, l'utilisateur va choisir une catégorie de
produits avant de sélectionner un produit particulier dans cette liste.
1.2.2 Service Layer

Service Interfaces : Ce composant ouvre le logique métier du système en exposant les services
disponibles. C'est grâce à cette interface qu'on va pouvoir " attaquer " le cœur de l'application.
Cette interface définit les modèles de communication en tenant compte des formats de
données, des exceptions. Dans notre cas, nous avons exposé les services à travers une couche
de communication WCF.
1.2.3. Business Layer

Business Components: Ce composant implémente les règles métier. C’est ici où est
implémenter la logique du métier.
Business Entity: Les composants de l'application doivent pouvoir s'échanger des données. Cet
échange peut se faire par différents formats. Cela peut être des données sérialisés (DataSets,
DataReaders, XML...) ou directement des classes. Ces classes sont appelées aussi POCO,
elles sont sollicitées partout dans l’application.
1.2.4. Data Layer

Data Access Components : C’est le composant qui accède directement à la base de données.
Nous l’avons conçu selon le patron de conception DAO. Il contient les requêtes SQL
permettant de manipuler les données de la base de données.
1.2.5. Framework
Cette dernière couche contient toutes les fonctionnalités propriétaires à notre
application : Contrôles, fonction d’aide à la saisie, gestionnaire d’exceptions, gestionnaire de
journalisation…
1.3 Schéma de dépendance entre couches
Le schéma suivant (figure 4.3) met en évidence la dépendance entre couches lors de la
conception de l’application.
58
Figure 4.3 : Schéma de dépendance entre couches
La liaison entre les différentes couches : (flèche « Référence ») est utilisée pour
décrire les interdépendances entre couches.
Exemple : la couche « Business Components » référence la couche « Business

Entities ».
La couche « Business Entities » contient les entités utilisées partout dans le système.
C’est pourquoi elle est référencée par toutes les autres couches.
La couche « Business Components » contient les classes métier de notre application.
Scénario : obtenir les informations d’un test.
La classe concernée au niveau de la couche « Business Components » : TestBC. Cette classe

a besoin des entités candidat, Test, User se trouvant au niveau de la couche « Business
Entities », d’où l’importance du référencement.
59
2. Environnement de développement
2.1. Environnement matériel
L’environnement matériel qu’on a utilisé se présente comme suit :
 Processeur : Intel® Dual Core CPU T2080 @ 1.73 GHz
 Mémoire RAM : 3 Go
 Disque Dur : 120 Go
 Carte Graphique : Mobile Intel 45 Express Chipset Family
 Système d’Exploitation : MS Windows SEVEN 32-bit.
2.2. Environnement logiciel
2.2.1 Framework utilisé
.NET Framework 4.0
Figure 4.4 : Logo Microsoft .NET
Le Framework .NET est un produit Microsoft, société avec laquelle OXIA est
partenaire. Ce choix rentre dans une stratégie d’entreprise désirant implémenter entièrement
son système d’information à base de Framework .NET. Notre projet constitue ainsi un projet
pilote pour d’autres entreprises de plus grande taille.
Le choix s’est porté sur la version 4.0.Microsoft a annoncé la version 4 du Framework

.NET le 12 avril. Cette version offre comme nouveautés :
 Autorisations des paramètres nommés et optionnels
60
 Prise en charge totale des langages IronPython, IronRuby et F #.
 Prise en charge d’un sous-ensemble du Framework .NET et ASP.NET avec la variante

"Server Core" de Windows Server 2008 R2.
 Intégration de la plate-forme de modélisation Oslo.
 Inclusion de nouveaux types de travailler avec précision arbitraire arithmétique

(System.Numerics.BigInteger) et les nombres complexes
(System.Numerics.Complex).
Microsoft Enterprise Library 5.0
Figure 4.5 : Logo Microsoft Entreprise Library 5.0
Enterprise Library [12] est un Framework contenant plusieurs blocs d'application. Ils
permettent de résoudre les problèmes courants auxquels on est confronté lorsqu'on développe
un projet. Les applications blocs encapsulent les méthodes de développement recommandées
par Microsoft (" best practices "). Enterprise Library contient 6 blocks d'application :
 Caching
 Cryptography
 Data Access
 Exception Handling
 Logging
 Security
Enterprise Library inclut également un ensemble de fonctions fondamentales, notamment

des services de configuration, d'instrumentation et de création d'objets. Ces fonctions sont
utilisées par tous les autres blocs d'application.
61
Il y a plusieurs avantages à utiliser le Framework Enterprise Library :
 Uniformité : Tous les blocs d'application utilisent les design patterns.
 Extensibilité : Les blocs d'application permettent d'être personnalisés en offrant la

possibilité d'ajouter du code dans les classes fournies.
 Facile d'utilisation : Enterprise Library contient un outil graphique de configuration,

une installation simple, une documentation utilisateur et des exemples d'application.
 Intégration : Les blocs d'application d'Enterprise Library sont conçus pour

communiquer ensemble.
 Gratuité : Enterprise Library est redistribué gratuitement.
Pour le besoin de notre application nous avons utilisé tous les blocks sauf celui de
cryptographie :
 Accès à la base de données (Block Data Access Application)
 Gestion d’accès des utilisateurs par les autorisations (Block Security Application)
 Gestion des exceptions (Block Exception Handling Application)
 Journalisation des exceptions et des événements sur des fichiers (Block Logging
Application)
 Enregistrement des données dans le cache de l’application (Block Caching

Application)
Le choix s’est porté sur la version 5 d’Enterprise Library car c’est la seule version qui
fonctionne avec le Framework .NET 4.0. Cette version d’Enterprise Library a été publiée le
20 Avril 2010.
2.2.2 Technologies de développement
WPF (Windows Presentation Foundation)
Windows Presentation Foundation (WPF) [13] est un sous-système graphique conçu pour le
rendu des interfaces utilisateur dans les applications basées sur Windows. Conçu pour
62
supprimer les dépendances sur le vieillissement du sous-système GDI, WPF est construit sur
DirectX, qui fournit l'accélération matérielle et permet les fonctions modernes de l'interface
utilisateur telles que la transparence, dégradés et transformations. WPF fournit un modèle de
programmation cohérent pour générer des applications et offre une séparation claire entre
l'interface utilisateur et le logique métier.
WPF offre également un nouveau langage de balisage, appelé XAML, qui est un autre
moyen pour définir les éléments d'interface utilisateur et les relations avec les autres éléments
de l’interface utilisateur. WPF peut être déployé sur le bureau ou hébergé dans un navigateur
web. Il permet également le contrôle riche, la conception et le développement des aspects
visuels de programmes Windows. Il vise à unifier un certain nombre de services applicatifs :
interface utilisateur, dessins 2D et 3D, documents fixes et adaptatives, typographie avancée,
graphiques vectoriels, raster graphique, animation, la liaison de données, audio et la vidéo.
WPF est inclus avec Windows 7, Windows Vista et Windows Server 2008 et est également
disponible pour Windows XP Service Pack 2 ou ultérieur et Windows Server 2003.
WCF (Windows Communication Foundation)
Windows Communication Foundation (WCF) [7] est la nouvelle technologie de

développement d’applications distribuées interopérables, fiables et sécurisées. L’objectif de
WCF est d’unifier les modes de communication que l’on a aujourd’hui à notre disposition
(services web, accès à distance, etc.) grâce à un nouveau modèle de programmation orienté
services.
WCF est utilisé dans notre application au niveau de la couche, son fonctionnement
consiste à implémenter des contrats de services permettant ainsi de relier la couche Business
Layer (Business Component) à la couche présentation (UI process Component).
WF4 (Windows Workflow Foundation)
Windows Workflow Foundation (WF) [8] est une technologie de Microsoft pour la
définition, l'exécution et la gestion des workflows. Tout d'abord, cette technologie a été
publiée en novembre 2006 dans le cadre du .NET Framework 3.0.
63
Un programme basique de workflow est comme les programmes traditionnels qui

permettent de coordonner les travaux et d'effectuer des opérations mais a quelques différences
près :
 Les Workflows utilisent un modèle déclaratif d'écriture de programmes en reliant un

ensemble prédéfinies d'activités plutôt qu'un modèle de programmation impératif
d'écriture.
 Les Workflows peuvent gérer un travail de longue durée par la persistance d’un
magasin durable, comme une base de données, lorsque inactif et se charger encore une
fois quand il y a du travail à effectuer.
 Un Workflow peut être modifiée dynamiquement lors de l'exécution lorsque de

nouvelles conditions nécessitent qu’un workflow se comporte différemment que
lorsqu'il a été créé.
 Les Workflows fournissent une séparation distincte des règles métier et de code de
l'application hôte, ce qui la rend plus facile à modifier.
 Un Workflow prend en charge les workflows séquentiels pour les systèmes avec une
logique séquentielle et workflows de machine d'état pour les systèmes basés sur
l'événement logique.
Les Workflows ont généralement une contrepartie visuelle qui permet une description de
l'organigramme de leur logique
2.2.3 Langage de développement
Langage C#
Le C# (prononcé C-Sharp) est un langage de programmation orienté objet à typage

fort, créé par la société Microsoft, et notamment par l’un de ses employés, Anders Hejlsberg,
le créateur du langage Delphi.
Il a été créé afin que la plate-forme Microsoft .NET soit dotée d'un langage permettant
d'utiliser toutes ses capacités. C# 4.0 est la dernière version de la programmation langage C#,
elle a été publiée le 12 avril 2010.C’est la version que nous avons utilisé pour notre
développement.
64
Langage XAML
XAML [11] est un langage déclaratif basé sur le langage XML. Prononcé Zammel, ces
initiales correspondent à eXtensible Application MarkupLanguage.
XAML facilite le travail du développeur et permet d'écrire une application client

Windows aussi aisément qu'une application web. L'idée est en effet de séparer la déclaration
des objets d'un programme du code sous-jacent comme cela est déjà le cas dans les
applications Web de type ASP.NET.
Dans le cas de XAML pour WPF, le développement de l'interface utilisateur étant

confié à des designers, Microsoft propose à ceux-ci le logiciel Expression Interactive
Designer pour manipuler cette interface. XAML inclut également des fonctionnalités pour
manipuler des objets en trois dimensions, de manière analogue à X3D.
2.2.4 Logiciels utilisés
Microsoft Visual Studio 2010 Ultimate
Figure 4.6 : Microsoft Visual Studio 2010 Ultimate
Microsoft Visual Studio 2010 Ultimate est la suite complète d'outils de gestion du cycle de
vie application permettant aux équipes de garantir des résultats de qualité, de la conception au
déploiement. Si vous créez de nouvelles solutions ou améliorer les applications existantes,
Visual Studio 2010 Ultimate permet de vous faire vivre un nombre croissant de plates-formes
et de technologies de ciblage de votre vision — y compris l’informatique dans les nuages et le
calcul parallèle.
Visual Studio 2010 Ultimate présente divers fonctionnalités :
 Application Lifecycle Management (ALM)
65
 Débogage et diagnostics
 Outils de test
 Architecture et modélisation
 Développement de base de données
 Environnement de développement intégré
 Prise en charge des plates-formes de développement
 Team Foundation Server
 Lab Management
 Abonnement MSDN
Microsoft Expression Blend® 4
Figure 4.7 : Microsoft Expression Blend 4
Microsoft Expression Blend est l'outil professionnel de conception d'interfaces utilisateurs de

Microsoft pour créer des interfaces graphiques riches orientées Web pour des applications de
bureau mêlant le meilleur du Web et du poste de travail. Expression Blend est écrit en
utilisant le .NET Framework 3.0 et le Windows Presentation Foundation (WPF).
Le nom de code de ExpressionBlend était Sparkle. À l'origine le produit a été annoncé en tant
que Microsoft Expression Interactive Designer, avant qu'il ne soit renommé en Expression
Blend en décembre 2006.
Expression Blend supporte le moteur des textes de WPF avec une typographie OpenType
avancée, le ClearType, les gadgets 2D vectorisés, et les gadgets 3D avec accélération
matérielle par l'intermédiaire de DirectX. Expression Blend est écrit entièrement en Windows
66
Presentation Foundation à l'opposé des anciennes technologies comme le GDI ou GDI+.

Expression Blend fait partie de la suite Microsoft Expression Studio.
Oracle 8i
Figure 4.8 : Oracle
Oracle est un système de gestion de base de données relationnel (SGBDR) qui depuis
l'introduction du support du modèle objet dans sa version 8 peut être aussi qualifié de système
de gestion de base de données relationnel-objet (SGBDRO).
Oracle est un SGBD permettant d'assurer :
 La définition et la manipulation des données

 La cohérence des données
 La confidentialité des données
 L'intégrité des données
 La sauvegarde et la restauration des données
 La gestion des accès concurrents
TortoiseSVN
Figure 4.9 : Tortoise SVN
C’est un logiciel client de SVN (Système de gestion des versions). Il a permis à tous
les membres de l’équipe de développeurs de travailler sur un seul projet commun hébergé sur
un serveur.
En s'intégrant dans l'explorateur de Windows, TurtoiseSVN offre aux utilisateurs de

Windows une interface graphique permettant de réaliser la plupart des tâches qu'offre SVN en
ligne de commande.
67
L'explorateur Windows s'enrichit des fonctionnalités suivantes :
 Superposition d'icône aux répertoires et fichiers permettant de visualiser

instantanément l'état (à jour, modifié, en conflit...)
 Menu contextuel permettant de faire la mise à jour et de confirmer la modification, à

l'échelle d'un fichier, d'une sélection de fichiers ou encore d'un répertoire
 Possibilité d'ajouter en mode détails de l'explorateur des colonnes de type numéro de

révision
3. Scénarios d’exécution
3.1 Interfaces du Framework
Dans cette partie, nous allons décrire les différentes interfaces propre au Framework qu’on a
conçu, et donc ces interfaces sont utilisées par toutes les applications intégrées dans le
Framework, dont notre application « Workflow Recrutement ».
3.1.1 Authentification
Figure 4.10 : Interface d’authentification
Cette interface (figure 4.10) est la première fenêtre lors du lançant l’application.
L’utilisateur est invité à saisir son login et mot de passe pour pouvoir accéder. Une fois
authentifié l’utilisateur accède à la fenêtre principale de l’application.
68
3.1.2 Interface principale
Figure 4.11 : Interface Principale
Cette interface (Figure 4.11) constitue la première interface lancée une fois
l’utilisateur authentifié. Chaque utilisateur possède un ensemble d’autorisations. Une
autorisation est une combinaison entre un profil et un module.
Le menu à gauche (1) permet d’afficher les modules auxquels l’utilisateur est autorisé.
En cliquant sur un module, une liste de liens apparaît dans la barre à gauche (2). Ces liens
sont ordonnés dans un ordre hiérarchique sous forme d’arbre.
En cliquant sur un lien, la fenêtre associée apparaît à l’interface principale dans la zone
(4).
La barre d’outils (3) offre plusieurs possibilités à travers des boutons dont l’activation
dépend de l’écran en cours. Parmi ces fonctionnalités, on peut trouver : Le retour à la page
d’accueil, l’enregistrement, la recherche, la mise en forme, l’impression, l’ajout, la
modification, le rafraîchissement des valeurs de l’écran, la suppression, l’affichage de
l’historique, l’export sous format Word (.doc), l’export sous format Excel (.xls), la validation,
l’annulation, l’ajout à la liste de favoris, l’affichage d’informations.
69
3.1.3 Paramétrage des acteurs du workflow Recrutement
Figure 4.12 : Paramétrage des acteurs du Workflow Recrutement
A travers cette interface (figure 4.12), le paramétrage devient une tache simple et facilement
accessible. En effet, elle permet d’ajouter, modifier ou supprimer un utilisateur dans la liste de
rôles du workflow recrutement et ceci en cliquant avec le bouton droit de la souris
directement sur la grille qui contient les utilisateurs de chaque profil.
70
3.1.4 Paramétrage des autorisations du workflow Recrutement
Figure 4.13 : Paramétrage des autorisations du Workflow Recrutement
A travers cette interface (figure 4.13), le paramétrage des autorisations devient une tache
simple et facilement accessible. En effet, il suffit de cocher le droit de chaque profil ensuite
cliquer sur valider dans la ToolBar.
3.1.5 Interface d’aide à la saisie : Recherche F12
Figure 4.14 : Fenêtre d’aide à la saisie
Cette interface (figure 4.14) est conçue pour faciliter la recherche.
71
En effet, après avoir placer le curseur de la souris sur le champs de texte souhaité pour la
recherche, en cliquant sur F12, une liste d’attributs souhaités s’affiche.
3.2 Principales interfaces du Workflow Recrutement
3.2.1 Ecran Candidat
Figure 4.15 : Interface Candidat
Cet écran (figure 4.15) s’affiche quand on clique sur Candidat dans le menu à gauche.
La grille au milieu affiche la liste de candidats selon le statut du candidat souhaité : candidat
soumis, pour test, pour entretien, pour offre, retenu à chaud, recruté ou rejeté.
72
3.2.1.1 Ecran Ajout Candidat
Figure 4.16 : Ecran Ajout Candidat : Informations Personnelles
Figure 4.17 : Ecrans Ajout Candidat : Niveau Académique et Expérience
Figure 4.18 : Ecrans Ajout Candidat : Références et Certifications
73
Ces écran (figure 4.16, 4.17 et 4.18) sont conçu pour ajouter un candidat, ajouter tous les
détails des candidats : ses informations personnelles, son niveau académique, son expérience,
ses stages, ses références et ses certifications.
3.2.1.2 Ecran Affichage et Modification Candidat
Les écrans d’affichage et de modification sont les mêmes que ceux de l’insertion avec en plus
la possibilité de choisir l’ID du candidat au début pour pouvoir afficher directement les détails
de ce candidat.
3.2.1.3 Ecran Recherche Candidat
Figure 4.19 : Ecrans Recherche Candidat : Informations Personnelles et Expérience
Ces écrans (figure 4.19) sont conçus pour faciliter la recherche du candidat selon des filtres
informations personnelles et synthèse expérience professionnelle. L’utilisateur introduit les
paramètres de recherche qu’il veut et ensuite il clique sur valider. Il obtient comme résultat
une liste de candidats selon les informations qu’il a introduites.
3.2.1.4 Candidat pour Offre
Figure 4.20 : Ecran Candidat pour offre
74
Cet écran (figure 4.20) sert à choisir les candidats pour offre. Quand on clique sur le bouton
valider après avoir choisi le candidat pour offre, un autre écran s’affiche : écran offre à faire
(figure 4.21).
Cet écran précise des informations concernant le profil à proposer au candidat.
Figure 4.21 : Ecran Candidat : Offre à Faire
3.2.1.5 Ecrans Candidat pour Test/pour Entretien/Recruté/Rejeté
Ces écrans contiennent tous des grilles de données qui affiche chacune la liste de candidat
selon son statut. Chaque écran contient également la tache suivante à faire.
Exemple : la tâche qui suit l’état « pour Test » c’est la planification du Test.
3.2.2 Ecran Test/Entretien
Figure 4.22 : Ecran Test/Entretien
75
Cet écran (figure 4.22) s’affiche quand on clique sur Test(ou Entretien) sur le menu de
gauche.
La grille au milieu affiche la liste de tests (ou d’entretiens) selon le statut du Test (ou de
l’entretien).
3.2.2.1 Ecran Test/Entretien non Planifié
Figure 4.23 : Ecran Entretien non planifié
Cet écran (figure 4.23) affiche les entretiens non planifiés, si on coche les entretiens à
planifier et on clique sur valider, un écran de planification du test ou de l’entretien (figure
4.24) s’affiche permettant d’introduire les différentes informations concernant le test ou
l’entretien.
Figure 4.24 : Ecran planifier Entretien
76
3.2.2.2 Ecran Test/Entretien Planifié
Figure 4.25 : Ecran Test planifié
Cet écran (figure 4.25) affiche la liste des candidats qui ont un test planifié. Dans la grille de
données, on peut cocher les cases « Réaliser le Test », « Reporter le Test » ou « Annuler le
Test » ensuite cliquer sur le bouton valider pour valider le choix et passer à l’état suivant du
workflow.
3.2.2.3 Ecran Test/Entretien Réalisé/Reporté/Annulé
Ces écrans sont semblables. Ils contiennent une grille de données qui affiche les candidats
suivant le statut du test ou de l’entretien : réalisé, reporté ou annulé.
4. Gestion du projet
Etant gérer par le processus Scrum, notre projet est organisé en sprints d’une durée de
deux semaines, une durée que notre ScrumMaster a jugée raisonnable pour que tous les
membres de l’équipe réalisent leurs tâches respectives. À chaque sprint, nous étions amenés à
réaliser un item de Backlog produit. La liste suivante présente les Backlog produit :
 Apprentissage et Documentation (Langage WPF, WF, Enterprise Library 5, Couche

Persistance)
77
 Conception et réalisation du Framework (Interface IHM, ToolBar avec Interface en

WPF, ToolBox en WPF générée à partir de la Base de données).
 Conception et Réalisation flux de travail de Recrutement (Développement des entités

POCO, Développement de la Couche DAO, Diagramme de classes, Développement
des interfaces)
En parallèle, nous avons élaboré ce rapport de Projet de fin d’études.
A noter également qu’après chaque réunion avec le client, il nous est demandé de
préparer un compte rendu de réunion et de mettre à jour le document de spécifications
fonctionnelles. La démarche suivie pour élaborer ce document se base principalement sur des
captures d’écrans pour illustrer les différentes fonctionnalités de l’application, chaque capture
est accompagnée d’un tableau décrivant les paramètres illustrés par l’écran.
La figure ci-dessous (figure 4.26), présente un diagramme de Gantt, qui est

l’illustration des efforts impartis à chaque phase du projet.
Figure 4.26 : Diagramme de Gantt
Conclusion
Cette dernière partie de rapport nous a permis de présenter l’architecture adoptée pour
structurer notre application. Nous avons aussi présenté l’environnement matériel et logiciel de
l’application, notamment l’utilisation des Framework .NET 4.0 avec les outils les plus
récents.
78
Nous avons ensuite enchaîné avec la partie démonstration qui rassemble quelques captures
d’écran de l’application développée. La fin du chapitre a été consacrée à la présentation de
notre planning de projet en diagramme de Gantt.
79
Conclusion Générale
L’objectif de notre projet de fin d’étude consiste en la modélisation et la mise en œuvre des
Processus workflow de la gestion de recrutement avec le Framework Windows Workflow

Foundation. Un tel projet vise à construire une plateforme solide « OXIADOTNET »,
propriétaire à la société, intégrant une diversité d’autres modules bénéficiant ainsi de la
richesse et de la fluidité du Framework .NET.
Durant notre projet, nous avons eu pour mission, dans une première étape, l’étude du
Framework WF4 en mettant l’accent sur ses services et son environnement d’exécution, puis
nous avons procédé au recensement des besoins et évoqué les fonctionnalités que OxiaDotNet
peut offrir.
Dans la deuxième étape, nous avons modélisé les processus métiers de la gestion du
recrutement. La dernière étape consistait en la mise en œuvre d’une application WPF qui gère
la totalité des taches relatives au recrutement et dont le service ressource humaine en est
responsable.
Ainsi, au terme de ce projet, nous sommes parvenues à mener une étude analytique et
conceptuelle du Framework OXIADOTNET et achever la modélisation des processus métiers.
Outre, nous avons réussi à nous familiariser avec le développement des Workflows sous WF4
en implémentant l’application hôte des processus Workflows.
Ce projet de fin d’étude a constitué, pour nous, une occasion intéressante d’acquérir de
nouvelles connaissances dans le domaine de gestion de recrutement, la modélisation des
processus Workflows et leurs mise en œuvre sur le Framework Windows Workflow
Foundation 4.
En perspective, nous essayerons de compléter l’implémentation des fonctionnalités conformes

au processus de recrutement de départ. Et améliorer au fur et à mesure l’intégralité des taches
du service ressources humaine.
Bibliographie/Netographie
Netographie
[1] http://www.oxiasoft.com
[2] http://fr.wikipedia.org/wiki/Méthode_agile
[3] http://agilemanifesto.org
[4] http://agilemanifesto.org/principles.html
[5] http://fr.wikipedia.org/wiki/Scrum
[6] http://www.mountaingoatsoftware.com
[7] http://msdn.microsoft.com/fr-fr/netframework/aa663324.aspx
[8] http://msdn.microsoft.com/en-us/netframework/aa663328.aspx
[9] http://www.commentcamarche.net/contents/oracle/oracintro.php3
Bibliographie
[10] UML 2 par la pratique, 4ème édition, Pascal ROQUES Editions Eyrolles
[11] Microsoft Application Architecture Guide 2ndEdition, ISBN: 9780735627109 Microsoft

Corporation
[12] The Definitive guide of Microsoft Enterprise Library, Keenan Newton ISBN: 10: 1-59059-
655-2
[13] WPF par la pratique, Thomas Lebrun ISBN : 978-2-212-12422-4 Editions Eyrolles
81
Annexes
82
Annexe A : Diagramme de flux de candidat
Processus Recrutement
Besoin en recrutement Gestion des entretiens Finalisation du recrutement Intégration Evaluation Titularisation
Manager
Réalisation des Evaluation poste

Besoin en Intégration
entretiens de recrutement après
recrutement Spécifique
Directeur Engagement/
recrutement(3) 3 mois
Demande Fiche
d’ouverture Plan Fiche
Opérations/SSC
évaluation évaluation
de poste intégration
entretien
Description de
Poste
NOK
Décision
Validation Validation
NOK
DG BA
NOK
OK OK
Direction Ressources
Préparation offre
Humaines
Recherche de Réception des Décision de Intégration Arrêt du contrat

& éléments
profils candidatures recrutement générale
contractuels Plan
Sites Annonce Contrat de intégration
emploi/ Boîte RH Offre emploi
Presse travail
Atuge
Technique compte
Responsable
Préparation arrivée
nouvelle recrue
(compte réseau,droits
d’accès, boîte
mail...etc
Figure A.1 : Diagramme de flux de candidat
83
Annexe B : Schématiquement workflow RH
Figure B.1 : Schématiquement workflow RH
84
Annexe C : UML
Figure C.1 : Emblème officiel d’UML
UML [10] est la forme contractée de « Unified Modeling Language », qui peut se
traduire en français par langage unifié pour la modélisation. UML représente l’état de l’art des
langages de modélisation objet. Il fournit les fondements pour spécifier, construire, visualiser
et décrire un système logiciel. Pour cela, UML se base sur une sémantique précise et sur une
notation graphique expressive. Il définit des concepts de base et offre également des
mécanismes d’extension de ces concepts.
UML est un langage de modélisation objet. En tant que tel, il facilite l’expression et la
communication de modèles en fournissant un ensemble de symboles (la notation) et de règles
qui régissent l’assemblage de ces symboles (la syntaxe et la sémantique).
UML n’est pas un langage propriétaire : il est accessible à tous et les fabricants
d’outils ainsi que les entreprises de formation peuvent librement en faire usage. La volonté
d’ouverture, la richesse de la notation et la définition sémantique précise des éléments de
modélisation font d’UML un langage de modélisation général simple, sans être simpliste pour
autant.
Dans UML chaque diagramme permet d’exprimer certains points d’un même
problème. La combinaison de plusieurs digrammes permettra donc d’avoir une vue complète
du système informatique. Ainsi en fonction du problème à résoudre, il convient de choisir les
diagrammes adéquats à utiliser. UML définit neuf types de diagrammes dont nous détaillerons
ceux que nous utiliserons dans la suite :
85
Diagramme de cas d’utilisation : Les cas d'utilisations [9] décrivent le comportement du
système du point de vue utilisateur sous la forme d'actions et de réactions. Un cas d'utilisation
indique une fonctionnalité du système déclenché par un acteur externe au système. Ce genre
de diagramme permet de mettre en place et de comprendre les besoins du client. Dans le
diagramme, interviennent trois éléments : les acteurs, le système et les cas d'utilisation.
L'acteur représente un rôle joué par une personne ou un autre système qui interagit avec le
système en cours de modélisation. Un cas d'utilisation regroupe plusieurs scénarios
d'utilisation du système.
Diagramme de classe : Le diagramme de classes [9] est le point central dans un

développement orienté objet. En analyse, il a pour objectif de décrire la structure des entités
manipulées par les utilisateurs. En conception, le diagramme de classes représente la structure
d’un code orienté objet ou, à un niveau de détail plus important, les modules du langage de
développement.
Diagramme de déploiement : il indique comment l’application sera distribuée entre les

différents composants matériels.
Diagramme de séquence : Les diagrammes de séquences permettent de représenter des

collaborations entre objets selon un point de vue temporel, on y met l'accent sur la
chronologie des envois de messages. Les diagrammes de séquences peuvent servir à illustrer
un cas d'utilisation.
Diagramme d’état/transition : il modélise les aspects contrôle et temps du système.
Diagramme d’activité : UML permet de représenter graphiquement le comportement d'une

méthode ou le déroulement d'un cas d'utilisation, à l'aide de diagrammes d'activités (une
variante des diagrammes d'états-transitions).
Diagramme de collaboration : il modélise la communication possible entre les classes dans

un scénario particulier.
Diagramme des composants.
Diagramme d’objets.
86
Glossaire
RH: Ressources Humaines
DRH: Direction Ressources Humaines
RRH: Responsable Ressources Humaines
CV: Curriculum Vitae
LM: Lettre de Motivation
RDV: Rendez-vous
BA: Business Area
BU: Business Unity
CMMI: Capability Maturity Model integration
DAO: Data Access Object
ENTLIB: Enterprise Library
ISBN: (International Standard Book Number)
Netographie: Bibliographie du net, synonyme de webographie
POCO: Plain Old CLR Object
SCRUM: Terme emprunté au rugby et signifie mêlée
SGBDR: Système de Gestion de Base de Données Relationnel
SQL: StructuredQueryLanguage, utilisée pour la manipulation des données d’une Base de

données
SSII: Société de Services en Ingénierie Informatique
87
SVN: SubVersion, système de gestion des versions.
UML: Unified Modeling Language
XAML: eXtensible Application Markup Language
XML: eXtensible Markup Language
WCF: Windows Communication Foundation
WPF: Windows Presentation Foundation
WF: Workflow Foundation
88

Rapport Final Recruteemnt Finale

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Rapport Final Recruteemnt Finale

Caricato da

Copyright:

Formati disponibili

Dédicaces

Au symbole de douceur, de tendresse, d’amour et

A mon père, pour les sacrifices qu’il a consentis pour

Que ce travail soit le témoignage de l'amour que je lui avoue.

A mes chers amis qui m'ont soutenue, encouragée et

Tout d’abord, je tiens à remercier la société OXIA qui m’a accueilli. En

J'adresse mes sincères remerciements à mon encadreur Mr Amine

Je remercie également mon encadreur à la Faculté des sciences de Tunis,

Mes remerciements et reconnaissances s'étendent également à toute la

Enfin, je tiens à remercier l'équipe de développeurs, constitué de Mr

1. PRESENTATION DE L’ORGANISME D’ACCUEIL .................................................. 13

1.1. MISSION .......................................................................................................................... 13

1.2. DOMAINES DE COMPETENCES .......................................................................................... 14

1.2.2. Solutions de Gestion d’Entreprises ......................................................................... 14

1.2.4. Télécommunications ............................................................................................... 14

2. ETUDE DE L’EXISTANT ................................................................................................ 14

3. CRITIQUE DE L’EXISTANT .......................................................................................... 15

4. SOLUTION PROPOSEE .................................................................................................. 15

5. METHODOLOGIE DU TRAVAIL ................................................................................. 16

5.1 METHODE AGILE .............................................................................................................. 16

5.1.1 Définition .................................................................................................................. 16

5.1.2 Valeurs des méthodes Agiles .................................................................................... 16

5.1.3 Principes des méthodes Agiles ................................................................................. 16

5.2 CHOIX DE LA METHODE AGILE SCRUM .......................................................................... 17

5.2.1 Définition .................................................................................................................. 17

5.2.2 Justification du choix ................................................................................................ 17

5.2.3 Mise en œuvre .......................................................................................................... 18

5.2.4 Planification .............................................................................................................. 19

5.2.5 Gestion des besoins .................................................................................................. 20

5.3 CHOIX CONCEPTUELS ....................................................................................................... 21

5.3.2 Langage de modélisation : UML .............................................................................. 22

5.3.3 Outils logiciel de conception .................................................................................... 22

CHAPITRE 2 SPECIFICATION DES BESOINS ........................................................... 24

1. SPECIFICATION INFORMELLE .................................................................................. 25

1.1. BESOINS FONCTIONNELS................................................................................................. 25

1.2. BESOINS NON FONCTIONNELS ......................................................................................... 26

2 IDENTIFICATION DES CAS D’UTILISATION ........................................................... 26

2.1 Définition ..................................................................................................................... 26

2.2 Diagrammes des cas d’utilisation : Framework .......................................................... 27

2.3 Diagrammes des cas d’utilisation : Workflow Recrutement ....................................... 28

3. VUE DYNAMIQUE : DIAGRAMME D’ACTIVITES .................................................. 34

3.1 DIAGRAMME D’ACTIVITE : FLUX DE TRAVAIL DE RECRUTEMENT .................................... 35

CHAPITRE 3 CONCEPTION DE LA SOLUTION ....................................................... 37

1. VUE STATIQUE : DIAGRAMME DE CLASSE ........................................................... 38

DESCRIPTION DU DIAGRAMME DE CLASSE .............................................................................. 40

2. DIAGRAMME DE SEQUENCE ...................................................................................... 42

2.1. DIAGRAMME DE SEQUENCE FRAMEWORK ....................................................................... 43

2.1.1. Diagramme de séquence : Administrateur Recrutement ......................................... 43

2.3. DIAGRAMME DE SEQUENCE WORKFLOW RECRUTEMENT ................................................ 45

2.3.1. Diagramme de séquence : Authentification............................................................. 45

2.3.2. Diagramme de séquence : Chargé Recrutement ...................................................... 47

CHAPITRE 4 REALISATION ........................................................................................... 55

1. PRESENTATION DE L’ARCHITECTURE .................................................................. 56

1.1 CHOIX DE L’ARCHITECTURE ............................................................................................. 56

1.2 STRUCTURE DE L’APPLICATION ........................................................................................ 57

1.2.1 Présentation Layer .................................................................................................... 57

1.2.2 Service Layer ............................................................................................................ 58

1.2.3. Business Layer ......................................................................................................... 58

1.2.4. Data Layer ............................................................................................................... 58

1.2.5. Framework ............................................................................................................... 58

1.3 SCHEMA DE DEPENDANCE ENTRE COUCHES ...................................................................... 58

2. ENVIRONNEMENT DE DEVELOPPEMENT ............................................................. 60

2.1. ENVIRONNEMENT MATERIEL ........................................................................................... 60

2.2. ENVIRONNEMENT LOGICIEL ............................................................................................ 60