Rapport Final

Ministère de l’enseignement supérieur et de la recherche scientifique
Université de Sousse
Institut supérieur de gestion de Sousse
Mémoire de stage de fin d’étude

Pour l’obtention de licence appliquée en informatique appliquée à la gestion
Application web : « conception et développement d’une application Freelance »
Lieu de stage : Geek Innovation Center
ELABORE PAR : ENCADRE PAR :

FNAIECH RAKIA & BRAHIM RIM MR. HADDED AHMED
MR. SAADI THAMER
Année universitaire 2017-2018

Remerciements
Nous tenons à remercier dans un premier temps, toute l'équipe pédagogique de l'Institut
Supérieur de Gestion de Sousse et les intervenants professionnels responsables de la
formation de Licence Appliquée en Informatique Appliquée à la Gestion, pour avoir assuré la
partie théorique de celle-ci.
Nous remercions également Monsieur Haddad Ahmed notre encadrant académique pour
l'aide et les conseils concernant les missions évoquées dans ce rapport, qu'il nous a apporté lors
des différents suivis, pour le temps qu'il nous a consacré tout au long de la période du travail
sachant répondre à toutes nos interrogations.
Nous tenons à remercier tout particulièrement et à témoigner toute notre reconnaissance à

Monsieur Saadi Thamer notre encadrant professionnel, pour la confiance qu'il nous a accordé
dès notre arrivé dans Greek Innovation Center ainsi que pour l'expérience enrichissante et
pleine d'intérêt qu'il nous a fait vivre durant ces trois mois sans oublier sa participation au
cheminement de ce rapport. Ainsi que pour l'ensemble du personnel de Greek Innovantion
Center pour leur accueil sympathique et leur coopération professionnelle tout au long de ces
trois mois.
Rim & Rakia

Dédicaces
Du profond de nos cœurs, nous dédions ce travail à tous ceux qui nous sont chers,
A nos chers parents
Que ce travail soit l’expression de notre reconnaissance pour vos sacrifices consentis, votre
soutien moral et matériel que vous n’avez pas cessé de prodiguer. Vous avez tout fait pour notre
bonheur et notre réussite. Que dieu vous préserve en bonne santé et vous accorde une longue
vie, prie le bon Dieu de vous bénir, de veiller sur vous, en espérant que vous soyez toujours fiers
de nous.
A nos familles, frères et sœurs pour leurs soutiens moraux.
A nos amis et nos collègues qui nous ont donné la force d’avancer et de continuer pour
compléter ce travail grâce à leurs générosités et leurs expéditions positives et optimistes. Vous
étiez toujours présents pour nous aider et nous encourager.
Rim & Rakia

Table des matières
Introduction générale ................................................................................................................................ 13
Chapitre 1 : Contexte et motivation ........................................................................................................ 14
I. Introduction : ...................................................................................................................................... 15
II. Présentation de l’organisme : ............................................................................................................ 15
1. Historique et identité : ................................................................................................................... 15
2. Principales activités : ...................................................................................................................... 15
3. L’organigramme de l’entreprise : .................................................................................................. 16
III. Cadre du projet :............................................................................................................................. 16
1. Définition de GRH : ......................................................................................................................... 17
2. Les principes de GRH : .................................................................................................................... 18
3. Choix de gestion : ........................................................................................................................... 19
IV. Etude de l’existant :........................................................................................................................ 19
1. Analyse de l’existant : .................................................................................................................... 19
2. Critique de l’existant : .................................................................................................................... 22
V. Spécification des besoins : ................................................................................................................. 22
1. Les besoins fonctionnels : .............................................................................................................. 22
2. Identification des besoins non fonctionnels : ............................................................................... 23
VI. Diagramme de Gantt : .................................................................................................................... 24
VII. Conclusion : .................................................................................................................................... 24
Chapitre 2 : Expression des besoins........................................................................................................... 25
I. Introduction : ...................................................................................................................................... 26
II. Méthode et langage utilisé : .............................................................................................................. 26
1. Processus unifié : ............................................................................................................................ 26
2. Présentation du langage de modélisation UML : .......................................................................... 28
3. Architecture à envisager : .............................................................................................................. 28
III. Conception détaillée du modèle du système : .............................................................................. 29
1. Identification des acteurs :............................................................................................................. 29
2. Définition d’un diagramme de cas d’utilisation : .......................................................................... 30
3. Description des cas d’utilisations : ................................................................................................ 31
IV. Modèle métier: ............................................................................................................................... 32
1. Diagramme processus métier : ...................................................................................................... 32
V. Processus « Authentification » .......................................................................................................... 33

1. Spécification de cas d’utilisation « Authentification » : ............................................................... 33
VI. Processus « Gérer utilisateurs » .................................................................................................... 34
1. Raffinement et spécification de diagramme de cas d’utilisation « gérer utilisateur » : ............. 34
a. Modifier profile : ........................................................................................................................ 34
b. Supprimer profile : ..................................................................................................................... 35
c. Consulter utilisateur : ................................................................................................................. 36
2. Modèle du domaine ....................................................................................................................... 36
a. Diagramme de domaine « gérer utilisateur » : ......................................................................... 36
b. Traçabilité Métier-Domaine « gérer utilisateur » : ................................................................... 37
VII. Processus « Gérer offre » ............................................................................................................... 38
1. Raffinement et spécification de diagramme de cas d’utilisation « gérer offre » : ...................... 38
a. Ajouter offre : ............................................................................................................................. 39
b. Modifier offre : ........................................................................................................................... 39
c. Supprimer offre : ........................................................................................................................ 40
d. Postuler offre : ............................................................................................................................ 41
e. Signaler offre : ............................................................................................................................ 41
f. Vérifier signal :............................................................................................................................ 42
2. Diagramme d’activité « gérer offre » : .......................................................................................... 43
a. Ajouter offre : ............................................................................................................................. 43
b. Modifier offre : ........................................................................................................................... 44
d. Postuler offre : ............................................................................................................................ 46
3. Diagramme séquence système « gérer offre » : ........................................................................... 47
a. Ajouter offre : ............................................................................................................................. 47
b. Modifier offre : ........................................................................................................................... 48
d. Postuler offre : ............................................................................................................................ 50
4. Prototypes des interfaces utilisateurs : ......................................................................................... 51
a. Interface ajouter offre :.............................................................................................................. 51
b. Interface Supprimer /Modifier offre : ....................................................................................... 52
c. Interface de Postulation :........................................................................................................... 53
5. Modèle de domaine : ..................................................................................................................... 54
a. Diagramme de domaine « gérer offre » : .................................................................................. 54

b. Traçabilité Métier-Domaine « gérer offre » : ............................................................................ 55
VIII. Processus « Gérer test QCM » ....................................................................................................... 56
1. Raffinement et spécification de diagramme de cas d’utilisation « gérer test QCM » : ............... 56
a. Consulter liste candidats : .......................................................................................................... 56
b. Passer test QCM : ....................................................................................................................... 57
c. Ajouter test QCM : ..................................................................................................................... 57
d. Modifier test QCM :.................................................................................................................... 58
e. Supprimer test QCM :................................................................................................................. 59
a. Diagramme de domaine « gérer test QCM » : .......................................................................... 60
b. Traçabilité Métier-Domaine « gérer test QCM » : .................................................................... 61
IX. Processus « Gérer test Problème »................................................................................................ 62
1. Raffinement et spécification de diagramme de cas d’utilisation « gérer test problème » : ....... 62
a. Ajouter test problème : .............................................................................................................. 62
b. Modifier test Problème : ............................................................................................................ 63
c. Supprimer test Problème : ......................................................................................................... 64
d. Consulter test Problème : .......................................................................................................... 64
e. Soumettre code : ........................................................................................................................ 65
a. Diagramme de domaine « gérer test problème » : ................................................................... 66
b. Traçabilité Métier-Domaine « gérer test problème » : ............................................................. 67
X. Conclusion : ........................................................................................................................................ 67
Chapitre 3 : Phase d’élaboration............................................................................................................. 68
I. Introduction : ...................................................................................................................................... 69
II. Présentation de la phase d’élaboration : .......................................................................................... 69
III. Modèle de conception : ................................................................................................................. 69
IV. Conception du cas « Authentification » ........................................................................................ 70
1. Diagramme de classe d’analyse « Authentification » : ................................................................. 70
2. Traçabilité MCU/MC « Authentification » :................................................................................... 71
3. Diagramme de séquence « Authentification » :............................................................................ 71
V. Conception du cas « gérer utilisateur » ............................................................................................. 73
1. Diagramme de classe d’analyse « gérer utilisateur » : ................................................................. 73
2. Traçabilité MCU/MC « gérer utilisateur » : ................................................................................... 76

1. Diagramme de séquence « gérer utilisateur » : ............................................................................ 77
a. Modifier profile : ........................................................................................................................ 78
b. Supprimer profile : ..................................................................................................................... 79
3. Diagramme de classe de conception « gérer utilisateur » :.......................................................... 80
VI. Conception du cas « gérer offre ».................................................................................................. 81
1. Diagramme classe d’analyse « gérer offre » : ............................................................................... 81
2. Traçabilité MCU/MC « gérer offre » : ............................................................................................ 83
3. Diagramme de séquence « gérer offre » : ..................................................................................... 84
a. Signaler offre .............................................................................................................................. 85
b. Vérifier signal :............................................................................................................................ 86
c. Ajouter offre : ............................................................................................................................. 87
d. Modifier offre : ........................................................................................................................... 88
e. Supprimer offre : ........................................................................................................................ 89
f. Postuler offre : ............................................................................................................................ 90
4. Diagramme de classe de conception « gérer offre » : .................................................................. 91
VII. Conception du cas « gérer test QCM» ........................................................................................... 92
1. Diagramme de classe d’analyse « gérer test QCM » : ................................................................... 92
2. Traçabilité MCU/MC « gérer test QCM » : .................................................................................... 94
3. Diagramme de séquence « gérer test QCM » : ............................................................................. 96
a. Ajouter test QCM ; ..................................................................................................................... 96
b. Modifier test QCM :.................................................................................................................... 97
c. Supprimer test QCM :................................................................................................................. 98
d. Consulter liste des candidats : ................................................................................................... 99
4. Diagramme de classe de conception « gérer test QCM » : ......................................................... 100
VIII. Conception du cas « gérer test problème » ................................................................................ 101
1. Diagramme de classe d’analyse « gérer test problème » : ......................................................... 101
2. Traçabilité MCU/MC « gérer test problème » :........................................................................... 102
3. Diagramme de séquence « gérer test problème » :.................................................................... 103
a. Ajouter problème : ................................................................................................................... 103
b. Modifier problème : ................................................................................................................. 104
c. Supprimer problème : .............................................................................................................. 105
d. Consulter problème :................................................................................................................ 106
4. Diagramme de classe de conception « gérer test problème » : ................................................. 107

IX. Schémas de la base de données : ................................................................................................ 108
X. Diagramme de déploiement : .......................................................................................................... 109
XI. Conclusion : .................................................................................................................................. 109
Chapitre 4 : Module d’implementation ................................................................................................... 110
I. Introduction : .................................................................................................................................... 111
II. Environnement de travail : .............................................................................................................. 111
1. Environnement matériel : ............................................................................................................ 111
2. Environnement logiciel : .............................................................................................................. 112
III. Langage de programmation et autres outils : ............................................................................. 114
a. C-Sharp :.................................................................................................................................... 114
b. XAML :....................................................................................................................................... 114
c. Html : ........................................................................................................................................ 114
d. CSS :........................................................................................................................................... 114
e. SQL : .......................................................................................................................................... 115
f. Framework :.............................................................................................................................. 115
IV. Implémentation du cas « Authentification » : ............................................................................ 116
1. Traçabilité MC/MI du cas « Authentification » : ......................................................................... 116
2. Diagramme de composants du cas « Authentification » : .......................................................... 117
3. Présentation des interfaces utilisateurs réelles du cas « Authentification » :........................... 118
V. Implémentation du cas « Gérer test problème » : .......................................................................... 120
1. Traçabilité MC/MI du CU « Gérer test problème » : ................................................................... 120
2. Diagramme de composants du cas « Gérer test problème » : ................................................... 120
3. Présentation des interfaces utilisateurs réelles du cas « Gérer test problème » : .................... 121
VI. Conclusion .................................................................................................................................... 124
Conclusion générale ................................................................................................................................. 125

Liste des figures
FIGURE 1:LOGO DE LA SOCIETE D'ACCUEIL .................................................................................................................15
FIGURE 2:ORGANIGRAMME DE LA SOCIETE D’ACCUEIL ..............................................................................................16
FIGURE 3:LES PRINCIPES DE GRH ................................................................................................................................18
FIGURE 4:SCHEMA ILLUSTRANT LE SYSTEME D’INFORMATION ..................................................................................19
FIGURE 5:LOGO D’UN SITE WEB FREELANCE TUNISIEN ..............................................................................................19
FIGURE 6:CAPTURE DE LA PAGE D’ACCUEIL D’UN SITE WEB FREELANCE TUNISIEN ...................................................20
FIGURE 7:CAPTURE DE LA PAGE D’ACCUEIL D’UN SITE WEB FREELANCE TUNISIEN ...................................................20
FIGURE 8:CAPTURE DES INFORMATIONS TROUVEES SUR UN SITE WEB FREELANCE .................................................21
FIGURE 9:CAPTURE DES INFORMATIONS TROUVEES SUR UN SITE WEB FREELANCE .................................................21
FIGURE 10:CAPTURE D’UNE OFFRE POSTULEE DANS UN SITE WEB FREELANCE ........................................................21
FIGURE 11:CHRONOGRAMME DE TRAVAIL .................................................................................................................24
FIGURE 12:PHASE DE PROCESSUS UNIFIE ...................................................................................................................26
FIGURE 13:LOGO D’UML .............................................................................................................................................28
FIGURE 14:ARCHITECTURE 3-TIERS DU POINT DE VUE TECHNOLOGIQUE ..................................................................29
FIGURE 15:LISTE DES ACTEURS ....................................................................................................................................29
FIGURE 16:DIAGRAMME PROCESSUS METIER ............................................................................................................32
FIGURE 17:DIAGRAMME DE CAS D’UTILISATION « GERER UTILISATEUR » .................................................................34
FIGURE 18:DIAGRAMME DE DOMAINE DE PROCESSUS « GERER UTILISATEUR » .......................................................36
FIGURE 19:TRAÇABILITE METIER-DOMAINE « GERER OFFRE » ...................................................................................37
FIGURE 20:DIAGRAMME DE CAS D’UTILISATION « GERER OFFRE »............................................................................38
FIGURE 21:DIAGRAMME D’ACTIVITE DE SOUS PROCESSUS « AJOUTER OFFRE » .......................................................43
FIGURE 22:DIAGRAMME D’ACTIVITE DE SOUS PROCESSUS « MODIFIER OFFRE » .....................................................44
FIGURE 23:DIAGRAMME D’ACTIVITE DE SOUS PROCESSUS « SUPPRIMER OFFRE » ...................................................45
FIGURE 24:DIAGRAMME D’ACTIVITE DE SOUS PROCESSUS « POSTULER OFFRE » .....................................................46
FIGURE 25:DIAGRAMME SEQUENCE SYSTEME DE SOUS PROCESSUS « AJOUTER OFFRE » ........................................47
FIGURE 26:DIAGRAMME SEQUENCE SYSTEME DE SOUS PROCESSUS « MODIFIER OFFRE » ......................................48
FIGURE 27:DIAGRAMME SEQUENCE SYSTEME DE SOUS PROCESSUS « SUPPRIMER OFFRE » ...................................49
FIGURE 28:DIAGRAMME SEQUENCE SYSTEME DE SOUS PROCESSUS « POSTULER OFFRE » ......................................50
FIGURE 29:MAQUETTE DE L’OPERATION « AJOUTER OFFRE » ...................................................................................51
FIGURE 30:MAQUETTE DE L’OPERATION « SUPPRIMER OU MODIFIER UNE OFFRE » ................................................52
FIGURE 31:MAQUETTE DE L’OPERATION « POSTULER OFFRE » .................................................................................53
FIGURE 32:MAQUETTE DE L’OPERATION « IMPORTER CV ET LETTRE DE MOTIVATION » ..........................................53
FIGURE 33:DIAGRAMME DE DOMAINE DE PROCESSUS « GERER OFFRE » .................................................................54
FIGURE 34:TRAÇABILITE METIER-DOMAINE « GERER OFFRE » ...................................................................................55
FIGURE 35:DIAGRAMME DE CAS D’UTILISATION « GERER TEST QCM » .....................................................................56
FIGURE 36:DIAGRAMME DE DOMAINE DE PROCESSUS « GERER TEST QCM » ...........................................................60
FIGURE 37:TRAÇABILITE METIER-DOMAINE « GERER TEST QCM ».............................................................................61
FIGURE 38:DIAGRAMME DE CAS D’UTILISATION « GERER TEST PROBLEME » ...........................................................62
FIGURE 39:DIAGRAMME DE DOMAINE DE PROCESSUS « GERER TEST PROBLEME » .................................................66
FIGURE 40:TRAÇABILITE METIER-DOMAINE « GERER TEST PROBLEME » ...................................................................67
FIGURE 41:DIAGRAMME DE CLASSE D’ANALYSE « AUTHENTIFICATION » ..................................................................70
FIGURE 42:TRAÇABILITE MCU/MC « AUTHENTIFICATION » .......................................................................................71
FIGURE 43:DIAGRAMME DE SEQUENCE DE SOUS CU « AUTHENTIFICATION ». .........................................................72
FIGURE 44:DIAGRAMME DE CLASSE D’ANALYSE « GERER UTILISATEUR » : ENTREPRENEUR .....................................73
FIGURE 45:DIAGRAMME DE CLASSE D’ANALYSE « GERER UTILISATEUR » : ADMINISTRATEUR .................................74
FIGURE 46:DIAGRAMME DE CLASSE D’ANALYSE « GERER UTILISATEUR » : FREELANCER ..........................................75
FIGURE 47:TRAÇABILITE MCU/MC « GERER UTILISATEUR » .......................................................................................76

FIGURE 48:DIAGRAMME DE SEQUENCE DE SOUS CU « MODIFIER PROFILE » ............................................................78
FIGURE 49:DIAGRAMME DE SEQUENCE DE SOUS CU « SUPPRIMER PROFILE » .........................................................79
FIGURE 50:DIAGRAMME DE CLASSE DE CONCEPTION « GERER UTILISATEUR » .........................................................80
FIGURE 51:DIAGRAMME DE CLASSE D’ANALYSE « GERER OFFRE » : ENTREPRENEUR ...............................................81
FIGURE 52:DIAGRAMME DE CLASSE D’ANALYSE « GERER OFFRE » : FREELANCER.....................................................82
FIGURE 53:DIAGRAMME DE CLASSE D’ANALYSE « GERER OFFRE » : ADMINISTRATEUR ............................................82
FIGURE 54:TRAÇABILITE MCU/MC « GERER OFFRE »..................................................................................................83
FIGURE 55:DIAGRAMME DE SEQUENCE DE SOUS CU « SIGNALER OFFRE » ...............................................................85
FIGURE 56:DIAGRAMME DE SEQUENCE DE SOUS CU « VERIFIER SIGNAL » ...............................................................86
FIGURE 57:DIAGRAMME DE SEQUENCE DE SOUS CU « AJOUTER OFFRE » ................................................................87
FIGURE 58:DIAGRAMME DE SEQUENCE DE SOUS CU « MODIFIER OFFRE » ...............................................................88
FIGURE 59:DIAGRAMME DE SEQUENCE DE SOUS CU « SUPPRIMER OFFRE » ............................................................89
FIGURE 60:DIAGRAMME DE SEQUENCE DE SOUS CU « POSTULER OFFRE » ..............................................................90
FIGURE 61:DIAGRAMME DE CLASSE DE CONCEPTION « GERER OFFRE » ...................................................................91
FIGURE 62:DIAGRAMME DE CLASSE D’ANALYSE « GERER TEST QCM » : ENTREPRENEUR .........................................92
FIGURE 63:DIAGRAMME DE CLASSE D’ANALYSE « GERER TEST QCM » : ADMINISTRATEUR .....................................93
FIGURE 64:DIAGRAMME DE CLASSE D’ANALYSE « GERER TEST QCM » : FREELANCER ..............................................93
FIGURE 65:TRAÇABILITE MCU/MC « GERER TEST QCM » ...........................................................................................94
FIGURE 66:DIAGRAMME DE SEQUENCE DE SOUS CU « AJOUTER TEST QCM » ..........................................................96
FIGURE 67:DIAGRAMME DE SEQUENCE DE SOUS CU « MODIFIER TEST QCM » ........................................................97
FIGURE 68:DIAGRAMME DE SEQUENCE DE SOUS CU « SUPPRIMER TEST QCM » ......................................................98
FIGURE 69:DIAGRAMME DE SEQUENCE DE SOUS CU « CONSULTER LISTE DES CANDIDATS » ...................................99
FIGURE 70:DIAGRAMME DE CLASSE DE CONCEPTION « GERER TEST QCM » ...........................................................100
FIGURE 71:DIAGRAMME DE CLASSE D’ANALYSE « GERER TEST PROBLEME » ..........................................................101
FIGURE 72:TRAÇABILITE MCU/MC « GERER TEST PROBLEME »................................................................................102
FIGURE 73:DIAGRAMME DE SEQUENCE DE SOUS CU « AJOUTER PROBLEME » .......................................................103
FIGURE 74:DIAGRAMME DE SEQUENCE DE SOUS CU « MODIFIER PROBLEME » .....................................................104
FIGURE 75:DIAGRAMME DE SEQUENCE DE SOUS CU « SUPPRIMER PROBLEME » ..................................................105
FIGURE 76:DIAGRAMME DE SEQUENCE DE SOUS CU « CONSULTER PROBLEME » ..................................................106
FIGURE 77:DIAGRAMME DE CLASSE DE CONCEPTION « GERER TEST PROBLEME » .................................................107
FIGURE 78:DIAGRAMME DE DEPLOIEMENT ..............................................................................................................109
FIGURE 79:ENVIRONNEMENT MATERIEL ..................................................................................................................111
FIGURE 80:ENVIRONNEMENT MATERIEL ..................................................................................................................112
FIGURE 81:LOGO VISUAL STUDIO 2017 .....................................................................................................................112
FIGURE 82:LOGO MICROSOFT SQL SERVER 2012 ......................................................................................................112
FIGURE 83:LOGO RATIONAL ROSE.........................................................................ERROR! BOOKMARK NOT DEFINED.
FIGURE 84:LOGO BALSAMIQ MOCKUPS ....................................................................................................................113
FIGURE 85:LOGO ADOBE PHOTOSHOP CC 2017 .......................................................................................................114
FIGURE 86:TRAÇABILITE MC/MI DU CAS « AUTHENTIFICATION » : ADMINISTRATEUR ............................................116
FIGURE 87:TRAÇABILITE MC/MI DU CAS « AUTHENTIFICATION » : FREELANCER/ENTREPRENEUR .........................117
FIGURE 88:DIAGRAMME DE COMPOSANTS DU CAS « AUTHENTIFICATION » : ADMINISTRATEUR ..........................117
FIGURE 89:DIAGRAMME DE COMPOSANTS DU CAS « AUTHENTIfiCATION » : FREELANCER ...................................118
FIGURE 90:DIAGRAMME DE COMPOSANTS DU CAS « AUTHENTIfiCATION » : ENTREPRENEUR ..............................118
FIGURE 91:INTERFACE D’AUTHENTIfiCATION ADMINISTRATEUR .............................................................................119
FIGURE 92:INTERFACE INSCRIPTION .........................................................................................................................119
FIGURE 93:TRAÇABILITE MC/MI DU CU « GERER TEST PROBLEME » ........................................................................120
FIGURE 94:DIAGRAMME DE COMPOSANTS DU CAS « GERER TEST PROBLEME » ....................................................120
FIGURE 95:INTERFACE DE LISTE DES TESTS PROBLEMES ..........................................................................................121
FIGURE 96:INTERFACE AJOUTER TEST PROBLEME ....................................................................................................121

FIGURE 97:INTERFACE MODIFIER TEST PROBLEME ..................................................................................................122
FIGURE 98:INTERFACE SUPPRIMER TEST PROBLEME ................................................................................................123
FIGURE 99:INTERFACE PASSER TEST PROBLEME .......................................................................................................124

Liste des tableaux
TABLEAU 1:IDENTIFICATION DES ACTEURS .................................................................................................................30
TABLEAU 2:DESCRIPTION DES CAS D’UTILISATION .....................................................................................................31
TABLEAU 3:SPECIFICATION DU CU « AUTHENTIFICATION » .......................................................................................33
TABLEAU 4:SPECIFICATION DU CU « MODIFIER PROFILE » .........................................................................................35
TABLEAU 5:SPECIFICATION DU CU « SUPPRIMER PROFILE » ......................................................................................35
TABLEAU 6:SPECIFICATION DU CU « AJOUTER OFFRE » .............................................................................................39
TABLEAU 7:SPECIFICATION DU CU « MODIFIER OFFRE » ............................................................................................40
TABLEAU 8:SPECIFICATION DU CU « SUPPRIMER OFFRE » .........................................................................................40
TABLEAU 9:SPECIFICATION DU CU « POSTULER OFFRE » ...........................................................................................41
TABLEAU 10:SPECIFICATION DU CU « SIGNALER OFFRE » ..........................................................................................42
TABLEAU 11:SPECIFICATION DU CU « VERIFIER SIGNAL » ..........................................................................................42
TABLEAU 12:SPECIFICATION DU CU « CONSULTER LISTE CANDIDATS » .....................................................................57
TABLEAU 13:SPECIFICATION DU CU « PASSER TEST QCM » ........................................................................................57
TABLEAU 14:SPECIFICATION DU CU « AJOUTER TEST QCM » .....................................................................................58
TABLEAU 15:SPECIFICATION DU CU « MODIFIER TEST QCM » ...................................................................................59
TABLEAU 16:SPECIFICATION DU CU « SUPPRIMER TEST QCM ».................................................................................59
TABLEAU 17:SPECIFICATION DU CU « AJOUTER TEST PROBLEME » ...........................................................................63
TABLEAU 18:SPECIFICATION DU CU « MODIFIER TEST PROBLEME »..........................................................................63
TABLEAU 19:SPECIFICATION DU CU « SUPPRIMER TEST PROBLEME » .......................................................................64
TABLEAU 20:SPECIFICATION DU CU « CONSULTER TEST PROBLEME ».......................................................................64
TABLEAU 21:SPECIFICATION DU CU « SOUMETTRE CODE » .......................................................................................65

Introduction générale
Aujourd’hui, les sites web occupent une place importante dans la vie des jeunes. De plus,
l’utilisation d’un site web freelance est idéale pour ceux qui cherchent des moyens
supplémentaires pour gagner de l’argent, ceux qui aiment la liberté de la pige et ceux qui veulent
gagner plus de développement professionnel.
Dans ce cadre, tous jeunes diplômés tentent à trouver des emplois qu’ils en rêvent toujours,
ainsi les entrepreneurs cherchent à recruter les bonnes qualités dans les postes convenables
facilement et sans effort.
Nous avons réalisé une application « Freelance », dans le but de permettre aux jeunes diplômés
de tester ses compétences pour trouver des emplois en même temps d’accorder aux
entrepreneurs de recruter les employés qu’ils cherchent toujours.
Ce stage nous permet de passer d’une formation plus étendue théoriquement au niveau de
l’université, à une formation purement pratique pour mieux comprendre la vie professionnelle
et être un bon programmeur.
Notre projet de fin d'études s'est donc déroulé à l’entreprise « Greek Innovation Center », sur
une période de trois mois du 01/02/2017 au 30/04/2018 et ce en vue de l'obtention du Licence
Appliquée en Informatique de Gestion à l'Institut Supérieur de Gestion de Sousse.
Au sein de l’entreprise « Greek Innovation Center », nous sommes reconnaissantes au bon

climat de travail qui nous avons aidé à bien achever ce projet.

Chapitre 1 : Contexte et
motivation

I. Introduction :
Dans ce chapitre, nous commençons par la présentation de l’organisme d’accueil où s’est
déroulé notre stage de fin d’études. Nous donnons par la suite un aperçu sur le projet réalisé.
II. Présentation de l’organisme :
Figure 1:Logo de la société d'accueil
1. Historique et identité :
Depuis 2016, la société ≪ Geek Academy ≫ (située au Pays-Bas) a créé une filiale en l’appelant
≪ Geek Innovation Center ≫. Cette dernière est spécialisée dans le développement des
Application web et mobile. Elle vient d’élargir, cette année, son domaine d’activité en acceptant
les projets de développement par des Entreprises tunisiennes.
2. Principales activités :
La société ≪ Geek Innovation Center ≫ exerce ses activités dans les domaines suivants :
 Le développement des applications web,
 Le développement des applications mobile,
 Création de solution Cloud pour les Entreprises.

3. L’organigramme de l’entreprise :
Figure 2:Organigramme de la société d’accueil
Greek Academy Pays_Bas
Greek Academy_Tunisie
III. Cadre du projet :

Aujourd’hui, plusieurs changements technologiques entrainent dans toutes les entreprises, fait
disparaitre par conséquences des changements en matière d’emploi et de recrutement.
Ces mutations technologiques impactent les entreprises en créant de nouveaux enjeux pour la
gestion des ressources humaines (GRH) pour garantir par la suite l’accroissement de la
production et être au niveau de la concurrence.
En effet, ces changements imposent à l’entreprise des efforts en termes d’innovation et de
flexibilité, elles cherchent à améliorer le niveau de qualification de ses salariés en accédant à
d’autres issues non habituels tels que les sites de recrutement afin de sélectionner les meilleures
compétences.

Notre application s’intègre dans ce cadre, où l’objectif réside à favoriser les entrepreneurs à
chercher et à recruter les bonnes compétences sans efforts ainsi que les jeunes diplômés à
déposer leurs profits et viser les postes convenables sans déplacement et sans fatigue.
De nos jours, les entreprises s’orientent des plus en plus vers la catégorisation et la spécification
de leur système d’informations en le décomposant en plusieurs sous domaines, tel que le GRH
(gestion de ressources humaines).
Pour mieux comprendre notre sujet, on va passer à la définition de GRH et ses principes :
1. Définition de GRH :
La Gestion des Ressource Humains (GR) est un service au sein de l'entreprise intervenant dans
différentes fonctions relatives à la gestion du personnel.
Elle se décline ainsi en de multiples tâches :
Définition des postes, recrutement, gestion des carrières, formation, gestion de la paie et des
rémunérations, évaluation des performances, gestion des conflits, relations sociales et
syndicales, motivation et l’implication du personnel, communication, les conditions de travail,
sélection et équité (justice distributive, interactive, etc..).
Afin de valoriser les compétences, la motivation, l’information et l’organisation, il est possible de

donner toute l’attention nécessaire à certains outils de gestion :
 Le recrutement. En évaluant les compétences et la motivation lors du recrutement, on

s'assure d'avoir un personnel adéquat en nombre et en qualification,
 La formation et le coaching. Afin d'améliorer le niveau de compétence
des collaborateurs, mais aussi pour améliorer leur motivation (une formation peut
constituer une récompense et, il est souvent plus motivant d'effectuer un travail que l'on
sait faire),
 La motivation positive.

2. Les principes de GRH :
Figure 3:Les principes de GRH
Les pratiques de gestion des ressources humaines sont réparties selon trois objectifs de saine
gestion des ressources humaines qui sont l’attraction, le développement et la rétention du
personnel.

3. Choix de gestion :
Voilà une image simplifiant notre application :
Figure 4:Schéma illustrant le système d’information
IV. Etude de l’existant :

Cette section a pour objectif d’étudier et faire le tour sur la solution existante ce qui va nous
permettre de dégager les points forts et les points faibles de cette solution. Dans ce qui suit, nous
présentons une analyse de l’existant.
1. Analyse de l’existant :
Plusieurs site web Freelance sont trouvés, tels que Upwork, Sphere Engine, Freelance-
Tunisie.tn et Freelance Tunisie…
Figure 5:Logo d’un site web freelance tunisien

Figure 6:Capture de la page d’accueil d’un site web freelance tunisien
Figure 7:Capture de la page d’accueil d’un site web freelance tunisien

Figure 8:Capture des informations trouvées sur un site web freelance
Figure 9:Capture des informations trouvées sur un site web freelance
Figure 10:Capture d’une offre postulée dans un site web freelance

On peut parler encore de l’application « FindJob », qui a beaucoup diffère de notre site web.
En effet, cette dernière s’adresse seulement à des employés qui exécutent leurs travails sous l’autorité
d’une entreprise contrairement à notre site web, il s’adresse aux freelances exerçants seuls en toute
indépendante une tâche. Ces freelances s’adressent à une clientèle d’entreprises, définirent avec elles
sa mission et la réalisent eux-mêmes sous leurs propres responsabilités.
2. Critique de l’existant :
Dans cette partie, nous essayons de déceler les insuffisances de la situation existante, nous
présentons ses défaillances pour arriver enfin à proposer une solution.
Suite aux collectes d’information que nous avons effectué auprès des applications similaires,
plusieurs site permet de recruter des employés, de poster des offres et permettre au chercheur
des emploi de déposer leurs CV ; parmi ces sites on peut citer deux sites nationaux Freelance
Tunisie et Freelance-Tunisie.tn qui sont conscients seulement à poster des missions par
plusieurs entrepreneurs, ils permettent de fournir des opportunités d'emploi sous forme d'une
liste disponible à tous les visiteurs, ce qui engendre une difficulté au sein de l'entreprise aux
sélections des employé à cause des nombreuses demandes.
Nous allons citer des différents inconvénients :
- L’entrepreneur ne peut pas choisir le candidat qu’à travers une demande qui porte son
CV.
- Aucune garantie que les candidats présentés par leurs CV sont des candidats compétents.
- Design et ergonomie : choix des couleurs, difficiles pour les daltoniens…
- L’écriture ou bien la langue utilisée doit être soit en anglais soit en français.
V. Spécification des besoins :

1. Les besoins fonctionnels :
En s'appuyant sur les inconvénients précédemment cités, nous allons créer une application web
avec les fonctionnalités qui résolvent les problèmes rencontrés.
Notre application permet de :
 Gérer les partenaires,
 Déposer des offres d’emploi,
 Gérer les tests d’évaluation (QCM et problèmes),
 Consulter les tests et les offres,
 Passer des tests de compétences pour les freelances selon leurs spécialités,

 Facilite le recrutement des employés à travers des listes de candidats avec un score
pour chacun.
2. Identification des besoins non fonctionnels :

Ces sont les contraintes qui peuvent empêcher l’application de fonctionner d’une
manière correcte. Les exigences de notre application sont donc les suivantes :
 La sécurité : le système qui doit fournir une fonction d’authentification en précisant le
droit d’accès pour chaque utilisateur et lui indiqué ou il doit se connecter avec un login
et un mot de passe.
 La performance : le système doit répondre à fonctionnalités fondamentales d’une
manière optimale et en un temps minimal.
 La fiabilité : le système doit afficher des données fiables à l’utilisateur.
 Disponibilité : le système doit être quotidien et hebdomadaire.
 Ergonomie des interfaces : les interfaces doivent être claires, simples et
professionnelles.
 Maintenabilité : complexité réduite, modularité, commentaires.

VI. Diagramme de Gantt :
Ce chronogramme présente la période passée pour réaliser notre projet :
Figure 11:chronogramme de travail
VII. Conclusion :
Cette partie nous a procuré une présentation du cadre général du stage, de l’étude et de critique
de l’existant ainsi que de la solution à proposer et des objectifs à atteindre sans oublier la
méthode de développement et les langages et outils choisis. Le chapitre suivant est consacré à
l'étude conceptuelle de notre application.

Chapitre 2 : Expression
des besoins

I. Introduction :
L’expression des besoins représente une étape fatidique puisque l’objectif extrême de toute
application est de satisfaire les besoins de ses utilisateurs, est par suite c’est la première phase
du Processus Unifié, elle consiste à comprendre le contexte du système. Il s’agit de déterminer
les fonctionnalités et les acteurs les plus pertinents, de préciser les risques les plus critiques et
d’identifier les cas d’utilisation initiaux.
II. Méthode et langage utilisé :

1. Processus unifié :
Le Processus unifié de développement logiciel est une méthode générique qui repose sur
l’approche orientée-objet, et utilisé UML comme langage de modélisation visuelle.
- Le but du Processus Unifié est d’assurer la production d’un logiciel de bonne

qualité, qui satisfait les besoins de ses utilisateurs et qui est produite et livrée
dans le respect des délais et des coûts prévus.
Le Processus Unifié répète un certain nombre de fois une série de cycles de développement.
Chaque cycle est géré comme un projet, se conclu par la livraison d’une version du produit au
client et s’articule autour 4 phases à savoir :
Figure 12:phase de processus unifié
 Création (Lancement, Incubation, Initialisation),
 Elaboration,
 Construction,

 Transition.
Chaque phase se subdivise en une ou plusieurs itérations. Chaque itération couvre généralement
5 activités et constitue un mini projet.
Les 5 activités de Processus Unifié sont :
 Expression des besoins :
- Identifier les besoins fonctionnels qui conduisent à l’élaboration du modèle de cas

d’utilisation.
- Besoins non fonctionnels.
 Analyse :
- Définir les réalisations des Cas d’utilisation et les structures.
 Conception :
- Détailler et approfondir le modèle d’analyse afin d’aboutir à un modèle de

conception décrivant l’architecture du système en termes de paquetages, classes
de conceptions, objets de conception interagissant entre eux pour réaliser les CU.
- Aboutis aussi à un modèle de déploiement décrivant l’architecture du système en

termes de nœuds matériels et leurs connexions.
 Implémentation :
- Implémenter sous forme de composants les sous-systèmes et les classes conçus.
 Test
Le processus unifie est une méthodologie qui repose sur le langage UML, la section suivante est
consacrée à la description de ce langage.

2. Présentation du langage de modélisation UML :
Figure 13:logo d’UML
UML se définit comme un langage de modélisation graphique et textuelle destiné à comprendre

et d’écrire des besoins, spécifier et documenter des systèmes, concevoir des solutions et
communiquer des points de vue.
UML est avant tout un support de communication performant, qui facilite la représentation et la
compréhension de solutions objet : Sa notation graphique permet d’exprimer visuellement une
solution objet, ce qui facilite la comparaison et l’évaluation de solutions.
3. Architecture à envisager :
L’architecture 3-tiers, aussi appelée architecture distribuée ou architecture multi-tiers, est un
modèle logique d’architecture applicative qui sépare une application ou un système en 3 couches
logiciel.
Ces couches sont : la couche de présentation, la couche métier et la couche base de données.
Elles présentent une fiabilité, une bonne disponibilité et une excellente évolutivité avec une
grande sécurité.
La figure suivante représente les trois couches de l’architecture d’une application.Net : Le

schéma ci-dessous présente de façon simplifié les différents niveaux d’une architecture logique
3-tier.

Figure 14:Architecture 3-tiers du point de vue technologique
III. Conception détaillée du modèle du système :
1. Identification des acteurs :
Un acteur est représenté par un ≪ stickman ≫. Il se réfère un genre d’une personne, un matériel
ou un logiciel qui interagit directement avec le système pour accomplir une tâche.
Ainsi, les acteurs fournissent les informations en entrée et/ou reçoivent les informations en
sortie.
En ce que concerne notre système, il fait intervenir quatre acteurs :
Figure 15:Liste des acteurs

Le tableau ci-dessous représente leurs fonctionnalités :
Administrateur C’est l’acteur qui gère les statistiques, les

problèmes, les cas de test et les missions ...
Entrepreneur C’est est un acteur principal qui poste des

missions (de type freelance ou autre) et des tests
de compétences.
Freelancer C'est un acteur principal de notre système qui

utilise les fonctionnalités offertes par
l’application pour chercher un travail et tester ses
compétences.
Tableau 1:identification des acteurs
2. Définition d’un diagramme de cas d’utilisation :
L’UML définit une notion graphique pour représenter les cas d’utilisation, cette notion est
appelée diagramme de cas d’utilisation.
Un diagramme de cas d’utilisation est utilisé pour donner une vision globale du
comportement fonctionnel d’un système logiciel. Il présente une unité discrète d’interaction
entre un utilisateur et un système.

3. Description des cas d’utilisations :
Un cas d'utilisation définit une manière d'utiliser le système et permet d'en décrire les exigences
fonctionnelles.
Chaque cas d'utilisation contient un ou plusieurs scénarios qui définissent comment le système
devrait interagir avec les acteurs pour atteindre un but ou une fonction spécifique d'un travail.
les acteurs
Administrateur Entrepreneur Freelancer
Cas d’utilisation
Gérer partenaires
Gérer offre
Gérer test QCM
Gérer test problème
Consulter profil
Consulter offre
Supprimer profile
Supprimer offre
Signaler offre
Consulter liste
demande
Consulter liste
candidats
Consulter
statistique
Postuler offre
Consulter signal
Tableau 2:description des cas d’utilisation

IV. Modèle métier :
Le modèle métier représente les objets métier, sous forme de diagrammes de classe et de
diagrammes d'état UML. Il permet de définir les entités ainsi que leurs relations et leurs
décompositions.
1. Diagramme processus métier :
Figure 16:diagramme processus métier

V. Processus « Authentification »
1. Spécification de cas d’utilisation « Authentification » :
Nom de cas d’utilisation : Modifier profile
Acteur : Utilisateur
Pré-condition : Opération authentification demandée par

l’acteur.
Post-condition : Acteur authentifié et redirigée vers son

espace.
Scénario de base : 1) L’acteur introduit son e-mail et son

mot de passe.
2) L’acteur valide la connexion.
3) Le système vérifie l’existence du
compte.
4) Le système dirige l’acteur vers son
espace.
Exception : Compte inexistant
Problème de connexion.
Le système informe l’utilisateur de l’échec

d’accès.
Retour à l’étape 1.
Tableau 3:spécification du CU « Authentification »

VI. Processus « Gérer utilisateurs »
1. Raffinement et spécification de diagramme de cas d’utilisation « gérer
utilisateur » :
Figure 17:diagramme de cas d’utilisation « gérer utilisateur »
a. Modifier profile :
Nom de cas d’utilisation : Modifier profile
Pré-condition : Utilisateur authentifié, opération de

modification choisie.
Post-condition : Un compte est modifié.
Scénario de base : 1) ≪ include ≫s’authentifier (voir

page).
2) Le système affiche une interface
contenant les informations du
l’utilisateur.
3) L’utilisateur modifie une ou
plusieurs informations affichées.
4) L’utilisateur valide la

modification.
5) Le système vérifie les champs
remplis du l’utilisateur.
6) Le système enregistre les
modifications.
Exception : Un champ non rempli ou incorrect.
Le système informe l’utilisateur de l’échec de

modification.
Retour à l’étape 3.
Tableau 4:spécification du CU « modifier profile »
b. Supprimer profile :
Nom de cas d’utilisation : Supprimer utilisateur
Acteur : Administrateur
Pré-condition : Administrateur authentifié, opération de

suppression choisie.
Post-condition : Un utilisateur est supprimé.
Scénario de base : 1) ≪ include ≫s’authentifier (voir page).

2) L’administrateur demande de
supprimer l’utilisateur sélectionné.
3) Le système demande à
l’administrateur une confirmation de
suppression d’un utilisateur.
4) L’administrateur confirme la
suppression de l’utilisateur.
5) Le système supprime l’utilisateur
6) Le système informe l’administrateur
du succès de l’opération.
Exception : Suppression annulée.
Le système informe l’administrateur de

l’échec de suppression.
Tableau 5:spécification du CU « supprimer profile »

c. Consulter utilisateur :
Même travail que le cas d’utilisation supprimer profile.
2. Modèle du domaine
a. Diagramme de domaine « gérer utilisateur » :
Figure 18:diagramme de domaine de processus « gérer utilisateur »

b. Traçabilité Métier-Domaine « gérer utilisateur » :
Figure 19:traçabilité métier-domaine « gérer offre »
Cette traçabilité consiste à identifier les classes Models (signal, profile, entrepreneur et
Freelancer) qui participent à la réalisation de « CU gérer utilisateur » et qui jouent le rôle d’un
intermédiaire entre les personnes et les interface.

VII. Processus « Gérer offre »
1. Raffinement et spécification de diagramme de cas d’utilisation « gérer offre »
:
Figure 20:diagramme de cas d’utilisation « gérer offre »

a. Ajouter offre :
Nom de cas d’utilisation : Ajouter offre
Acteur : Entrepreneur
Pré-condition : Entrepreneur authentifié, opération d’ajout
Post-condition : Offre ajouter
Scénario de base : 1) « include » s’authentifier (voir

diagramme).
2) L’entrepreneur demande d’ajouter
une offre.
d’ajouter offre.
4) L’entrepreneur remplie les champs.
5) Le système vérifie les champs remplis
pour l’offre.
6) Le système informe l’utilisateur de
succès de l’opération et enregistre
l’offre.
Exception : Champs non remplis ou incorrect.
Le système informe l’entrepreneur de l’échec

de l’ajout.
Retour à l’étape 3).
Tableau 6:Spécification du CU « ajouter offre »
b. Modifier offre :
Nom de cas d’utilisation : Modifier offre
Pré-condition : Entrepreneur authentifier, opération de

modification
Post-condition : Offre modifier

diagramme).
2) L’entrepreneur demande de modifier
l’offre.
3) Le système affiche une interface de

modification.
4) L’entrepreneur modifie les champs
5) Le système demande de confirmation
de mise à jour
6) Entrepreneur valide la modification.
7) Le système informe l’entrepreneur du
succès de l’opération.

de modification.
Tableau 7:Spécification du CU « modifier offre »
c. Supprimer offre :
Nom de cas d’utilisation : Supprimer offre
Acteur : Administrateur et entrepreneur
Pré-condition : Administrateur ou entrepreneur authentifié,

opération de suppression.
Post-condition : Offre supprimer
Scénario : 1) « include » s’authentifier.

2) L’acteur demande de supprimer une
offre.
3) Le système demande une
confirmation de suppression.
4) L’acteur confirme la suppression.
5) Le système informe l’acteur de succès
de l’opération.

suppression.
Tableau 8:Spécification du CU « supprimer offre »

d. Postuler offre :
Nom de cas d’utilisation : Postuler une offre
Acteur : Freelancer
Pré-condition : Freelance authentifier, opération de

postulation.
Post-condition : Offre postuler

2) Freelancer click sur un bouton
postuler offre.
3) Le système affiche une
interface de postulation.
4) Freelancer importé son CV et
lettre de motivation
5) Le système informe le
Freelancer de sucées de
l’opération.
Exception : Echec de postulation.
Le système informe le Freelancer de l’échec

de l’opération.
Tableau 9:Spécification du CU « postuler offre »
e. Signaler offre :
Nom de cas d’utilisation : Signaler utilisateur
Pré-condition : Utilisateur authentifié, opération de signal

choisie
Post-condition : Compte signaler
Scénario de base : 1) « include » s’authentifier (voir page).

2) L’utilisateur demande de signaler une
offre.
3) Le système demande à l’utilisateur
une confirmation de signal.
4) L’utilisateur confirme le signal.
5) Compte signaler par le système.

6) Le système informe l’administrateur
du succès de l’opération.
Exception : Echec de signal

l’échec
Tableau 10:Spécification du CU « signaler offre »
f. Vérifier signal :
Nom de cas d’utilisation : Vérifier signal
Pré-condition : Administrateur authentifié, opération de

vérification choisie.
Post-condition : Compte signaler
Scénario de base : 1) « include» s’authentifier (voir page).

2) L’administrateur reçoit une demande
de signal.
3) Le système affiche la liste des
demandes.
4) Administrateur vérifie les causes.
5) Administrateur valide le signal.
Exception : Echec de signal

l’échec
Tableau 11:Spécification du CU « vérifier signal »

2. Diagramme d’activité « gérer offre » :
a. Ajouter offre :
Figure 21:diagramme d’activité de sous processus « ajouter offre »

b. Modifier offre :
Figure 22:diagramme d’activité de sous processus « modifier offre »

Figure 23:diagramme d’activité de sous processus « supprimer offre »

d. Postuler offre :
Figure 24:diagramme d’activité de sous processus « postuler offre »

3. Diagramme séquence système « gérer offre » :
a. Ajouter offre :
Figure 25:diagramme séquence système de sous processus « ajouter offre »

b. Modifier offre :
Figure 26:diagramme séquence système de sous processus « modifier offre »

Figure 27:diagramme séquence système de sous processus « supprimer offre »

d. Postuler offre :
Figure 28:diagramme séquence système de sous processus « postuler offre »

4. Prototypes des interfaces utilisateurs :
BalsamiqMockup est une application d’interface utilisateur graphique qui permet de
construire de wireframe de site web.
Il permet au concepteur d’organiser des widgets préconstruits à l’aide d’un éditeur WY-SIWYG
glissé-déposer.
a. Interface ajouter offre :
Figure 29:maquette de l’opération « ajouter offre »
L’interface ajouter offre permet à l’entrepreneur d’ajouter une offre.

b. Interface Supprimer /Modifier offre :
Figure 30:maquette de l’opération « supprimer ou modifier une offre »
Cette interface permet à un entrepreneur de supprimer ou modifier une offre.

c. Interface de Postulation :
Figure 31:maquette de l’opération « postuler offre »
Figure 32:maquette de l’opération « importer cv et lettre de motivation »
Cette interface permet à un freelance d’importer son CV et sa lettre de motivation.

5. Modèle de domaine :
Un modèle de domaine est le modèle conceptuel d’un domaine. Il comprend tant le
comportement que les données.
a. Diagramme de domaine « gérer offre » :
Figure 33:diagramme de domaine de processus « gérer offre »

b. Traçabilité Métier-Domaine « gérer offre » :
Figure 34:Traçabilité métier-domaine « gérer offre »
Cette traçabilité consiste à identifier les classes Models (offre et demande) qui participent à la
réalisation de « CU gérer offre » et qui jouent le rôle d’un intermédiaire entre les personnes et
les interface.

VIII. Processus « Gérer test QCM »
1. Raffinement et spécification de diagramme de cas d’utilisation « gérer test
QCM » :
Figure 35:diagramme de cas d’utilisation « gérer test QCM »
a. Consulter liste candidats :
Nom de cas d’utilisation : Consulter test
Pré-condition : Entrepreneur authentifié, opération de

suppression.
Post-condition : Liste consultée

2) L’entrepreneur demande de voir la
liste des adhérents qui passent les

tests.
adhérents.
4) L’entrepreneur sélectionne un
Freelancer parmi les adhérents
affichés.
Exception : Echec, au sein de système.
Tableau 12:spécification du CU « consulter liste candidats »
b. Passer test QCM :
Nom de cas d’utilisation : Passer test
Acteur : Freelancer
Pré-condition : Freelancer authentifié, opération de

suppression.
Post-condition : Test passé

2) Freelancer demande de passer un test
choisi.
3) Le système affiche le test.
4) L’acteur passe le test et le confirme.
5) Le système informe le Freelancer que
le test passé avec succès.
6) Le système affiche les nombres des
réponses vrais et faux.
Exception : Echec, si le test est déjà passé.
Problème au sein de système.
Tableau 13:spécification du CU « passer test QCM »
c. Ajouter test QCM :
Nom de cas d’utilisation : Ajouter test qcm
Post-condition : Test ajouté

diagramme).
2) L’entrepreneur demande d’ajouter un
test.
d’ajouter test.
pour le test.
succès de l’opération et enregistre le
test.

de l’ajout.
Tableau 14:spécification du CU « ajouter test QCM »
d. Modifier test QCM :
Nom de cas d’utilisation : Modifier test QCM

modification
Post-condition : Test modifié

diagramme).
le test.
3) Le système affiche une interface de
modification déjà rempli.
4) L’entrepreneur modifie les champs.
de mise à jour.


de modification.
Tableau 15:Spécification du CU « modifier test QCM »
e. Supprimer test QCM :
Nom de cas d’utilisation : Supprimer test QCM

Post-condition : Test supprimé

2) L’acteur demande de supprimer un
test.
de l’opération.

suppression.
Tableau 16:Spécification du CU « supprimer test QCM »

a. Diagramme de domaine « gérer test QCM » :
Figure 36:diagramme de domaine de processus « gérer test QCM »

b. Traçabilité Métier-Domaine « gérer test QCM » :
Figure 37:Traçabilité métier-domaine « gérer test QCM »
Cette traçabilité consiste à identifier les classes Models (Test, Question, Réponse et
TestFreelancer) qui participent à la réalisation de CU « gérer test QCM » et qui jouent le rôle
d’un intermédiaire entre les personnes et les interface.

IX. Processus « Gérer test Problème »
1. Raffinement et spécification de diagramme de cas d’utilisation « gérer test
problème » :
Figure 38:diagramme de cas d’utilisation « gérer test problème »
a. Ajouter test problème :
Nom de cas d’utilisation : Ajouter test Problème
Post-condition : Problème ajouté

diagramme).
2) L’entrepreneur demande d’ajouter un
problème.
d’ajouter problème.
pour le test.
succès de l’opération et enregistre le

test.

de l’ajout.
Tableau 17:spécification du CU « ajouter test problème »
b. Modifier test Problème :
Nom de cas d’utilisation : Modifier test Problème

modification
Post-condition : Problème modifié

diagramme).
un problème.
3) Le système affiche un formulaire de
modification déjà remplis.
4) L’entrepreneur modifie les champs
de mise à jour

de modification.
Tableau 18:spécification du CU « modifier test problème »

c. Supprimer test Problème :
Nom de cas d’utilisation : Supprimer test Problème

Post-condition : Problème supprimé

2) L’acteur demande de supprimer un
problème.
de l’opération.

suppression.
Tableau 19:spécification du CU « supprimer test problème »
d. Consulter test Problème :

Nom de cas d’utilisation : Consulter test Problème
Pré-condition : Utilisateur authentifié, opération de

suppression.
Post-condition : Liste de problèmes consultée

2) Utilisateur demande de voir la liste
des problèmes.
problèmes.
Exception : Echec, au sein de système.
Problème de connexion
Tableau 20:spécification du CU « consulter test problème »

e. Soumettre code :
Nom de cas d’utilisation : Soumettre code
Acteur : Freelancer
Pré-condition : Freelancer authentifié, opération de

suppression.
Post-condition : Test passé

2) Freelancer demande de passer un test
problèmes.
3) Le système afficher une interface.
4) Freelancer choisir le compilateur et
cliquer sur button soumettre code.
de l’opération.
Exception : Problème de connexion.
Erreur au sein de système.
Tableau 21:spécification du CU « soumettre code »

a. Diagramme de domaine « gérer test problème » :
Figure 39:diagramme de domaine de processus « gérer test problème »

b. Traçabilité Métier-Domaine « gérer test problème » :
Figure 40:traçabilité métier-domaine « gérer test problème »
Cette traçabilité consiste à identifier les classes Models (TestProblème, TestCase et Sphère
Engine) qui participent à la réalisation de CU « gérer test QCM » et qui jouent le rôle d’un
intermédiaire entre les personnes et les interface.
X. Conclusion :
Nous avons présenté dans ce chapitre les différents diagrammes des cas d’utilisation ayant servi
à la modélisation des besoins de notre application aussi la spécification de chaque cas
d’utilisation. Le chapitre suivant sera réservé à la conception de cas d’utilisation.

Chapitre 3 : Phase
d’élaboration

I. Introduction :
Dans ce chapitre nous allons passer par la phase de conception, l’activité de conception consiste
à façonner le système et à lui donner une forme et une architecture répondant à tous les besoins
et les exigences (y compris les besoins non fonctionnels et les autres contraintes).
Objectifs de la conception :
 Acquérir une compréhension approfondie des questions concernant les besoins non
fonctionnels.
 Constituer une base et un point de départ aux activités suivantes d’implémentation en
formulant les exigences pesant sur chaque sous-système sur les interfaces et sur les
classes.
 Décomposer le travail d’implémentation en portions plus gérables.
II. Présentation de la phase d’élaboration :

La phase d’élaboration est le moment pour procéder à des itérations, son l’objectif est de rédiger
en détails, reformuler la partie de cas d’utilisation et d’éliminer les risques faisant obstacles à cet
objectif.
III. Modèle de conception :

Dans ce modèle nous explicitons les interfaces des objets et la sémantique des opérations
(méthodes).
 Définition de 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.
Le diagramme de séquence permet de cacher les interactions d'objets 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éroulent les actions entre les acteurs ou objets.
La dimension verticale du diagramme représente le temps, permettant de visualiser
l'enchaînement des actions dans le temps, et de spécifier la naissance et la mort des objets. Les
périodes d'activité des objets sont symbolisées par des rectangles, et ces objets dialoguent par le
biais de messages.

IV. Conception du cas « Authentification »
1. Diagramme de classe d’analyse « Authentification » :
Figure 41:diagramme de classe d’analyse « Authentification »

2. Traçabilité MCU/MC « Authentification » :
Cette traçabilité consiste à identifier les classes de conception IU Connexion, Controller-
Connexion et utilisateur qui participent à la réalisation de cas d’utilisation Authentification. En
effet, c’est le Controller-Connexion qui joue le rôle d’intermédiaire entre l’entité utilisateur et les
interfaces utilisateur IUConnexion.
Figure 42:traçabilité MCU/MC « Authentification »
3. Diagramme de séquence « Authentification » :

Le diagramme de séquence permet de d´écrire les scénarios de chaque cas d’utilisation en
mettant l’accent sur la chronologie des opérations montrant l’interaction entre les objets.

Figure 43:diagramme de séquence de sous CU « Authentification ».

V. Conception du cas « gérer utilisateur »
1. Diagramme de classe d’analyse « gérer utilisateur » :
Figure 44:diagramme de classe d’analyse « gérer utilisateur » : entrepreneur

Figure 45:diagramme de classe d’analyse « gérer utilisateur » : administrateur

Figure 46:diagramme de classe d’analyse « gérer utilisateur » : Freelancer

2. Traçabilité MCU/MC « gérer utilisateur » :
Figure 47:traçabilité MCU/MC « gérer utilisateur »
IUHomeEntrepreneur : c’est une classe de type Interface utilisateur à travers laquelle

l’entrepreneur interagit pour consulter son compte.
IUmodifier : c’est une classe de type Interface utilisateur à travers laquelle l’entrepreneur
interagit pour modifier ses données.
IUhomeFreelancer : c’est une classe de type Interface utilisateur à travers laquelle le
Freelancer interagit pour consulter son compte.
IUconsulterFreelancer et IUconsulterEntrepreneur : ces sont des classes de type
Interface utilisateur à travers lesquelles l’administrateur interagit pour consulter les utilisateurs.
Controller_Freelancer et Controller_Entrepreneur : ces sont des classes de type
Controller, elles jouent le rôle d’intermédiaire entre les classes de type Interfaces utilisateur et la
classe de type Model (freelancer et entrepreneur).
Entrepreneur et Freelancer : ces sont des classes de type Model qui concernent les
informations.

IUconsulterStatistique : c’est une classe de type Interface utilisateur à travers laquelle
l’administrateur interagit pour consulter les statistiques de site.
1. Diagramme de séquence « gérer utilisateur » :

a. Modifier profile :
Figure 48:diagramme de séquence de sous CU « modifier profile »

b. Supprimer profile :
Figure 49:diagramme de séquence de sous CU « supprimer profile »

3. Diagramme de classe de conception « gérer utilisateur » :
Figure 50:diagramme de classe de conception « gérer utilisateur »

VI. Conception du cas « gérer offre »
1. Diagramme classe d’analyse « gérer offre » :
Figure 51:diagramme de classe d’analyse « gérer offre » : entrepreneur

Figure 52:diagramme de classe d’analyse « gérer offre » : Freelancer
Figure 53:diagramme de classe d’analyse « gérer offre » : administrateur

2. Traçabilité MCU/MC « gérer offre » :
Figure 54:traçabilité MCU/MC « gérer offre »
IUAjouterPost : c’est une classe de type Interface utilisateur à travers laquelle l’entrepreneur
interagit pour ajouter un nouveau poste.
IUindexPost : c’est une classe de type Interface utilisateur à travers laquelle l’entrepreneur
interagit pour consulter (modifier, supprimer) ses postes.
IUModifierPost : c’est une classe de type Interface utilisateur à travers laquelle l’entrepreneur
interagit pour modifier un poste.
Controller_IndexPost : c’est une classe de type Controller, elle joue le rôle d’intermédiaire
entre les classes de type interface utilisateur (IUModifierPost et IUindexPost) et la classe de type
Model.
Controller_AjouterPost : c’est une classe de type Controller, elle joue le rôle d’intermédiaire
entre la classe de type interface utilisateur (IUAjouterPost) et la classe de type Model.
Offre : c’est une classe de type Model qui concerne les informations d’une offre.
IUPostulerOffre : c’est une classe de type Interface utilisateur à travers laquelle le freelancer
interagit pour postuler une offre.
Demande : c’est une classe de type Model qui concerne les informations de l’action postuler.
Controller_AjouterPost : c’est une classe de type Controller, elle joue le rôle d’intermédiaire
entre la classe de type interface utilisateur (IUPostulerOffre) et la classe de type Model.

IUConsulterOffre : c’est une classe de type Interface utilisateur à travers laquelle
l’administrateur interagit pour consulter la liste des offres.
Controller_ConsulterOffre : c’est une classe de type Controller, elle joue le rôle
d’intermédiaire entre la classe de type Interface utilisateur (IUConsulterOffre) et la classe de
type Model (Offre).
IUconsulterSignal : c’est une classe de type Interface utilisateur à travers laquelle
l’administrateur interagit pour consulter les demandes de signal.
Signal : c’est une classe de type Model qui concerne les informations de l’action signaler.
Controller_signal : c’est une classe de type Controller, elle joue le rôle d’intermédiaire entre
la classe de type interface utilisateur (IUconsulterSignal) et la classe de type Model (Signal).
3. Diagramme de séquence « gérer offre » :

a. Signaler offre:
Figure 55:diagramme de séquence de sous CU « signaler offre »
Année universitaire : 2017-2018

b. Vérifier signal :
Figure 56:diagramme de séquence de sous CU « vérifier signal »

c. Ajouter offre :
Figure 57:diagramme de séquence de sous CU « ajouter offre »

d. Modifier offre :
Figure 58:diagramme de séquence de sous CU « modifier offre »

e. Supprimer offre :
Figure 59:diagramme de séquence de sous CU « supprimer offre »

f. Postuler offre :
Figure 60:diagramme de séquence de sous CU « postuler offre »

4. Diagramme de classe de conception « gérer offre » :
Figure 61:diagramme de classe de conception « gérer offre »

VII. Conception du cas « gérer test QCM » :
1. Diagramme de classe d’analyse « gérer test QCM » :
Figure 62:diagramme de classe d’analyse « gérer test QCM » : entrepreneur

Figure 63:diagramme de classe d’analyse « gérer test QCM » : administrateur
Figure 64:diagramme de classe d’analyse « Gérer test QCM » : Freelancer

2. Traçabilité MCU/MC « gérer test QCM » :
Figure 65:traçabilité MCU/MC « gérer test QCM »
IUAjouterTest : c’est une classe de type Interface utilisateur à travers laquelle l’entrepreneur
interagit pour ajouter un nouveau test.
IUindexQuiz : c’est une classe de type Interface utilisateur à travers laquelle l’entrepreneur
interagit pour consulter (modifier, supprimer) ses tests.
IUindexQuiz : c’est une classe de type Interface utilisateur à travers laquelle le freelancer
interagit pour voir les tests.
IUModifierTest : c’est une classe de type Interface utilisateur à travers laquelle l’entrepreneur
interagit pour modifier un test.
Controller_Test : c’est une classe de type Controller, elle joue le rôle d’intermédiaire entre les
classes de type interface utilisateur (IUAjouterTest et IUindexTest) et la classe de type Model.
Controller_reponse : c’est une classe de type Controller, elle joue le rôle d’intermédiaire
entre la classe de type interface utilisateur (IUAjouterTest) et la classe de type Model.
Controller_Question : c’est une classe de type Controller, elle joue le rôle d’intermédiaire
entre la classe de type interface utilisateur (IUAjouterTest) et la classe de type Model.
Question : c’est une classe de type Model qui concerne les informations d’une question.
Réponse : c’est une classe de type Model qui concerne les informations d’une réponse.

Test : c’est une classe de type Model qui concerne les informations d’un test.
IUPasseTest : c’est une classe de type Interface utilisateur à travers laquelle le freelance
interagit pour passer un test.
Test-Freelancer : c’est une classe de type Model qui concerne les informations du score d’un
test passé.

3. Diagramme de séquence « gérer test QCM » :
a. Ajouter test QCM ;
Figure 66:diagramme de séquence de sous CU « ajouter test QCM »

b. Modifier test QCM :
Figure 67:diagramme de séquence de sous CU « modifier test QCM »

c. Supprimer test QCM :
Figure 68:diagramme de séquence de sous CU « supprimer test QCM »

d. Consulter liste des candidats :
Figure 69:diagramme de séquence de sous CU « consulter liste des candidats »

4. Diagramme de classe de conception « gérer test QCM » :
Figure 70:diagramme de classe de conception « gérer test QCM »

VIII. Conception du cas « gérer test problème »
1. Diagramme de classe d’analyse « gérer test problème » :
Figure 71:diagramme de classe d’analyse « gérer test problème »

2. Traçabilité MCU/MC « gérer test problème » :
Figure 72:Traçabilité MCU/MC « gérer test problème »
Cette traçabilité consiste à identifier les classes de conception telles que (IU ajout problème,
IUindex Problemes, SphereEngine, Controller test Problème, TestProbleme, testCase) qui
participent à la réalisation de cas d’utilisation gérer test problème. En effet, c’est le Controller
TestProblème qui joue le rôle d’intermédiaire entre l’entité Problème et toutes les interfaces
utilisateurs du processus gérer test problème.

3. Diagramme de séquence « gérer test problème » :
a. Ajouter problème :
Figure 73:diagramme de séquence de sous CU « ajouter problème »

b. Modifier problème :
Figure 74:diagramme de séquence de sous CU « modifier problème »

c. Supprimer problème :
Figure 75:diagramme de séquence de sous CU « supprimer problème »

d. Consulter problème :
Figure 76:diagramme de séquence de sous CU « consulter problème »

4. Diagramme de classe de conception « gérer test problème » :
Figure 77:diagramme de classe de conception « gérer test problème »

IX. Schémas de la base de données :
Pour passer du diagramme de classe au modèle relationnel, nous avons respecté les règles
suivantes :
 Transformations des classes:

- Toutes les classes sont transformées en tableaux.
- Les attributs de la classe deviennent les attributs du tableau.
- L’identifiant de la classe est devenu la clé primaire du tableau.
En appliquant ces règles nous obtenons le schéma rationnel suivant :
 Entrepreneur (id, nom, prenom, nomEntreprise, email, motDePasse, spécialité,

logoEntreprise)
 Freelancer (id, nom, prenom, motDePasse, email, specialite, imageProfil, LinkedIn)
 Administrateur (id, login, motDePasse)
 Offer (id, specialite, typeDeProjet, description, nbFreelancer, framework, typeSalaire,
salaire, idEntrepreneur)
 Postulation (id, #idFreelancer, #idOffre, cv, lettreDeMotivation)
 Question (id, #idTest, libeller, temps)
 Réponse (id, #idQuestion, libeller, valide)
 Test (id, #idEntrepreneur, titre, objectif, catégorie, description)
 TestFreelancer (id, #idFreelancer, #idTest, nbVrai, nbFalse, nbQuestion)
 TestProbleme (id, #idEntrepreneur, createur, codeProbleme, nomProbleme,
memoirelimite, tempslimiter, visibilite, difficulté, categorie, echantillon, statement)
 Signale (id, idExpediteur, idRecepteur, commentaire, #idOffre)
 TestCase (id, input, output, time, #IdProbleme)
 Submission (pseudo, id, solution, langage, date, verdict, logs, idContetest,
codeProbleme, nameProleme, time, memory)

X. Diagramme de déploiement :
Ce diagramme de déploiement montre la disposition physique des matériels qui composent le
système et la répartition des composants sur ces matériels. Ces ressources matérielles sont
représentées sous forme de nœuds. Les nœuds sont connectés entre eux, à l’aide d’un support de
communication qui ont une nature et des caractéristiques différents.
Figure 78:diagramme de déploiement
XI. Conclusion :
Après avoir achevé l’étude conceptuelle par la représentation et l’explication des diagrammes
utilisés qui rendent notre application plus claire, il ne reste qu’à commencer à décrire notre code
en se basant sur les résultats obtenus des chapitres précédents en précisant les moyens utilisés
pour développer notre application.

Chapitre 4 : Module
d’implémentation

I. Introduction :
Dans ce chapitre, nous allons décrire la partie réalisation et la mise en œuvre du projet dans le
but de réaliser un produit complet et prêt à être exploité. Nous allons présenter dans ce chapitre
en premier lieu, la technologie et l’environnement matériel et logiciel ainsi que les outils utilisés.
Dans deuxième lieu, l’implémentation de nos cas d’utilisation à travers les diagrammes de
composants et leurs interfaces graphiques
II. Environnement de travail :

1. Environnement matériel :
Notre application a été développé sur deux PC portables ayant les caractéristiques suivantes :
Figure 79:environnement matériel

Figure 80:environnement matériel
2. Environnement logiciel :
Visual studio 2017 :
C’est un environnement de développement intègre (IDE) permettant de générer des applications
bureautiques, Web ASP.NET, des services web XML, des applications mobiles. Ainsi qu’il nous a
permis de se connecter à divers services.
Figure 81:logo Visual Studio 2017
Microsoft SQL Server 2012:

Microsoft SQL Server est un système de gestion de base de données relationnelle développé par
Microsoft. En tant que serveur de base de données, il s’agit d’un produit logiciel dont la fonction
principale consiste à stocker et à récupérer des données comme demande par d’autres
applications logicielles, qui peuvent être exécutées sur un même ordinateur ou sur un autre
ordinateur sur un réseau (y compris Internet).
Figure 82:logo Microsoft SQL Server 2012

Rational Rose :
Rational Rose est un logiciel édité par l'entreprise Rational Machines (plus tard
renommée Rational Software) pour créer et éditer les différents diagrammes du modèle UML
d'un logiciel.
Figure 83:logo rational rose
Balsamiq Mockups:
Balsamiq Mockups est un outil de Wire framing rapide qui nous aide à travailler plus vite et plus
intelligemment. Il reproduit l’expérience de l’esquisse sur un tableau blanc, mais en utilisant un
ordinateur. Faire des maquettes est rapide. Nous allons générer plus d’idées, afin de pouvoir
jeter les mauvaises et découvrir les meilleures solutions.
Figure 84:logo Balsamiq Mockups

Adobe Photoshop CC 2017:
Il est un logiciel créé par Adobe et spécialisé dans le traitement des images avec des diésèrent
outils professionnels. Nous l’avons l’utilisé pour créer le logo de notre application web.
Figure 85:logo Adobe Photoshop CC 2017
III. Langage de programmation et autres outils :

a. C-Sharp :
 C’est un langage orienté objet crée par Microsoft.
 C’est un langage fiable, puissant et la plus utilisé pour le développement des applications
.Net.
 C’est un langage bien documenté.
b. XAML :
 XAML est un langage crée par Microsoft
 Permet aux développeurs de définir des interfaces utilisateur dans Xamarin.
 Basée pour iOS, Android et dispositive mobiles UWP.
 XAML est souvent plus succinct et lisible qu'un code équivalent.
c. Html :
 C’est un langage basé sur la syntaxe XML.
 Il est utilisé pour structure une page web sur internet.
 Il est simple et lisible en codage.
d. CSS :
 C’est un langage utilisé pour mettre en forme les fichiers HTML.
 Il est utilisé pour gérer le design de la page web.

e. SQL :
Le SQL (Structured Query Language) est un langage permettant de communiquer avec une base
de données. Ce langage informatique est notamment très utilisé par les développeurs web pour
communiquer avec les données d’un site web.
f. Framework :
Asp.net :
 ASP.NET est une technique pour générer des pages web dynamiques.
 Le moteur d'ASP.NET est un filtre branché sur le serveur web Internet information
Service (IIS). Il est distribué avec le framework.NET. ASP.NET peut être utilisé avec
n'importe quel langage de programmation pour la plateforme .NET (Visual Basic.NET,
c#, jScript…).
UWP :
Plateforme d'application universelle Windows est une architecture homogène créée
par Microsoft et introduite pour la première fois dans Windows 10. L'objectif de cette plate-
forme logicielle est d'aider à développer des applications universelles qui fonctionnent sous
Windows 10, sans qu'il y ait le besoin de réécrire un nouveau code source pour chacun de ces
systèmes. Il prend en charge le développement d'applications Windows en utilisant (C++, C#,
XAML…). L'API est implémentée en C++ et prise en charge en (C++, VB.NET, C#, …). Conçu
comme une extension de la plate-forme Windows Runtime.

IV. Implémentation du cas « Authentification » :
1. Traçabilité MC/MI du cas « Authentification » :
Figure 86:traçabilité MC/MI du cas « Authentification » : administrateur

Figure 87:traçabilité MC/MI du cas « Authentification » : freelancer/entrepreneur
2. Diagramme de composants du cas « Authentification » :
Figure 88:diagramme de composants du cas « Authentification » : administrateur

Figure 89:diagramme de composants du cas « Authentification » : Freelancer
Figure 90:diagramme de composants du cas « Authentification » : entrepreneur
3. Présentation des interfaces utilisateurs réelles du cas « Authentification » :

L’interface authentification permet à l’administrateur de s’authentifier à travers un pseudo et un
mot de passe. Cette action n’est validée qu’après leur vérification dans la base de données. Si
elles sont correctes, l’utilisateur aura l’accès au menu principal de l’application, sinon un
message d’erreur s’affichera.

 Interface authentification administrateur:
Figure 91:interface d’authentification administrateur
 Interface authentification utilisateur:

L’interface permet aux utilisateurs de s’inscrire à travers un formulaire d’inscription.
Figure 92:interface inscription

V. Implémentation du cas « Gérer test problème » :
1. Traçabilité MC/MI du CU « Gérer test problème » :
Figure 93:traçabilité MC/MI du CU « Gérer test problème »
2. Diagramme de composants du cas « Gérer test problème » :
Figure 94:diagramme de composants du cas « Gérer test problème »

3. Présentation des interfaces utilisateurs réelles du cas « Gérer test
problème » :
Ces interfaces permettent à l’entrepreneur d’ajouter, modifier et supprimer les problèmes.
 Interface test problème:
Figure 95:interface de liste des tests problèmes
 Interface ajouter test problème:
Figure 96:interface ajouter test problème

 Interface modifier test problème:
Figure 97:interface modifier test problème

 Interface supprimer test problème:
Figure 98:interface supprimer test problème

 Interface passer test problème:
Cette interface permet à un freelance de passer un test problème.
Figure 99:interface passer test problème
VI. Conclusion
Lors de ce chapitre nous avons essayé de montrer le fonctionnement de notre site web. En effet,
nous avons présenté les principales interfaces graphiques avec les différents diagrammes de
composants qui nous a permis de mieux comprendre le fonctionnement de notre site web tout
en décrivant l’environnement matériel et logiciel.

Conclusion générale
L’objectif de notre projet de fin d'étude est la mise en place d'un site web Freelance, à travers
une conception détaillée et une réalisation d'un scénario mettant en valeur le bon
fonctionnement de notre système.
Ce site web va garantir essentiellement à un freelance de passer des tests de compétences
proposés par des entrepreneurs pour gagner une poste tout en offrant d'autres offres proposées.
Pour achever ce travail, nous avons sélectionner la méthode de développement logiciel «
Processus Unifié » en suivant ces différentes activités (Expressions des besoins, Conception et
Implémentation). Nous avons également choisi l’UML comme langage de modélisation et l’outil
de développement innovant et évolutive « ASP.NET » sous la Platform de développement «
Visual Studio » du Microsoft.
Grace à ce stage, nous avons pu affronter les différentes difficultés rencontrées au niveau de la
réalisation avec les recherches et la pratique. Ainsi il nous a offert l’opportunité de travailler en
groupe au sein d’une compagnie et d’avoir un esprit d’équipe et de collaboration.
Ce projet clôture notre formation pour l'obtention d'un diplôme de Licence Appliquée en
Informatique Appliquée à la Gestion et nous a permis de mettre en pratique nos connaissances
théoriques acquises auprès de nos enseignants de l'Institut Supérieur de Gestion de Sousse tout
en nous améliorant nos techniques de recherche.
Enfin, nous espérons avoir réalisé un travail sérieux et permutable.

Webographie
- http://fr.wikipedia.org/wiki/Unified_Process
- http://fr.wikipedia.org/wiki/UML_%28informatique%29
- http://fr.wikipedia.org/wiki/Diagramme_des_cas_d%27utilisation
- http://fr.wikipedia.org/wiki/Diagramme_de_s%C3%A9quence
- https://en.wikipedia.org/wiki/Balsamiq
- https://en.wikipedia.org/wiki/Microsoft_SQL_Server
- https://balsamiq.com/
- http://glossaire.infowebmaster.fr/xml
- http://sql.sh/
- https://docs.microsoft.com/en-us/xamarin/xamarin-forms/xaml/xaml-basics/

Rapport Final

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Final

Transféré par

Droits d'auteur :

Formats disponibles

Ministère de l’enseignement supérieur et de la recherche scientifique

Mémoire de stage de fin d’étude

Application web : « conception et développement d’une application Freelance »

Lieu de stage : Geek Innovation Center

ELABORE PAR : ENCADRE PAR :

Année universitaire 2017-2018

Nous tenons à remercier tout particulièrement et à témoigner toute notre reconnaissance à

Rim & Rakia

Année universitaire 2017-2018

A nos chers parents

A nos familles, frères et sœurs pour leurs soutiens moraux.

Rim & Rakia

Année universitaire 2017-2018

Année universitaire 2017-2018

Année universitaire 2017-2018

Année universitaire 2017-2018

Année universitaire 2017-2018

Année universitaire 2017-2018

Année universitaire 2017-2018

Année universitaire 2017-2018

Année universitaire 2017-2018

Année universitaire 2017-2018

Au sein de l’entreprise « Greek Innovation Center », nous sommes reconnaissantes au bon

Année universitaire 2017-2018

Année universitaire 2017-2018

II. Présentation de l’organisme :

Figure 1:Logo de la société d'accueil

 Le développement des applications web,

 Le développement des applications mobile,

 Création de solution Cloud pour les Entreprises.

Année universitaire 2017-2018

Figure 2:Organigramme de la société d’accueil

Greek Academy Pays_Bas

III. Cadre du projet :

Année universitaire 2017-2018

Elle se décline ainsi en de multiples tâches :

Afin de valoriser les compétences, la motivation, l’information et l’organisation, il est possible de

 Le recrutement. En évaluant les compétences et la motivation lors du recrutement, on

Année universitaire 2017-2018

Figure 3:Les principes de GRH

Année universitaire 2017-2018

Figure 4:Schéma illustrant le système d’information

IV. Etude de l’existant :

Figure 5:Logo d’un site web freelance tunisien

Année universitaire 2017-2018

Figure 7:Capture de la page d’accueil d’un site web freelance tunisien

Année universitaire 2017-2018

Figure 9:Capture des informations trouvées sur un site web freelance

Figure 10:Capture d’une offre postulée dans un site web freelance

Année universitaire 2017-2018

Nous allons citer des différents inconvénients :

- Design et ergonomie : choix des couleurs, difficiles pour les daltoniens…

V. Spécification des besoins :

Notre application permet de :

 Gérer les partenaires,

 Déposer des offres d’emploi,

 Gérer les tests d’évaluation (QCM et problèmes),

 Consulter les tests et les offres,

Année universitaire 2017-2018

2. Identification des besoins non fonctionnels :

Année universitaire 2017-2018

Figure 11:chronogramme de travail

Année universitaire 2017-2018

Année universitaire 2017-2018