Rapport Mariem VF

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Université de la Manouba
Institut Supérieur des Arts Multimédias
MEMOIRE DE PROJET DE FIN D’ETUDES

Code IM21
PLATEFORME FREELANCE
Réalisé par
Mariem Bousaid 3IM4
Islem Ayari 3IM4
Encadré par
Mariem Fallah ISAMM
Khalil Terzi 360DEV
Tayeb Chargui 360DEV
Année Universitaire 2017-2018

Dédicaces
Je remercie Dieu le tout puissant pour l’aide, le courage et la patience

qu’Il m’a accordé tout au long de mon cursus…
A mes chers parents pour tous leurs sacrifices, leur amour, leur
tendresse, leur soutien et leurs prières tout au long de mes études…
A mes chers frères, pour leur appui, leur encouragement et leur

continuel soutien moral…
A toute ma famille pour leur soutien tout au long de mon parcours

universitaire…
Pour n’en oublier aucun, à tous mes amis, qui ont été toujours présents
avec leur soutien…
À tous ceux qui m’ont aidé afin de réaliser ce travail,

À tous ceux que j’aime et qui m’aiment,
Que ce travail soit l’accomplissement de vos vœux tant allégués, et le

fuit de votre soutien infaillible,
Merci d’être toujours là pour moi.

Maryem
Rapport de projet fin d’études 2017/2018

Dédicaces
A mes chers parents : Tous les mots du monde ne sauraient exprimer

l’immense amour que je vous porte, ni la profonde gratitude que je vous
témoigne pour tous les offres et les sacrifices que vous n’avez jamais
cessé de consentir pour mon bien-être.
Je dédie aussi ce travail à :
Ma binôme Mariem, qui m'a encouragé et m'a soutenu tout au long de

la période de stage.
Mes chers amis : Pour leur encouragement et pour tous les bons
moments qu’on a vécus ensemble. J’espère que notre amitié durera
éternellement.
Et à toute ma famille et à tous ceux que j’aime.
Islem

Remerciements
Au terme de ce travail, Nous tenons à exprimer notre profonde

gratitude à notre chère professeur et encadrant Mme Meriem Fellah
pour son suivi et pour son énorme soutien, qu’elle n’a cessé de nous
prodiguer tout au long de la période du projet.
Nous tenons à remercier également nos encadrants M. Khalil Terzi et

M. Taieb Chargui pour le temps qu’ils ont consacré tout au long de
cette période de stage et pour les précieuses informations qu’ils nous
ont prodiguées avec intérêt et compréhension.
Nous adressons aussi nos vifs remerciements aux membres des jurys pour
avoir bien voulu examiner et juger ce travail.
Nos remerciements vont à tout le personnel que nous avons contacté

durant notre stage au sein de 360dev, auprès desquelles nous avons
trouvé l’accueil chaleureux, l’aide et l’assistance dont nous avons besoin.
Nous ne laisserons pas cette occasion passer, sans remercier tous les
enseignants et le personnel de L’institut supérieur des arts de
multimédia et particulièrement ceux de la section informatique et
multimédia pour leur aide et leurs précieux conseils et pour l’intérêt
qu’ils portent à notre formation.
Enfin, nos remerciements à tous ceux qui ont contribué de prés ou de

loin au bon déroulement de ce projet.

Table des matières
INTRODUCTION GENERALE .............................................................................................................................. 1
CHAPITRE 1 : ETUDE PREALABLE....................................................................................................................... 3
1.1. PRESENTATION DE LA SOCIETE D’ACCUEIL ............................................................................................................... 4

1.2. PRESENTATION DU SUJET .................................................................................................................................... 4
1.3. ETUDE DE L’EXISTANT......................................................................................................................................... 5
1.3.1. UpWork ................................................................................................................................................ 5
1.3.2. Freelancer ............................................................................................................................................. 7
1.3.3. Uprod’it................................................................................................................................................. 9
1.4. CRITIQUE DE L’EXISTANT ................................................................................................................................... 11
1.5. SOLUTION PROPOSEE ....................................................................................................................................... 11
1.6. CONCLUSION.................................................................................................................................................. 12
CHAPITRE 2 : SPECIFICATION DETAILLEE ......................................................................................................... 13
2.1. PRESENTATION DE LA METHODOLOGIE ET LANGAGE ADOPTE .................................................................................... 14

2.1.1 Scrum ................................................................................................................................................... 14
2.1.2. Langage de modélisation (UML)......................................................................................................... 17
2.2. ANALYSE DES BESOINS...................................................................................................................................... 17
2.2.1. Besoins fonctionnels .......................................................................................................................... 18
2.2.2. Besoins non fonctionnels ................................................................................................................... 19
2.3. LE DIAGRAMME DE CAS D’UTILISATION ................................................................................................................ 22
2.3.1. Identification des acteurs ................................................................................................................... 22
2.3.2 Diagramme de cas d’utilisation global ................................................................................................ 23
2.3.3 Diagrammes de cas d’utilisation détaillés ........................................................................................... 24
2.4. DIAGRAMMES DE SEQUENCE SYSTEME ................................................................................................................. 29
2. 4.1 Description textuelle et interaction système : Authentification ......................................................... 30
2.4.2 Description textuelle et interaction système : Acheter un abonnement.............................................. 32
2.4.3 Description textuelle et interaction système : Demander un service ................................................... 33
2.4.4. Description textuelle et interaction système : Vérifier service ............................................................ 36
2.4.5. Description textuelle et interaction système : créer une notification ................................................. 38
2.5. PILOTAGE DU PROJET AVEC SCRUM ................................................................................................................... 39
2.5.1Backlog du produit : ............................................................................................................................. 40
2.5.2 La planification des sprints et releases ................................................................................................ 43
2.6. CONCLUSION.................................................................................................................................................. 43
CHAPITRE 3 : CONCEPTION DE LA SOLUTION .................................................................................................. 45
3.1. CONCEPTION TECHNIQUE GLOBALE ..................................................................................................................... 46

3.2 CONCEPTION TECHNIQUE DETAILLEE .................................................................................................................... 47
3.2.1 Représentation de la vue statique ....................................................................................................... 47
3.2.2 Représentation de la vue dynamique .................................................................................................. 52
3.3. CONCEPTION GRAPHIQUE ................................................................................................................................. 54
3.3.1 Maquette ............................................................................................................................................. 54
3.3.2 Schéma de navigation ......................................................................................................................... 57
3.3.3 Charte graphique ................................................................................................................................. 59
3.4. DESCRIPTION DES SPRINTS ................................................................................................................................ 60
3.4.1 Sprint 1 : « inscription, authentification et gestion des utilisateurs » ................................................. 60
3.4.2 Sprint 2 : « Gestion des abonnements et gestion des domaines » ...................................................... 61
3.4.3 Sprint 3 : « Gestion des services et gestion des abonnements » ......................................................... 63
3.4.4 Sprint 4 : « Contact et statistiques » .................................................................................................... 64
3.5. CONCLUSION :................................................................................................................................................ 65
CHAPITRE 4 : REALISATION ET TESTS .............................................................................................................. 66
4.1. ENVIRONNEMENT DE TRAVAIL............................................................................................................................ 67

4.1.1. Environnement matériel ..................................................................................................................... 67
4.1.2. Environnement logiciel ....................................................................................................................... 67
4.1.3 Diagramme de déploiement ................................................................................................................ 72
4.2. DESCRIPTION DES INTERFACES GRAPHIQUES DE L’APPLICATION ................................................................................. 73
4.2.1. Interfaces liées à un visiteur ............................................................................................................... 73
4.2.2. Interfaces liées à un client .................................................................................................................. 76
4.2.3. Interfaces liées à un superviseur ......................................................................................................... 79
4.2.4. Interfaces liées à un agent de service ................................................................................................. 81
4.2.5. Interfaces liées à un agent d’alerte .................................................................................................... 83
4.2.6. Interfaces liées à l’administrateur ...................................................................................................... 84
4.3. EVALUATION DE LA QUALITE DU PROCESSUS DE DEVELOPPEMENT ............................................................................. 85
4.3.1. Revue de release 1 .............................................................................................................................. 85
4.3.2 Revue du release 2 ............................................................................................................................... 87
4.4. CONCLUSION.................................................................................................................................................. 90
CONCLUSION GENERALE ................................................................................................................................ 91
WEBOGRAPHIE ............................................................................................................................................... 93

Liste des figures
Figure 1.1: Page d'accueil d’UpWork....................................................................................................... 5

Figure 1.2: Page d'accueil de Freelancer ................................................................................................. 8
Figure 1.3: Page d'accueil de Uprod’it ................................................................................................... 10
Figure 2.1: Vue globale de Scrum .......................................................................................................... 15
Figure 2.2: Le modèle générale de la norme ISO 9126 ......................................................................... 20
Figure 2.3: Le modèle de qualité du système avec la norme ISO 9126................................................. 21
Figure 2.4: Héritage des acteurs............................................................................................................ 23
Figure2.5 : diagramme de cas d’utilisation global................................................................................. 24
Figure 2.6 : Diagramme de cas d’utilisation relatif à l’administrateur .................................................. 25
Figure 2.7 : Diagramme de cas d’utilisation relatif à l’agent d’alerte ................................................... 26
Figure 2.8 : Diagramme de cas d’utilisation relatif au superviseur ....................................................... 27
Figure 2.9 : Diagramme de cas d’utilisation relatif à l’agent de service ............................................... 28
Figure 2.10 : Diagramme de cas d’utilisation relatif au client ............................................................... 29
Figure 2.11: Diagramme de séquence du cas d’utilisation « Authentification » .................................. 31
Figure 2.12: Diagramme de séquence du cas d’utilisation « Acheter un abonnement » ..................... 33
Figure 2.13: Diagramme de séquence du cas d’utilisation « Demander un service » .......................... 35
Figure 2.14: Diagramme de séquence du cas d’utilisation « Vérifier un service» ................................ 37
Figure 2.15: Diagramme de séquence du cas d’utilisation « Créer une notification» .......................... 39
Figure 2.16: Interface scrumwise représentant l’équipe de travail ...................................................... 40
Figure 2.17 : Plan de release ................................................................................................................. 43
Figure 3.1 : Modèle MVC ....................................................................................................................... 47
Figure 3.2 : Diagramme de classe .......................................................................................................... 52
Figure 3.3: Diagramme d’activité de l’inscription d’un client ............................................................... 53
Figure 3.4: Diagramme d’activité de demande d’un service................................................................. 54
Figure 3.5 : l’interface d’un compte client ............................................................................................ 55
Figure 3.6 : la page d’achat d’un abonnement...................................................................................... 55
Figure 3.7 : La page de demande d’un service ...................................................................................... 56
Figure 3.8: La page de la liste des services ............................................................................................ 56
Figure 3.9: schéma de navigation de la session administrateur ........................................................... 57
Figure 3.10 : schéma de navigation de la session client........................................................................ 58
Figure 3.11: schéma de navigation de la session superviseur .............................................................. 58

Figure 3.12 : schéma de navigation de la session agent d’alerte .......................................................... 58
Figure 3.13: schéma de navigation : Schéma de navigation de la session agent de service................. 59
Figure 3.14 : interface scrumwise du sprint1 ........................................................................................ 61
Figure 4.1 : Modèle d’architecture 3-tiers ............................................................................................ 68
Figure 4.2 : Diagramme de déploiement............................................................................................... 72
Figure 4.3 : Interface de contact ........................................................................................................... 73
Figure 4.4 : Interface d’accueil .............................................................................................................. 74
Figure 4.5 : Interface d’inscription ........................................................................................................ 75
Figure 4.6 : Interface d’authentification ............................................................................................... 76
Figure 4.7 : Interface d’accueil d’un compte client ............................................................................... 77
Figure 4.8 : Interface d’achat d’un abonnement .................................................................................. 77
Figure 4.9 : Interface de demande d’un service .................................................................................... 78
Figure 4.10 : Interface de la liste des notifications ............................................................................... 78
Figure 4.11 : Interface de la liste des services ....................................................................................... 79
Figure 4.12 : Interface de consultation d’un nouveau service .............................................................. 80
Figure 4.13 : Interface de création d’une notification .......................................................................... 80
Figure 4.14 : Interface de traitement d’un service................................................................................ 81
Figure 4.15 : Interface de payement ..................................................................................................... 82
Figure 4.16 : Interface de modification de profile d’un agent de service ............................................. 82
Figure 4.17 : Interface de la liste des abonnements ............................................................................. 83
Figure 4.18 : Interface de consultation des services ............................................................................. 83
Figure 4.19 : Interface de création d’un employé ................................................................................. 84
Figure 4.20 : Interface de la liste des domaines .................................................................................... 84
Figure 4.21 : Tableau des tâches du sprint1 .......................................................................................... 85
Figure 4.23 : Burndown chart du sprint1 .............................................................................................. 86
Figure 4.24 : Burndown chart du sprint2 .............................................................................................. 87
Figure 4. 27: Burndown chart du sprint3 .............................................................................................. 89
Figure 4.28: Burndown chart du sprint4 ............................................................................................... 89

Liste des Tableaux
Tableau 2.1: Description textuelle du cas d'utilisation "Authentification" ........................................... 31

Tableau 2.2: Description textuelle du cas d'utilisation "Acheter un abonnement".............................. 32
Tableau2.3: Description textuelle du cas d'utilisation "Demander un service" .................................... 34
Tableau 2.4: Description textuelle du cas d'utilisation "Vérifier un service" ........................................ 36
Tableau 2.5: Description textuelle du cas d'utilisation "créer une notification" .................................. 38
Tableau 2.6 : Backlog de produit ........................................................................................................... 43
Tableau 3.1 : Description des classes .................................................................................................... 50
Tableau 3.2: Backlog du sprint1 ............................................................................................................ 61

Introduction générale
Actuellement, on vit dans un environnement numérique. Toutes les découvertes

technologiques ont été inventées pour satisfaire les besoins de l’homme. En fait, elles visent à
faciliter notre quotidien garantissant ainsi à l’homme une totale liberté, le gain de temps,
l’accroissement de la productivité ou simplement le confort. Elles nous offrent une nouvelle
possibilité qui consiste à travailler à notre compte comme travailleur indépendant. Un autre
terme désigne également cette activité : le Freelance.
Un Freelancer est une personne qui vend sa prestation à la journée, à l’heure, au forfait. Il
prospecte ses propres clients et s’autogère. Il définit sa mission avec son client et la réalise
ensuite lui-même. Les secteurs les plus concernés par le Freelance sont tous les métiers dits
« intellectuels » comme traducteurs, métiers touchant à l’informatique, photographes,
graphistes… Internet a facilité l’expansion de ce mode de travail dans les secteurs comme le
développement de software, dessinateur web, technologie de l’information et de la
documentation pour l’entreprise. Cela permet donc au Freelancer de travailler à une distance
éloignée de son client et dans différents pays. Ce mode de travail se développe énormément,
c’est pour cela que nous pourrons trouver beaucoup de sites d’offres d’emploi dédiés au
Freelance.
Dans ce contexte et dans le cadre du projet de fin d’étude pour l’obtention du diplôme de
licence fondamentale en informatique et multimédia à l’Institut Supérieure d’Arts Multimédia
(ISAMM), nous avons été invités à travailler au sein de la société 360dev pour l’élaboration
d’une plateforme Freelance constituée d’une interface permettant à un membre Freelancer de
vendre des services à un client servant à ses besoins. Cette solution garantit aux clients un
service rapide et avec une exigence de qualité. Ainsi, elle facilite le travail pour le client et le
travailleur.
La problématique à laquelle on essaie de répondre dans ce projet est de simplifier et faciliter

l’interaction entre le client et les employés fournisseurs de services, permettre le gain de
temps et d’argent et enfin, offrir des opportunités d'emploi pour les nouveaux diplômés. Pour
cela, une interface web dédiée à répondre à ces objectifs semble être la bonne solution.
Rapport de projet fin d’études 2017/2018 1

Ce rapport vise à décrire et expliquer le sujet du projet, ses différentes phases, les méthodes,
les outils et les résultats et sera traité en 4 chapitres :
Le premier chapitre « Etude préalable » comporte la présentation de la société d’accueil

ainsi que la présentation du sujet, une étude suivie d’une critique de quelques sites similaires
en proposant les solutions.
Le second chapitre est intitulé « Spécifications détaillées ». Il s’agit d’une partie qui sera
consacrée pour la représentation de la méthodologie de travail et les langages adoptés.
Ensuite, il y aura une analyse de besoins fonctionnels et non fonctionnels ainsi que la
représentation des diagrammes des cas d’utilisations et les diagrammes de séquence système.
Enfin il ya une représentation de la gestion du projet avec la méthodologie SCRUM.
Le troisième chapitre nommé « Conception de la solution ». Ce chapitre représente la partie

conception du système à travers une présentation de l’architecture utilisée, de la description
détaillée des classes, des règles de gestion, du diagramme de classe et des diagrammes
d’activités.
Le quatrième et dernier chapitre « Réalisation et tests » suivra à décrire l’environnement du

travail et tous les aspects techniques ainsi que le diagramme de déploiement. L’évaluation de
la qualité du processus de développement terminera ce chapitre.
2
Chapitre 1 : Etude préalable
3
Etude préalable
C
e chapitre a pour objectif de situer notre sujet dans son contexte général. Nous
commençons par une présentation de la société d’accueil « 360dev». Après, nous
décrivons brièvement le sujet à traiter et les objectifs à atteindre. Enfin, nous
présentons une étude de l’existant et une analyse des applications similaires ainsi qu’une
critique de l’existant, et nous proposons des solutions qui pourront remédier aux problèmes
constatés.
1.1. Présentation de la société d’accueil

La société 360 DEV 1
est fondée en juin 2017 par des jeunes compétences dans l’objectif
d’apporter une nouvelle vision dans le domaine de l’informatique.
L’entreprise progresse bien évidemment en adéquation permanente avec la révolution

informatique et s'est perpétuellement attachée à la quête des moyens technologiques les plus
performants permettant la réalisation des applications propres telles que la création des sites
web, des logiciels, création application mobiles, optimisation du moteur de recherche… pour
ainsi répondre le plus efficacement possible au besoin de sa clientèle.
La société s'attache à la collaboration d'une équipe jeune et dynamique qui dispose d'un large
panel de savoir-faire, réalise ainsi des opérationnels en cohérence avec les demandes précises
de ses clients.
L'entreprise travaille dans le respect constant des normes et des règles en vigueur pour vous
garantir une qualité de travail indéniable.
L'entreprise est née d'une grande passion pour l'informatique c’est ce qui fait que son service
méticuleux et raffiné soit le meilleur.
1.2. Présentation du sujet

Notre projet consiste à la création d’une plateforme Freelance permettant aux employés de
vendre des services aux clients selon des besoins spécifiques. Cette application simplifie et
facilite le travail pour le client et l’employé en garantissant des services rapides et avec une
exigence de qualités pour le client et en offrant des opportunités d’emploi dans des conditions
favorables pour l’employé.
1
www.360dev.info
4
Etude préalable
En effet, cette Plateforme impose au client l’achat d’un abonnement avant la demande d’un
service ce qui garantit les droits de l’employé et assure une motivation pour tous les
utilisateurs. Par ailleurs la plateforme concerne une alerte pour les employés et une
supervision pour les services afin d’être sure que les services seront traités rapidement et en
satisfaisant les besoins des clients.
1.3. Etude de l’existant

L’étude de l’existant fournit une base de référence pour la suite du projet comme elle sert à
approfondir l’analyse des dimensions innovantes de notre travail. Au cours de cette étape,
nous procédons à la revue de quelques applications similaires.
1.3.1. UpWork
UpWork2 est une plateforme qui réunit des freelances et des employeurs en ligne. Elle a bien
marché au niveau international.
Description
UpWork est une plateforme qui nous permet de s’inscrire à des projets à court ou long terme
et choisir de travailler à l'heure ou être payé par projet. Le site dispose d'une fonctionnalité de
chat facile à utiliser, d'un traceur temporel et d'un plan de protection des paiements pour
faciliter la communication et la collaboration avec le client. La figure 1.1 montre l’interface
d’accueil de ce site.
Figure 1.1: Page d'accueil d’UpWork

2
www.upwork.com
5
Etude préalable
Fonctionnalités
UpWork permet aux utilisateurs de :
• Chercher, trouver et postuler à un emploi

• Poster un emploi
• Recevoir des messages d’une façon instantanée
• Suivre les statistiques des heures de travail effectuées
• Suivre les statistiques des revenus obtenus durant une période
• Recevoir un rapport quotidien des travaux effectués durant une période donnée
• Suivre l’évolution de travail à travers un outil de suivi (le client recevoir des
captures d’écran chaque 10 minutes et le nombre des heures ainsi le nombre de
clique de souris et touche de clavier).
Critique
Points forts :
• Fonds reçus transférables en seulement 6 jours pour des raisons de sécurité.

• Accepte plusieurs moyens de transferts de fonds : Payoneer, Skrill, PayPal,
Virement bancaire, etc.
• Offre des rapports journaliers, hebdomadaires, mensuels et annuels : travaux
effectués, heures effectuées.
• Offre la possibilité de travailler hors ligne si votre recruteur vous y autorise,
3
pratique dans les cas où Bénin Télécoms annonce que le câble sous-marin a été
heurté et coupé.
• Mets l’accent plus sur les projets payés à l’heure.
• Offre un outil de suivi (capture d’écran automatique)
• Comptage du nombre de touches pianotées
• Comptage du nombre de clicks sur la souris
• Comptage du nombre d’heures effectuées
Bénin Télécoms: c’est l’opérateur historique des télécommunications au Bénin fondé en mai 2004
3
suite à la scission de l'Office des Postes et Télécommunications
6
Etude préalable
Points faibles :
• La Plateforme est non disponible en français.

• Pas de recherche.
• Le Freelancer doit payer 20 % de l'argent gagné pour les frais de service.
• La Plateforme déduit 30 dollars pour chaque virement bancaire.
• La désactivation du profil au bout de 30 jours d’inactivité. Pour maintenir un profil
public il faut payer 10 dollars par mois.
1.3.2. Freelancer
Freelancer4 est une plateforme jeune créée en 2004 en Australie. Elle est la plateforme
grand public des freelances. Elle nous permet de poster des offres d’emploi ou postuler
à des offres. Elle est notamment utilisée par Microsoft, DHL 5, IBM 6 pour embaucher des
freelances.
Description
C’est une plateforme qui permet aux Clients de publier simplement une tâche qu’ils doivent
faire réaliser et par la suite ils vont recevoir des offres compétitives des freelances en
quelques minutes. Peu importe vos besoins, il y aura un freelance pour y répondre : depuis le
design Internet, le développement d'applications mobiles, les assistants virtuels, la fabrication
de produits et le design graphique (et bien plus encore) avec des paiements sûrs et de milliers
de professionnels évalués parmi lesquels choisir. Freelancer.com est la manière la plus simple
et la plus sûre de faire réaliser du travail en ligne. La figure 1.2 montre l’interface d’accueil de
ce site.
4
www.freelancer.com
5
DHL: C’est un groupe spécialisé en transport et logistique
6
IBM: c’est une société multinationale américaine
7
Etude préalable
Figure 1.2: Page d'accueil de Freelancer
Fonctionnalités
Freelancer permet aux utilisateurs de :
• poster des offres d’emploi

• postuler à des offres
• Parcourir les profils des freelances
• Discutez en temps réel
• Comparer les propositions
• Sélectionnez un freelance préféré et décerner-lui le travail
• Le freelance commencera à travailler tout de suite.
• Payez lorsque vous êtes satisfait
Critique
Points forts :
• Le client ne doit payer pour le travail que lorsqu'il a été complété et lorsqu’il est
satisfait à 100 %.
• Le client reçoit gratuitement des offres de freelances talentueux en quelques
secondes.
8
Etude préalable
• Le site est toujours disponible pour aider les utilisateurs. Le support est fait par
des vraies personnes disponibles 24/7.
• Possibilité de discussion en direct avec les freelances pour obtenir des mises à
jour permanentes concernant les progrès sur la tâche.
• Restez à jour et restez connecter lors de vos déplacements avec notre suivi des
heures et avec notre application mobile.
• Trouver des professionnels à qui nous pouvons faire confiance en parcourant des
exemples de leurs travaux antérieurs et en lisant leurs commentaires sur leur profil.
Points faibles :
• certains membres ne sont pas assez sérieux.

• Pas beaucoup de visibilité sur les projets à long terme.
• Le processus de retrait prend quelques jours.
1.3.3. Uprod’it
Uprod’it7 est la plateforme tunisienne des freelances entreprises et organismes de trois,

principaux domaines: Les arts audio visuels, L’informatique et la technologie, la
communication. Elle est un réseau social professionnel spécialisé dans le recrutement de
profils freelances en Tunisie élaboré par une équipe d’ingénieurs franco-tunisiens.
Description
Uprod’it est une plateforme qui permet aux freelances de mettre en avant leur identité
professionnelle, talents et compétences afin de trouver des opportunités d'affaires proposées
par les entreprises et les clients. Elle permet aux entreprises de promouvoir leur image et
produits, d'émettre des offres de travail pour freelances mais aussi de gérer collaborative ment
leur grands projets. Ainsi elle permet aux associations et organismes d'agrandir leur réseau de
connaissances, d'être constamment à jour sur les évènements du domaine et d'accroitre la
visibilité de leurs propres évènements. La figure 1.3 montre l’interface d’accueil de ce site.
7
www.uprodit.com
9
Etude préalable
Figure 1.3: Page d'accueil de Uprod’it
Fonctionnalités
Uprod’it permet aux utilisateurs de :
• Créer un profil en tant que freelance, Entreprise, Organisme et Client.

• Chercher, trouver et postuler à un emploi.
• Parcourir les pages des entreprises et des organismes.
• Consulter les profile des freelances.
• Visiter le journal d’événement et le forum.
• Communiquer entre eux à travers une messagerie interne.
Critique
Points forts :
• Créer un profil adapté à la valorisation des compétences (porte-folio, curriculum vitae,

Compétences. . .).
• visualiser les pages des entreprises et organismes (contacts, projets passés,
évènements. . .).
• Être constamment à jour grâce à un journal des actualités en Tunisie (évènements. . .).
• Accéder à des pages de recherche pertinentes vers des classements selon des critères
particuliers.
• Être en communication avec les différents membres par une messagerie interne.
10
Etude préalable
Points faibles :
• L’application web est un peu lente

• L’utilisateur doit scroller plusieurs fois pour arriver à la bonne information
• Si un membre ajoute des informations, il n’aura plus le droit de les modifier
1.4. Critique de l’existant

Afin d’approfondir notre compréhension du sujet et avoir une idée plus claire sur ses
fonctions attendues, nous avons étudié quelques plateformes similaires et nous avons relevé
les faiblesses à éviter et les points forts à retenir de chaque application.
Nous avons remarqué que le critère de suivi de projet est important surtout lorsque le travail
est payé par heure. Ce critère est respecté dans UpWork, mais pas dans Freelancer et
Uprod’it ainsi que dans la plupart des sites de freelance. On trouve aussi que le critère de
recherche est très important il nous permet d’éviter le gaspillage de temps à travers une
simple recherche d’un employé selon les domaines et selon les compétences a partir de son
profile et l’évaluation de ses anciens projets réalisés. Cela est bien respecte par Uprod’it mais
pas dan Upwork.
Alors ce critère nous aide à éviter le risque d’avoir des employés qui ne sont pas assez
sérieux.
De plus nous avons remarqué que le payement est généralement assez lent et il ya aussi
manque de visibilité sur les projets à long terme. Alors nous avons constaté que dans toutes
les applications similaires il y a toujours un ensemble de critères importants qui n’est pas
établi. Donc, nous avons décidé de développer une plateforme Freelance adaptée aux besoins
de clients ainsi que des freelances en garantissant un payement rapide, un service rapide et
avec exigences de qualité en toute sécurité.
1.5. Solution proposée

Afin de pallier aux problèmes constatés au niveau de la critique des différentes applications
existantes, la solution proposée est d’implémenter une plateforme freelance offrant aux
utilisateurs un espace de travail virtuel bien organisé et bien ordonné. Dans cette plateforme
nous avons choisi d’ajouter deux acteurs. Un agent superviseur expert dans le domaine traité
responsable du contrôle des services et du choix des employés pour le traitement d’un service
(Il intervient en cas d’un problème en notifiant les utilisateurs) ; Un agent d’alerte qui
contrôle le déroulement des services, contrôle les abonnements des clients et notifie les
11
Etude préalable
utilisateurs de déroulement de ses services. La création des profiles des employés, des agents
de supervision et des agents d’alerte se fait par l’Administrateur. L’Administrateur doit bien
examiner les documents de ses agents pour éviter le problème des agents qui ne sont pas
sérieux et garantir les droits de l’utilisateur et la sécurité des données. Alors notre solution
assure le bon déroulement de travail ainsi la satisfaction des utilisateurs. Le service devient
simple et facile, en plus du gain de temps et d’argent avec des droits réservés.
1.6. Conclusion
Dans ce chapitre nous avons présenté l’environnement de notre projet à partir de la
description de la société d’accueil en premier lieu, et en second lieu la présentation du cadre
du projet à travers la présentation de notre sujet et une étude des applications existantes, en
cernant les défaillances des systèmes existants et de conclure par la proposition d’une
solution.
12
Spécification détaillée
Chapitre 2 : Spécification détaillée
Rapport de projet fin d’études 2017/2018 13

D
ans ce chapitre, nous allons illustrer la méthodologie de travail et les langages
adoptés pour la conception. Ensuite Nous allons présenter les besoins fonctionnels
et non fonctionnels de notre application puis les diagrammes des cas d’utilisations
et les diagrammes de séquence système. Enfin la gestion du projet avec la méthodologie
Scrum.
2.1. Présentation de la méthodologie et langage adopté
Pour faciliter l’étude et la documentation de notre projet, nous devons passer par une phase de
modélisation du système.
La méthodologie est la démarche que nous allons prendre pour répondre aux différentes
exigences et permettre la construction de l’application, sur le plan fonctionnel et technique.
Nous avons ainsi adopté le modèle Scrum comme processus de travail et UML comme
langage de modélisation.
2.1.1 Scrum
Scrum [1] est un schéma d’organisation de développement de produits complexes. Il est défini
par ses créateurs comme un « cadre de travail holistique itératif qui se concentre sur les buts
communs en livrant de manière productive et créative des produits de la plus grande valeur
possible ». Il est considéré en plus comme un cadre méthodologique et non à proprement
parler comme une méthode agile. Elle s'applique toutefois théoriquement à n'importe quel
contexte où un groupe de personnes travaillant ensemble pour atteindre un objectif commun.
Le choix de cette technique pour ce projet s’est basé sur les trois piliers suivants:
• Transparence : Scrum met l'accent sur le fait d'avoir un langage commun entre
l'équipe et le management. Ce langage commun doit permettre à tout observateur
d'obtenir rapidement une bonne compréhension du projet.
• Inspection : À intervalle régulier, Scrum propose de faire le point sur les différents
artéfacts produits, afin de détecter toute variation indésirable.
• Adaptation : Si une dérive est constatée pendant l'inspection, le processus doit alors
être adapté. Scrum fournit des rituels, durant lesquels cette adaptation est possible. Il
14
s'agit de la réunion de planification de sprint, de la mêlée quotidienne, de la revue de

sprint ainsi que de la rétrospective de sprint.
La figure 2.1 illustre une vue globale de Scrum.
Figure 2.1: Vue globale de Scrum
Les acteurs :
Scrum définit 3 rôles :
• Le Product Owner : qui porte la vision du produit à réaliser (représente généralement

le client). Il gère le Backlog du Produit, défini des priorités et accepte ou rejette les
livrables.
• Le Scrum Master : qui veille au bon fonctionnement de l’équipe. Il est le gardien des
pratiques de Scrum, Serviteur de l’équipe mais il n’est pas un chef de projet.
• L'équipe de développement : qui réalise le produit. Il se compose de 5 à 9 personnes

contenant toutes les compétences nécessaires pour terminer le sprint. Il est autogérée
(les décisions sont prises collectivement).
15
Les réunions :
La vie d'un projet Scrum est rythmée par un ensemble de réunions clairement définies et
strictement limitées dans le temps (timeboxing):
• Planification du Sprint (Sprint = itération) : au cours de cette réunion, l'équipe de

développement sélectionne les éléments prioritaires du Backlog de produit (liste
ordonnancée des exigences fonctionnelles et non fonctionnelles du projet) qu'elle pense
pouvoir réaliser au cours du sprint (en accord avec le « Product Owner »).
• Revue de Sprint : au cours de cette réunion qui a lieu à la fin du sprint, l'équipe de
développement présente les fonctionnalités terminées au cours du sprint et recueille les
feedbacks du Product Owner et des utilisateurs finaux. C'est également le moment
d'anticiper le périmètre des prochains sprints et d'ajuster au besoin la planification de
release (nombre de sprints restants).
• Rétrospective de Sprint : la rétrospective qui a généralement lieu après la revue de
sprint est l'occasion de s'améliorer (productivité, qualité, efficacité, conditions de
travail…) à la lueur du "vécu" sur le sprint écoulé (principe d'amélioration continue).
• Mêlée quotidienne : il s'agit d'une réunion de synchronisation de l'équipe de
développement qui se fait debout (elle est aussi appelée "stand up meeting") en 15
minutes maximum au cours de laquelle chacun répond principalement à 3 questions : «
Qu'est ce que j'ai terminé depuis la dernière mêlée ? Qu'est ce que j'aurai terminé d'ici
la prochaine mêlée ? Quels obstacles me retardent ? »
Le Backlog de produit:
Tout dans Scrum tourne autour du Backlog du produit. Ce Backlog contient, sous forme de
liste, les choses que le client veut que l'équipe réalise. C'est en quelque sorte une « liste
priorisée d'exigences, d'histoires, de caractéristiques, ou autre ». Le Backlog de produit est
maintenu par le Product Owner. Chacun peut contribuer à collecter des éléments, mais c'est le
Product Owner qui les accepte finalement et c'est lui qui définit les priorités.
Le Backlog est élaboré avant le lancement des sprints, dans la phase de préparation (ou
sprint0). Il est utilisé pour planifier la release, puis à chaque sprint, lors de la réunion de
planification du sprint pour décider du sous-ensemble qui sera réalisé. C'est donc un outil
16
essentiel pour la planification. Mais il est aussi, par sa nature, un maillon de la gestion des
exigences, puisqu'on y collecte ce que doit faire le produit.
2.1.2. Langage de modélisation (UML)
Après le choix de la méthodologie, nous avons choisi UML comme un langage de

modélisation afin de concevoir le projet.
Le langage de Modélisation Unifié (UML) est un langage de modélisation graphique à base

de pictogrammes conçu pour fournir une méthode normalisée pour visualiser la conception
d'un système. Il est couramment utilisé en développement logiciel et en conception orientée
objet.
UML est utilisé pour spécifier, visualiser, modifier et construire les documents nécessaires au
bon développement d'un logiciel orienté objet. IL offre un standard de modélisation, pour
représenter l'architecture logicielle. Les différents éléments représentables sont :
• Activité d'un objet/logiciel

• Acteurs
• Processus
• Schéma de base de données
• Composants logiciels
• Réutilisation de composants
Grâce aux outils de modélisation UML, il est également possible de générer automatiquement
tout ou partie du code d'une application logicielle, par exemple en langage Java, à partir des
divers documents réalisés. [2]
2.2. Analyse des besoins
Cette étape de spécification des besoins qui est nécessaire avant la réalisation de notre
application afin d’exposer les fonctionnalités du système. Nous allons commencer alors par la
description des besoins fonctionnels et non fonctionnels.
17
2.2.1. Besoins fonctionnels
Dans cette partie nous présentons la description des différentes actions qui peuvent être
effectuées par les acteurs.
Dans ce contexte, notre plateforme implémente les fonctionnalités suivantes :
• Inscription : Le système doit permettre à l’utilisateur de créer un compte à travers un
formulaire. Cette fonctionnalité lui permet d’avoir la visibilité sur le contenu de
l’application et avoir l’accès sur les ressources qu’elle contient.
• Authentification : Après l’étape d’inscription, l’utilisateur passe à l’authentification.

Il doit entrer son email et son mot de passe. En cas d’oubli du mot de passe,
l’utilisateur peut cliquer sur « Mot de passe oublié » et saisit son email, ensuite il doit
entrer le code qui va être envoyé à son email pour qu’il puisse finalement changer son
mot de passe et s’authentifier.
• Gestion des abonnements : Dès qu’il est authentifié, le client peut acheter un ou
plusieurs abonnements. Chaque abonnement contient un nombre d’heures. Le client
alors estime le nombre d’heures nécessaires à la réalisation de son service et confirme
l’achat de l’abonnement. Il peut aussi consulter le nombre d’heures restantes.
• Gestion des services : une fois le client a acheté un abonnement, il peut postuler un
service, recevoir un service ou modifier, supprimer un service pas encore affecté à un
agent de service. Un agent de service peut consulter les services qui ont été envoyés
par le superviseur puis envoyer le service traité qui va être vérifié aussi par le
superviseur et envoyé au client. L’agent alerte contrôle le déroulement de service et
alerte le client lorsque le service est terminé et alerte l’employé lorsqu’il n’est pas
disponible. L’administrateur doit accepter ou refuser les services. Lorsqu’il accepte un
service, il va être envoyé automatiquement au superviseur pour le vérifier.
• Gestion des comptes employés : afin de se connecter à la plateforme,

l’administrateur crée les comptes des employés (les superviseurs, les agents d’alerte,
les agents de services). Il peut consulter, modifier ou supprimer ces comptes.
18
• Consulter site : un utilisateur peut visiter le site afin de consulter les informations sur
les services proposés ainsi que sur quelques services déjà réalisés.
• Consultation des heures de travail : L’agent de service consulte les heures de travail
et clique sur retirer pour avoir son argent. L’agent d’alerte peut consulter le nombre
d’heures achetées par le client.
• Gestion des notifications : Tous les utilisateurs peuvent envoyer ou recevoir une
notification. L’agent d’alerte et le superviseur peuvent envoyer une notification à tous
les utilisateurs alors que le client et l’agent de service peuvent envoyer une
notification seulement au superviseur. Le superviseur doit envoyer une notification au
client ou à l’agent de service lors du refus d’un service en expliquant la cause de ce
refus. Si l’agent de service a refusé un service, il doit expliquer aussi à travers une
notification. De même pour le client, il doit expliquer son refus d’un service traité.
• Consultation des états des services : L’agent alerte consulte le progrès des services.
• Le contact : Pour toute information ou besoin d’aide, les utilisateurs peuvent envoyer
un message contenant une description de leurs besoins.
2.2.2. Besoins non fonctionnels
Pour réussir notre projet, nous devrons tenir compte aussi des besoins non fonctionnels qui
spécifient des propriétés du système, telles que les contraintes liées à l’environnement et
l’implémentation, les exigences en matière de performance, de facilité de maintenance,
d’extensibilité et de fiabilité.
Dans cette partie nous avons opté de se baser sur la norme ISO 9126 pour crée le modèle de
qualité du système.
Présentation de la norme ISO9126
La norme ISO 9126 [3] définit et décrit une série de caractéristiques qualités d’un produit
logiciel (caractéristiques internes et externes, caractéristiques à l’utilisation) qui peuvent être
utilisées pour spécifier les exigences fonctionnelles et non fonctionnelles des clients et des
utilisateurs.
19
Chaque caractéristique est détaillée en sous-caractéristique, et pour chacune d’elle, la norme

propose une série de mesures à mettre en place pour évaluer la conformité du produit
développé par rapport aux exigences formulées. La figure 2.2 présente le modèle générale de
la norme ISO 9126.
Figure 2.2: Le modèle générale de la norme ISO 9126
Modèle de qualité de système
Comme le montre la figure 2.3, les principaux besoins non fonctionnels de notre application
d’après la norme ISO_9126 se résument dans les points suivants :
20
Maintenabilité Fiabilité Fonctionnalité Portabilité Utilisabilité
Facilité
Modificabilité Récupération Sécurité Adaptabilité
d'exploitation
Stabilité Exactitude
Testabilité
Figure 2.3: Le modèle de qualité du système avec la norme ISO 9126
➢ Maintenabilité :
o Modificabilité : la facilité d’implémenter des modifications grâce à
l’architecture 3tiers qui assure une bonne structuration du projet.
o Stabilité : la capacité de l’application à maintenir la stabilité lors de la
modification et prévoir les erreurs qui bloque l’application.
o Testabilité : le projet doit être valide par rapport à la spécification.
➢ Fiabilité :
o Récupération : La possibilité de récupérer les données et les services défaites.
➢ Fonctionnalité :
o Sécurité : l’application doit protéger les informations et assuré la sécurité des
données de chaque utilisateur de façon que chaque utilisateur n’a l’accès
qu’aux données dont il possède le droit de consultation et/ou de modification.
o Exactitude : le résultat du projet doit être convenable et exacte aux besoins
spécifiés au niveau du cahier de charge.
➢ Portabilité :
o Adaptabilité : L'application doit être fonctionnelle sur n'importe quel type de
système d'exploitation et à n'importe quel environnement de travail.
21
➢ Utilisabilité :
o Facilité d’exploitation : le projet doit être ergonomique et bien organisé pour
assurer la facilité de la consultation et du contrôle.
2.3. Le diagramme de cas d’utilisation

Les diagrammes de cas d’utilisation décrivent ce qu’un système fait du point vue observateur
externe.
2.3.1. Identification des acteurs
Nous allons maintenant énumérer les acteurs susceptibles d’interagir avec le système. Tout
d’abord, nous commençons par définir ce qu’est un acteur.
Un acteur est une entité externe qui interagit avec le système, comme une personne humaine
ou un robot. Une même personne (ou robot) peut être plusieurs acteurs pour un système, c'est
pourquoi les acteurs doivent surtout être décrits par leur rôle, ce rôle décrit les besoins et les
capacités de l'acteur. Un acteur agit sur le système. L'activité du système a pour objectif de
satisfaire les besoins de l’acteur. Les acteurs sont représentés par un pictogramme humanoïde
(Stick man) sous-titré par le nom de l'acteur.
Nous allons maintenant identifier les différents acteurs et leurs interventions dans
l’application. Il existe 5 acteurs dans notre système :
• Administrateur
• Client
• Agent Service
• Agent Alerte
• Superviseur
La figure 2.4 illustre l’héritage des acteurs de notre plateforme.
22
utilisateur
client agent de service agent d'alerte superviseur administrateur
Figure 2.4: Héritage des acteurs
2.3.2 Diagramme de cas d’utilisation global
Le diagramme de cas d'utilisation global représente les scénarios effectués par les différents
acteurs qui interagissent avec le système. La figure 2.5 présente le diagramme global de notre
plateforme.
23
consulter les statistiques
contacter l'administrateur
utilisateur
<<include>>
gestion des services
gestion des profils <<include>>

<<include>> authentification
<<include>>
<<include>>
consulter liste des contact
administrateur
gestion domaine
gestion des comptes des employés
consulter les abonnements des clients <<include>>
consulter la liste des utilisateur <<include>>
agent d'alerte
gestion des notifications <<include>>
superviseur
agent de service
<<include>>
gestion abonnement
client
Figure2.5 : diagramme de cas d’utilisation global
2.3.3 Diagrammes de cas d’utilisation détaillés
Dans cette partie nous allons détailler les cas d’utilisation relatifs à chaque acteur.
❖ Diagramme de cas d’utilisation relatif à l’administrateur :
L’administrateur peut gérer les comptes des utilisateurs (consulter, modifier, supprimer, créer
les comptes des employés (agent d’alerte, superviseur, agent de service)), consulter les
24
abonnements, consulter la liste des contacts, consulter les statistiques, consulter les services et
gérer les domaines et les sous-domaines. La figure 2.6 présente le diagramme de cas
d’utilisation relatif au superviseur.
Créer un compte employé
Gestion des comptes des utilisateurs consulter un compte d'un utilisateur
Modifier un compte d'un utilisateur
Suprimer un compte d'un utilisateur
Ajouter un domaine
Gestion des domaines

Modifier un domaine
Administrateur
Supprimer un domaine
<<extend>> afficher un service

consulter la liste des services
<<extend>>
telecharger un service
consulter liste des abonnements
consulter liste des contacts
consulter les statistiques
Figure 2.6 : Diagramme de cas d’utilisation relatif à l’administrateur
25
❖ Diagramme de cas d’utilisation relatif à l’agent d’alerte :
L’agent d’alerte peut contrôler le déroulement des services (consulter liste de service puis
envoyer une notification), envoyer et consulter des notifications consulter les profiles des
utilisateurs ainsi que les abonnements des clients.
La figure 2.7 présente le diagramme de cas d’utilisation relatif à l’agent d’alerte.
<<extend>>
consulter la liste des services
Gestion des notifications consulter liste des notifications

Agent d'alerte
<<extend>>
Envoyer une notification à un utilisateur
consulter les abonnements des clients <<extend>>
<<extend>>
consulter les profiles des clients
consulter la liste des utilisateurs
<<extend>>
modifier
consulter le profile
Figure 2.7 : Diagramme de cas d’utilisation relatif à l’agent d’alerte
❖ Diagramme de cas d’utilisation relatif au superviseur:

Le superviseur peut gérer les services (vérifier les services en cas de refus, il faut créer une
notification contenant la cause), il peut aussi créer une notification a tous les utilisateurs et
consulter ses notifications).
La figure 2.8 présente le diagramme de cas d’utilisation relatif au superviseur.
26
<<include>>
refuser
consulter les nouveaux services
<<extend>>
accepter
<<extend>>
telecharger un fichier
<<extend>>
<<extend>>
consulter les services terminés
<<extend>>
consulter les services livrés
consulter les services en attente de confirmation du client
gérer les services
consulter les services non confirmés par le client
consulter les services en attente de confirmation par l'agent de service
consulter les services en cours de traitement

superviseur
<<extend>> modifier
consulter le profile
consulter mes notifications <<extend>>

gérer les notifications
créer une notification
Figure 2.8 : Diagramme de cas d’utilisation relatif au superviseur
❖ Diagramme de cas d’utilisation relatif à l’agent service:
L’agent de services peut gérer les services (vérifier les services en cas de refus, il faut créer
une notification contenant la cause), il peut aussi créer une notification au superviseur et
consulter ses notifications). Aussi, il peut consulter ses heures de travails et être pays pour
chaque heure.
La figure 2.9 présente le diagramme de cas d’utilisation relatif à l’agent de service.
27
modifier le progrés de travail
consulter les services en cours telecharger un fichier
<<extend>>
gérer les services
importer un fichier
accepter
agent service consulter la liste des nouveaux services
refuser
gestion des notification consulter mes notifications <<include>>
<<extend>>
créer une notification pour le superviseur
<<extend>>
payement
Consulter les heurs de travail
<<extend>>
modifier
Consulter le profile
Figure 2.9 : Diagramme de cas d’utilisation relatif à l’agent de service
❖ Diagramme de cas d’utilisation relatif au client:
Le client peut gérer les services (demander, consulter, accepter, refuser, modifier, supprimer
un service), il peut aussi créer une notification au superviseur et consulter ses notifications)
ainsi il peut consulter et acheter un abonnement.
La figure 2.10 présente le diagramme de cas d’utilisation relatif au client.
28
<<extend>>
consulter le nombre d'heures d'un abonnement acheter un abonnement
<<extend>>
ajouter des taches
<<extend>> importer un fichier

demander un service
télécharger un fichier
gérer ses services <<extend>>
client
consulter les services en cours
modifier
consulter la liste des services consulter les services en attente
supprimer
consulter les services términés

<<extend>>
refuser accepter
<<include>>
<<extend>>
consulter ses notifications
<<extend>>
consulter le profile modifier le profile
Figure 2.10 : Diagramme de cas d’utilisation relatif au client
2.4. Diagrammes de séquence système
Le diagramme de séquence système est la représentation graphique de l’interaction directe

entre l’acteur et le système selon un ordre chronologique dans la formulation Unified
Modeling Language. Pour notre modélisation, nous allons présenter les principaux
diagrammes par cas d’utilisation.
29
2. 4.1 Description textuelle et interaction système : Authentification
Le tableau 2.1 présente la description textuelle du cas d’utilisation « Authentification ».
Titre Authentification
Acteurs Administrateur, agent-alerte, agent-service,

client, superviseur.
objectif Permettre à l’utilisateur de s’authentifier afin de

pouvoir accéder aux rubriques dont il possède le
privilège.
Description des enchainements
Pré condition Post condition
L’utilisateur doit avoir une connexion L’utilisateur est connecté.

internet et un compte (login et mot de
passe).
Scénario nominal
1. L’utilisateur lance la Plateforme.
2. L’utilisateur saisit son identifiant et son mot de passe.
3. Le système vérifie les coordonnées saisies.
4. Le système examine le rôle de l’utilisateur.
5. L’utilisateur est dirigé vers la page du rôle choisi
Scénario alternatif
A1 : Les coordonnées saisies sont incorrectes
L'enchainement démarre après le point 3 du scénario nominal
4. Un message d'erreur est affiché sur l'écran
5. Le système va afficher en boucle la page d'authentification et revient au point 1 du
scénario nominal jusqu'à ce que l'utilisateur réussisse l'authentification.
Scénario d’exception
E1. Le champ Identifiant est vide :
Le système indique que le champ Identifiant est obligatoire.
30
Le système donne la possibilité à l'utilisateur de refaire la saisie.

E2. L’Identifiant et le mot de passe ne se correspondent pas :
Un message d'erreur s'affiche pour demander la vérification du mot de passe.
Le système annule la requête (toutes les opérations mémorisées par le système sont
défaites).
Tableau 2.1: Description textuelle du cas d'utilisation "Authentification"
Le schéma de la figure 2.11 correspond à la description textuelle cas d’utilisation

« Authentification ».
Authentification
utilisateur systeme
Lancer la plateforme
formulaire de connexion
remplir formulaire
vérifier les données
alt invalide
message d'erreur
valide
vérifier l'existance
alt n'existe pas
message d'erreur
existe
afficher le profile
Figure 2.11: Diagramme de séquence du cas d’utilisation « Authentification »
31
2.4.2 Description textuelle et interaction système : Acheter un

abonnement
Le tableau 2.2 présente la description textuelle de cas d’utilisation d’achat d’un abonnement.
Titre Acheter un abonnement

Acteurs Client
objectif Permettre au client d’acheter un abonnement

afin de profiter d’un nombre d’heure nécessaire
pour la réalisation de son service.
Le client doit avoir une connexion L’achat est effectué et ajouté dans la base de
internet et succès d’authentification. données.
Scénario nominal
1. Le client demande la page d’achat des abonnements.
2. Le système affiche la page d’achat des abonnements.
3. Le client remplit le formulaire d’achat.
4. Le client choisit le bouton acheter.
5. Le système vérifie la validité des champs remplis.
6. Le système affiche le nombre d’heures achetées.
A1 : Les champs saisies sont incorrectes.
6. Le système indique que les champs ne sont pas valides et affiche un message d'erreur.
7. Le système invite l'utilisateur à faire une autre tentative de saisie.
8. Le scénario nominal reprend au point 3.
E1. Les champs Obligatoires sont vides :
L'enchainement démarre après le point 5 du scénario nominal :
6. Le système indique que les champs sont obligatoires.
7. Le système donne la possibilité à l'utilisateur de refaire la saisie.
Tableau 2.2: Description textuelle du cas d'utilisation "Acheter un abonnement"
32
Le schéma de la figure 2.12 correspond à la description textuelle cas d’utilisation « Acheter

un abonnement ».
acheter un abonnement
client système
ref
authentification()
demande le formulaire d'achat d'un abonnement
formulaire d'achat
remplir formulaire
alt invalide
message d'erreur
valide
afficher le nouveau nombre d'heures
Figure 2.12: Diagramme de séquence du cas d’utilisation « Acheter un abonnement »
2.4.3 Description textuelle et interaction système : Demander un

service
Le tableau 2.3 présente la description textuelle de cas d’utilisation de demande d’un service.
Titre Demander un service
Acteurs Client
objectif Permettre au client de postuler un service afin

de recevoir une solution.
33
L’utilisateur doit avoir un abonnement Le service est bien envoyé au superviseur.

contient le nombre d’heure nécessaire
pour son service.
Scénario nominal
1. Le client demande la page de demande d’un service.
2. Le système affiche le formulaire de création d’un service.
3. Le client remplit le formulaire de création d’un service.
5. Le système affiche la page d’ajout d’une tâche et d’ajout d’un fichier.
6. Le client remplit les champs et choisit le bouton demander.
7. Le service est ajouté à la liste des services en attente.
A1 : Les champs saisis sont incorrectes.
5. Le système indique que les champs ne sont pas valides et affiche un message d'erreur.
6. Le système invite l'utilisateur à faire une autre tentative de saisie.
7. Le scénario nominal reprend au point 3.
A2 : Les champs Obligatoires sont vides.

L'enchainement démarre après le point 5 du scénario nominal.
E1. le nombre d’heure introduit pour le service est supérieur au nombre d’heure achetés.
L'enchainement démarre après le point 4 du scénario nominal :
5. Le système indique que le choix de nombre d’heure est invalide.
Tableau2.3: Description textuelle du cas d'utilisation "Demander un service"
34
Le schéma de la figure 2.13 correspond à la description textuelle cas d’utilisation « Demander

un service ».
Demander un service
client système
ref
authentification()
demande le formulaire de demande d’un service
formulaire de demande d'un service
remplir formulaire
alt invalide message d'erreur
valide
verifier nombre d'heures
alt invalide
message d'erreur
valide
afficher la page d'ajout d'une tache et d'un fichier
remplir lres champs
le service est ajouté à la liste des services en attente
Figure 2.13: Diagramme de séquence du cas d’utilisation « Demander un service »
35
2.4.4. Description textuelle et interaction système : Vérifier service
Le Tableau 2.4 présente la description textuelle de cas d’utilisation de Vérification d’un

service.
Titre Vérifier service
Acteurs Superviseur
objectif Permettre au superviseur de vérifier le nombre

d’heures nécessaire pour un service et la
description de service sont valides ou pas.
Le superviseur doit avoir une connexion Le service est bien accepté par le superviseur.
internet et succès d’authentification.
Scénario nominal
1. Le superviseur demande la page des nouveaux services.
2. Le système affiche la page des nouveaux services.
3. Le superviseur choisit le bouton afficher
4. Le système affiche le service détaillé.
5. Le superviseur vérifie le service.
6. Le superviseur choisit le bouton accepter.
7. Le système affiche la liste des agents services.
8. Le superviseur affecte le service à un agent service.
9. Le service est envoyé à l’agent service.
A1 : Le superviseur choisit le bouton refuser.
6. Le superviseur choisit le bouton refuser
7. Le système invite l'utilisateur à faire créer une notification.
Tableau 2.4: Description textuelle du cas d'utilisation "Vérifier un service"
36
Le schéma de la figure 2.14 correspond à la description textuelle cas d’utilisation « vérifier un

service».
Demander un service
superviseur système
ref
authentification()
demande la page des nouveaux servcices
page de nouveaux services
demande la page d'un service détaillé
page d'un service détaillé
vérifier le service
alt refuser formulaire de création d'une notification
remplir formulaire
notification envoyé
accepter
liste des agents de service
choisir un agent de service
le service est envoyé à l'agent de servcie
Figure 2.14: Diagramme de séquence du cas d’utilisation « Vérifier un service»
37
2.4.5. Description textuelle et interaction système : créer une

notification
Le Tableau 2.5 présente la description textuelle de cas d’utilisation de création d’une

notification.
Titre Créer une notification
Acteurs Client, superviseur, agent alerte, agent service.
objectif Permettre à l’utilisateur d’envoyer une

notification contenant une information.
L’utilisateur doit avoir un abonnement La notification est bien envoyée au destinataire.

contient le nombre d’heure nécessaire
pour son service.
Scénario nominal
1. L’utilisateur choisit la page de création d’une notification.
2. Le système affiche le formulaire de création d’une notification.
3. L’utilisateur remplit le formulaire de création d’une notification.
4. L’utilisateur choisit le bouton envoyer.
6. La notification est envoyée au destinataire.
A1 : Les champs Obligatoires sont vides.
L'enchainement démarre après le point 5 du scénario nominal.

Tableau 2.5: Description textuelle du cas d'utilisation "créer une notification"
Le schéma de la figure 2.15 correspond à la description textuelle cas d’utilisation « créer une
notification».
38
utilisateur système
ref
authentification()
demande le formulaire de création d'une notification
formulaire de création d'une notification
remplir le formulaire
vérification des données
alt invalide
message d'erreur
valide
notification envoyée
Figure 2.15: Diagramme de séquence du cas d’utilisation « Créer une notification»
2.5. Pilotage du projet avec SCRUM
Au cours du notre projet, à partir de la phase de spécification jusqu’à la mise en production,

nous avons réparti le travail en sprints et releases. Un sprint est une période d'un mois au
maximum, au bout de laquelle l'équipe délivre un incrément du produit. Un release est une
somme de sprints améliorant la visibilité sur le planning du projet.
Nous avons alors réparti les rôles de Scrum de la manière suivante :
Notre équipe est constituée par «Mariem Bousaid» et «Islem Ayari» dont chacun a une mêlée
quotidienne de mise au point chaque jour en effectuant le backlog du sprint et le tableau de
tâches pour signaler l’avancement du travail du chacun.
39
Tout au long du projet, chaque semaine l’un des membres de l’équipe joue le rôle d’un Scum
Master. C’est la personne qui doit assurer le bon déroulement des différents sprints du release
et qui doit impérativement maitriser Scrum.
Le Product Owner représente la personne qui porte la vision du produit à réaliser. Il s’agit
généralement d’un expert dans le domaine. Au cours du notre projet le Product Owner est Mr
«Chargui Tayeb» qu’il est notre encadrant de stage et il effectue le Backlog du produit. La
figure 2.16 illustre l’interface Scrumwise représentant l’équipa de travail.
Figure 2.16: Interface scrumwise représentant l’équipe de travail
2.5.1Backlog du produit :
Le backlog du projet est l’artefact le plus important de Scrum, c’est l’ensemble des
caractéristiques fonctionnelles ou techniques qui constituent le produit souhaité. Les
caractéristiques fonctionnelles sont appelées des histoires utilisateur (user story) et les
caractéristiques techniques sont appelées des histoires techniques (technical story).
L’importance de la story est définie par la priorité MOSCOW tel que :
M: Must, S: Should, C: Could, W: Won’t
Le Tableau 2.6 résume le Backlog du projet qui est considéré comme une définition des
besoins fonctionnels sous forme de « User Story ». Un utilisateur désigne un superviseur, un
agent d’alerte, un agent service et un client.
40
Feature En tan que Je souhaite Afin de Priorité Sprint

Administrateur Pouvoir Sécurisé l’accès à la M
m’authentifier plateforme.
Utilisateur Pouvoir Utiliser la Plateforme M
Inscription et m’authentifier
authentification
client Pouvoir D’avoir un compte M
m’inscrire personnel
Administrateur Gérer les Créer des comptes pour M

utilisateurs les employés,
Consulter, modifier,
supprimer les comptes Sprint1
des utilisateurs.
Utilisateur Gérer mon Consulter mon profile, C
profile Modifier mes
Gestion des
utilisateurs Informations.
Agent d’alerte Consulter la Contrôler les S
liste des utilisateurs
utilisateurs
Agent d’alerte Consulter les Connaitre les C
profiles des informations des
utilisateurs utilisateurs
Client Gérer mon Acheter un abonnement, M
abonnement Consulter le nombre
d’heures acheté
Administrateur Consulter la De connaitre les S
liste des nombres des heures
Abonnement achetés par les clients
Gestion des des clients
abonnements
Agent de Gérer mes Consulter le nombre M Sprint2
service heures de d’heure de travail,
travail retirer la somme
d’argent gagné pour
chaque heure.
Agent d’alerte Consulter la Connaitre le nombre S
liste des d’heures restant dans
abonnements l’abonnement.
des clients
Gestion des Administrateur Gérer les Créer un domaine, M
domaines Modifier un domaine
41
domaines Supprimer un domaine

Consulter la liste des
domaines
Administrateur Gérer les sous Créer un sous domaine, M
domaines Modifier un sous
domaine, Supprimer un
sous domaine,
Consulter la liste des
sous domaines.
Client Gérer mes Demander, consulter, M
services un service, Supprimer,
modifier un service qui
est refuser ou n’est pas
encore affecté à un
agent service, recevoir,
valider, télécharger un
service traité.
Superviseur Gérer les Consulter un service, M
services affecter un service à un
agent de service,
Gestion des vérifier les services.
services Agent d’alerte Consulter la Contrôlé le S
liste des déroulement de service.
services
Agent de Gérer mes Consulter les services M

service services demandés, donner le Sprint3
progrès de traitement
de service, importer le
service traité
Administrateur Consulter la Contrôlé le S
liste des déroulement de service.
services
Client Gérer mes Consulter mes S
notifications notifications, créer une
notification pour
l’agent de service.
Superviseur Gérer les Consulter les S
notifications notifications, créer des
notifications pour tous
Gestion des les utilisateurs
notifications Agent de Gérer mes Consulter mes S
service notifications notifications, créer une
notification pour
l’agent de service.
Agent d’alerte Gérer les Consulter les S
notifications notifications, créer des
notifications pour tous
les utilisateurs
Visiteur Contacter Informer de mon C
l’administrateur besoin
Contact et Sprint4
Visiteur Consulter les Connaitre le nombre W
statistique statistiques du des utilisateurs et le
Plateforme nombre de domaine et
42
services traité par le

site.
Administrateur Consulter les Connaitre le nombre C
statistiques du des utilisateurs et le
Plateforme nombre de domaine et
services traité par le
site.
Administrateur Consulter les Répondre au besoin de C

contacts des l’utilisateur
visiteurs
Tableau 2.6 : Backlog de produit
2.5.2 La planification des sprints et releases
La réunion de planification des sprints est l’événement le plus important dans Scrum. Le but
de cette réunion est de préparer le planning de travail et d’identifier le backlog des sprints.
L’un des produits de cette réunion est le choix de la durée des sprints qui se diffère selon la
complexité du projet et la taille de l’équipe. Puisqu’à la fin de chaque release, le client doit
avoir un produit exploitable et exécutable pour tester l’application et accélérer le processus de
travail, nous avons choisi de développer deux releases. La figure 2.17 présente le planning du
travail.
Figure 2.17 : Plan de release
2.6. Conclusion
Dans ce chapitre, nous avons représenté la méthodologie adoptée et présenté les besoins de
l’utilisateur. Ensuite nous avons fait une description détaillée des différents cas d’utilisation
43
de notre produit ainsi que les différents besoins non fonctionnels que nous avons sélectionnés
d’après la norme ISO 9126. Dans le chapitre suivant, nous passerons à la phase de conception
permettant d'aborder l'aspect architecturale, technique et graphique du système.
44
Chapitre 3 : Conception de la solution
45
Conception de la solution
fin de décrire les différents besoins de notre projet, nous allons passer à l’étape de
A conception de notre solution. Dans ce chapitre, nous allons tout d’abord

commencer par présenter les architectures sur lesquelles notre système est basé.
Par la suite, nous décrirons la conception détaillés de notre système. Pour cela, nous allons
présenter les diagrammes de classe pour décrire la vue statique ainsi les diagrammes
d’activités qui ont recours à la description de la vue dynamique.
3.1. Conception technique globale
Les choix architecturaux d'une application sont décisifs dès qu'ils interviennent sur les
performances, le temps de développement et bien sûr le coût. L’architecture de notre
application est une architecture 3-tiers qui est composée de trois niveaux :
L'architecture Modèle/Vue/Contrôleur (MVC) est une façon d'organiser une interface

graphique d'un programme. Elle consiste à distinguer trois entités distinctes qui sont, le
modèle, la vue et le contrôleur ayant chacun un rôle précis dans l'interface. L'organisation
globale d'une interface graphique est souvent délicate. Bien que la façon MVC d'organiser une
interface ne soit pas la solution miracle, elle fournit souvent une première approche qui peut
ensuite être adaptée. Elle offre aussi un cadre pour structurer une application. Dans
l'architecture MVC, les rôles des trois entités sont les suivants :
• Model : Représente la partie métier de l’application, Il correspond aux données stockées

généralement dans une base de données. Dans un langage orientée objet ces données sont
exploitées sous forme de classes. Le modèle peut aussi agir sur la vue en mettant à jour ses
données.
• Contrôleur : Reçoit les actions de l’utilisateur et gère la répartition des traitements entre la
vue et le modèle. Il sert de base à récupérer les informations, de les traiter en fonction des
paramètres demandés par la vue (par l’utilisateur), puis de renvoyer à la vue les données afin
d’être affichées. C’est donc l’élément qui va utiliser les données pour les envoyer à la vue.
• Vue : Est la partie graphique, dans laquelle seul l’affichage est géré. Elle ne contenant que
les informations liées à l’affichage, la vue se contente d’afficher le contenu qu’elle reçoit sans
avoir connaissance des données. En bref, c’est l’interface homme machine de l’application.
[4]
46
La figure 3. 1 présente le modèle MVC.
Figure 3.1 : Modèle MVC
3.2 Conception technique détaillée
Le but de cette section est de détailler la conception de notre projet en commençant par la
représentation statique du système et par la suite nous détaillerons quelques scénarios en
utilisant une représentation dynamique de nos modules.
3.2.1 Représentation de la vue statique
Cette partie sera consacrée à la description détaillée des classes, les règles de gestion et
ensuite les diagrammes de classes pour détailler les différents rôles et associations entre les
modules.
Description détaillée des classes
Une classe représente plusieurs attributs ayant des différentes natures. Les classes de notre
application sont décrites dans le tableau 3.1.
47
Classe Description
La classe utilisateur est identifiée par sa clé
utilisateur primaire id et elle a pour attributs :
- id : int Nom, prénom, email, tel, date de naissance,
- nom : String
- prénom : String profession, adresse, image.
- email : String
- tel : int
- date de naissance : Date
- profession : String
- adresse : String
- image : String
+ afficher ()
+ modifier ()
...
La classe administrateur est identifiée par sa

administrateur clé primaire id_ad.
- id_ad : int
La classe superviseur est identifiée par sa clé

superviseur primaire id-sup.
- id_sup : int
+ afficher ()
+ supprimer ()
+ modifier ()
+ ajouter ()
La classe agent_alerte est identifiée par sa clé

agent_alerte primaire id_aal.
- id_aal : int
+ afficher ()
+ modifier ()
+ supprimer ()
+ ajouter ()
agent_service La classe agent_service est identifiée par sa

- id_aser : int clé primaire id_aser.
+ afficher ()
+ ajouter ()
+ supprimer ()
+ modifier ()
La classe client est identifiée par sa clé

client primaire id_cl.
- id_cl : int
+ afficher ()
+ modifier ()
+ supprimer ()
abonnement La classe abonnement est identifiée par sa clé

- id_ab : int primaire id_ab et elle a pour attributs :
- nb_heure : int
+ acheter ()
Nb_heure.
+ afficher ()
...
48
La classe payement est identifiée par sa clé

payement primaire id_p et elle a pour attributs :
- id_p : int Nb_heure.
- nb_heure : int
+ acheter ()
+ afficher ()
...
La classe service est identifiée par sa clé

service primaire id_service et elle a pour attributs :
- id-service : int Nom, heures, description, état, progrès.
- nom : String
- heures : int
- description : String
- etat : String
- progrés : int
+ afficher ()
+ modifier ()
+ supprimer ()
+ ajouter ()
La classe domaine est identifiée par sa clé

domaine primaire id_doamine et elle a pour attributs :
- id_domaine : int Libelle.
- libelle : String
+ afficher ()
+ modifier ()
+ supprimer ()
+ ajouter ()
...
La classe sous_domaine est identifiée par sa

sous_domaine clé primaire id_sousdom et elle a pour
- id_sousdom : int attributs :
- libelle : String
+ afficher ()
Libelle.
+ modifier ()
+ supprimer ()
+ ajouter ()
La classe tache est identifiée par sa clé

tache primaire id_tache et elle a pour attributs :
- id_tache : int Tache.
- tache : String
+ afficher ()
+ modifier ()
+ supprimer ()
+ ajouter ()
...
La classe fichier est identifiée par sa clé

fichier primaire id_fichier et elle a pour attributs :
- id_fichier : int Lien.
- lien : String
+ importer ()
+ telecharger ()
...
49
notification La classe fichier est identifiée par sa clé

- id_notification : int primaire id_notification et elle a pour
- sujet : String
- message : String attributs :
+ ajouter () Sujet, message.
+ afficher ()
...
La classe contact est identifié par son clé

contact primaire id_contact et elle a pour attributs :
- id_contact : int Nom, email, sujet, message.
- nom : String
- email : String
- sujet : String
- message : String
+ ajouter ()
+ afficher ()
...
Tableau 3.1 : Description des classes
Règles de gestion
Le diagramme de classe étudié est basé sur les règles de gestion suivantes :
R1 : Un administrateur hérite les fonctionnalités d’un utilisateur ;
R2 : Un agent de service hérite les fonctionnalités d’un utilisateur ;
R3 : Un agent d’alerte hérite les fonctionnalités d’un utilisateur ;
R4 : Un client hérite les fonctionnalités d’un utilisateur ;
R5 : Un superviseur hérite les fonctionnalités d’un utilisateur ;
R6 : Un client peut demander 0 ou plusieurs service suite à l’achat d’un abonnement ;
R7 : Un service peut être demandé par un seul client ;
R8 : Un agent de service peut envoyer 0 ou plusieurs service pour bénificier d’un payement ;
R9 : Un service peut être envoyé un seul agent de service ;
R10 : Un utilisateur peut consulter ou plusieurs service ;
R11 : Un service peut être consulté par 0 ou plusieurs utilisateurs ;
R12 : Un superviseur peut vérifier un 0 ou plusieurs service ;
R13 : Un service peut être vérifié par un ou plusieurs superviseur ;
R14 : Un service possède un seul domaine ;
R15 : Un domaine est possédé par 0 ou plusieurs service ;
R16 : Un domaine est composé par 0 ou plusieurs sous domaine ;

50
R17 : Un sous domaine correspond à un seule domaine ;
R18 : Un utilisateur possède 0 ou plusieurs notification ;
R19 : Une notification est possédé par un seul utilisateur ;
R20 : Un utilisateur peut envoyer 0 ou plusieurs notification ;
R21 : Une notification peut être envoyé par un seul utilisateur ;
R22 : Un contact peut être envoyé par un seul utilisateur ;
R23 : Un utilisateur peut envoyer 0 ou plusieurs contact ;
R24 : Un administrateur peut recevoir 0 ou plusieurs contact ;
R25 : Un contact peut être reçu par 1 ou plusieurs administrateur ;
R26 : Un fichier correspond à un seul service ;
R27 : Un service possède 0 ou plusieurs fichier ;
R28 : Un service est composée par 0 ou plusieurs tâche ;
R29 : Une tâche correspond à un seul service ;
Diagramme de classe
Le diagramme de classe est considéré comme le plus important de la modélisation orientée

objet, c'est le seul diagramme obligatoire lors d'une telle modélisation. Il permet de définir la
structure interne du système contrairement au diagramme de cas d'utilisation qui montre le
système de point de vue acteur. La figure 3.2 illustre le diagramme de classe de notre
plateforme.
51
sous_domaine
tâche domaine
- id_sousdom : int
- id_tache : int - id_domaine : int
- libelle : String
- tache : String - libelle : String
1..1 + afficher ()
+ afficher () + afficher () 0..* + modifier ()
+ modifier () + modifier ()
+ supprimer ()
+ supprimer () + supprimer ()
+ ajouter ()
+ ajouter () + ajouter () abonnement
... ...
- id_ab : int
0..* 1..1 - nb_heure : int
+ acheter ()
+ afficher ()
...
1..1 0..*
1..1
fichier service
0..* 1..1
- id_fichier : int - id-service : int
- lien : String - nom : String
- heures : int
- description : String
- etat : String
0..* - progrés : int 0..* payement
+ afficher () - id_p : int
+ modifier () - nb_heure : int
+ supprimer () + acheter ()
1..1 + ajouter ()
+ afficher ()
...
1..* 0..* 0..* 1..1
client
administrateur superviseur agent_alerte agent_service - id_cl : int
- id_ad : int - id_sup : int - id_aal : int - id_aser : int + afficher ()
+ afficher () + afficher () + afficher () + modifier ()
+ supprimer () + modifier () + ajouter () + supprimer ()
1..* + modifier () + supprimer () + supprimer ()
+ ajouter () + ajouter () + modifier ()
0..*
utilisateur
- id : int
- nom : String 1..1
0..* 0..* 1..1 - prénom : String
- email : String
0..*
- tel : int
contact - date de naissance : Date
- id_contact : int - profession : String notification
- nom : String - adresse : String - id_notification : int
- email : String - image : String - sujet : String
- sujet : String + afficher () - message : String
- message : String
+ modifier () + ajouter ()
+ ajouter () ... + afficher ()
+ afficher () ...
...
Figure 3.2 : Diagramme de classe
3.2.2 Représentation de la vue dynamique
Dans la partie précédente, nous avons exprimé les différentes composantes de notre
application en se basant sur la description des objets organisés dans un diagramme de classes.
Dans cette partie nous allons présenter l’aspect dynamique de notre application à travers la
description de quelques scénarios. Nous allons employer pour cette fin quelques diagrammes
52
d’activités. Le diagramme d'activité est un moyen graphique qui permet de donner une vision
globale de l'ensemble des scénarios possibles. Il aide à voir un peu plus clair le déroulement
du processus du progiciel.
On représente dans la figure 3.3 la modélisation du processus de l’inscription d’un client.
client
inscription
authentification
remplir formulaire d'achat d'un abonnement
[champs non valides]
valider
Figure 3.3: Diagramme d’activité de l’inscription d’un client
On représente dans la figure 3.4 la modélisation du processus de demande d’un service
53
client superviseur agent de service
authentification
remplir formulaire de demande d'un service
[champs non valides]
[champs valides] consulter les nouveaux services

valider
[accépter]
vérifier
[refuser]
affecter à un agent de service consulter les demande de service

consulter mes notifications
vérification
[refuser]
[accépter]
consulter notifications créer notification
consulter les services non confirmer
Figure 3.4: Diagramme d’activité de demande d’un service
3.3. Conception graphique

La conception graphique consiste à présenter les différentes maquettes de notre application, le
schéma de navigation de chaque acteur et la charte graphique que nous avons utilisé.
3.3.1 Maquette
Une maquette est une représentation partielle d'un objet. Elle permet la création graphique
d'une interface. Nous avons établi les maquettes de chaque interface avant de se lancer dans le
54
développement. On en représente ainsi quelques-unes qui ont été dessinées depuis le site
mybalsamiq.
Les maquettes illustrées dans les figures ci-dessous présentent l’interface d’un compte client,
la page d’achat d’un abonnement, La page de demande d’un service et la page de la liste des
services.
Figure 3.5 : l’interface d’un compte client
Figure 3.6 : la page d’achat d’un abonnement

55
Figure 3.7 : La page de demande d’un service
Figure 3.8: La page de la liste des services
56
3.3.2 Schéma de navigation
Notre application comporte cinq sessions : une session pour l‘administrateur, une autre pour
le client, une 3éme pour l’agent de service, une 4éme pour superviseur et une dernière pour le
l’agent d’alerte. Nous avons choisi pour notre système une navigation d’une structure
pyramidale qui offre un accès par niveaux hiérarchique bidirectionnel et qui est riche en
interactivité.
La figure 3.9 représente le schéma de navigation du système dont l’utilisateur est

l’administrateur.
Figure 3.9: schéma de navigation de la session administrateur
La figure 3.10 représente le schéma de navigation du système dont l’utilisateur est le client.
57
Figure 3.10 : schéma de navigation de la session client
La figure 3.11 représente le schéma de navigation du système dont l’utilisateur est le

superviseur.
Figure 3.11: schéma de navigation de la session superviseur
La figure 3.12 représente le schéma de navigation du système dont l’utilisateur est l’agent
d’alerte.
Figure 3.12 : schéma de navigation de la session agent d’alerte
58
La figure 3.13 représente le schéma de navigation du système dont l’utilisateur est l’agent de
service.
Figure 3.13: schéma de navigation : Schéma de navigation de la session agent de service
3.3.3 Charte graphique
La charte graphique permet de définir la position et l’aspect des différents éléments

constituant les principales pages d’un site avant sa mise en production. Le but est de valider
les principes de navigation entre les pages, l’organisation des différents modules pour
l’ergonomie du site et l’aspect graphique des produits web.
Couleur : Pour assurer la lisibilité et la clarté de l’information, nous allons utiliser cette
palette de couleurs
#66d27 #202021 #73879c #bab8b8 #2a3f54 #d9534f
Forme: Les principales formes de la charte graphique de notre application sont les rectangles.
Police de caractère: Open Sans, Arial, sans-serif.
59
3.4. Description des sprints
Dans le cadre méthodologique SCRUM, le projet est découpé en cycles de développement

appelés Sprint. Chaque sprint est composé de plusieurs scénarios fonctionnels.
Echelle de mesure :
Un jour = 8 heures.
Une semaine = 5 jours.
Un mois = 4 semaines.
3.4.1 Sprint 1 : « inscription, authentification et gestion des utilisateurs »
Le sprint est le cœur de Scrum. Il s'agit d'un bloc de temps durant lequel un incrément du
produit sera réalisé. Ce sprint est alors découpé en tâches réalisables sur un temps raisonnable
pour voir l'évolution du travail.
Avant de se lancer dans un sprint, l'équipe Scrum doit définir le but de ce dernier. Suite à une
conversation entre le Product Owner et l'équipe Scrum nous avons décidé le but suivant pour
le premier sprint achever la partie inscription, authentification et gestion des utilisateurs.
Le tableau 3.2 résume le backlog du premier sprint de notre plateforme
Elément de backlog Les Taches Durée

Inscription de client. 30h
Inscription
Authentifications des 30h

utilisateurs.
Authentification
Authentification de 20h
l’administrateur.
Consultation de profile (front 16h
end).
Consultation des profiles des 8h
utilisateurs par l’agent
d’alerte.
Modification de profile (front 8h
Gestion des utilisateurs end).
Consultation de la liste des 8h
utilisateurs par l’agent
d’alerte.
Création des comptes des 16h
employés (back end).
60
Consultation des comptes des 8h

utilisateurs (back end).
Modifier les comptes des 8h
utilisateurs (back end)
Supprimer les comptes des 8h
utilisateurs (back end)
Tableau 3.2: Backlog du sprint1
La figure 3.14 montre l’interface scrumwise du sprint1
Figure 3.14 : interface scrumwise du sprint1
3.4.2 Sprint 2 : « Gestion des abonnements et gestion des domaines »
Suite à une réunion avec le Product Owner nous avons décidé concernant le deuxième sprint
d'achever la partie « gestion des abonnements et gestion des domaines »
Le tableau 3.3 résume le backlog du sprint 2 de notre application
Elément de Backlog Les Taches Durée

Achat d’un 16h
Gestion des abonnements abonnement par le
client
61
Consultation des 4h
abonnements des
clients par l’agent
d’alerte
Virement pour le 16h
nombre d’heure de
travail par l’agent de
service.
Consultation des 4h
abonnements des
clients (back end).
Création d’un domaine (back 5h
end).
Modification d’un domaine 5h
(back end).
Suppression d’un domaine 5h
(back end).
domaines (back end).
Gestion des domaines
Création d’un sous domaine 5h
(back end).
Modification d’un sous 5h
domaine (back end).
Suppression d’un sous 5h
domaine (back end).
sous domaines (back end).
62
3.4.3 Sprint 3 : « Gestion des services et gestion des abonnements »
Suite à une réunion avec le Product Owner nous avons décidé concernant le troisième sprint
d'achever la partie « Gestion des abonnements et domaines». Le tableau 3.4 résume le backlog
du sprint 3 de notre application :
Elément de Backlog Les Taches Durée

Créer un service. 16h
Modifier un service. 8h
Supprimer un service 4h
Consulter la liste des 24h
services (front end).
Afficher un service. 8h
Ajouter des taches à 12h
un service.
Afficher liste des 8h
Gestion des services
taches.
Supprimer une tache. 4h
taches (back end).
Affecter un service à 16h
un agent de service.
Télécharger un 8h
fichier.
Importer un fichier. 8h
Envoyer une notification par 24h
l’utilisateur.
Envoyer des notifications 24h
d’information sur l’état des
Gestion des notifications services par le système.
notifications
Afficher une notification 16h
63
3.4.4 Sprint 4 : « Contact et statistiques »
Suite à une conversation entre le Product Owner et l'équipe Scrum nous avons décidé le but
suivant pour le quatrième sprint « contact et statistique»
Le tableau 3.5 résume le backlog du sprint 4 de notre application :
Elément de backlog Les Taches Durée

Contacter 15h
l’administrateur.
contact
contacts.
Statistique de la plateforme : 15h
back end
Statistiques
Statistique de la plateforme : 5h
front end
64
3.5. Conclusion :
Dans ce chapitre, nous avons répondu à toutes les questions concernant la manière de
réalisation du système à développer. Nous avons commencé par une conception technique de
notre système. Par la suite nous avons détaillé la conception à travers quelques diagrammes
d’activité. Et nous avons présenté la conception graphique pour arriver enfin à la description
des sprints à travers les backlogs. Dans le prochain chapitre, nous allons présenter
l’environnement de développement matériel et logiciel ainsi que la description et l’évaluation
de la qualité travail réalisé.
65
Réalisation et tests
Chapitre 4 : Réalisation et tests
66
L
a phase de réalisation est l’étape la plus importante dans le cycle de vie de notre
application puisqu’elle représente le résultat des étapes précédentes. Au cours de ce
chapitre, nous allons décrire l'environnement de travail logiciel et matériel
permettant la réalisation de notre application. Par la suite, nous présenterons le travail réalisé
et les résultats obtenus.
4.1. Environnement de travail
Au cours de cette phase nous allons présenter l'environnement matériel et logiciel utilisés
pour le développement de notre application.
4.1.1. Environnement matériel
Afin de réaliser notre application, nous avons travaillé sur deux ordinateurs personnels dont la
configuration est la suivante :
Première machine :
• Fabricant : HP
• Processeur : Intel® Core ™ i5-5200U CPU @2.20 GHz.
• Mémoire installée (RAM) : 4,00 Go.
• Type de système : Système d’exploitation 64 bits.
Deuxième machine :
• Fabricant : ASUS
• Processeur : Intel® Core™ i7-7500U, up @ 3.50GHz.
• Mémoire installée (RAM) : 8,00 Go.
• Type de système : Système d’exploitation 64 bits
4.1.2. Environnement logiciel

Tout au long de la phase de développement, nous avons utilisé l’environnement logiciel
suivant :
Système d’exploitation : Windows 10.
Outils de développement : Sublime text 3.
67
Serveur de développement : MySQL 10.1.13 : utilisé pour la gestion de la base des données.
Outils de conception : Power AMC : est un logiciel de conception créé par la société SAP,
qui permet de modéliser les traitements informatiques et leurs bases de données associées.
Outils graphiques : Adobe Photoshop CC : Pour les retouches d’images.
Gestion de projet : Scrumwise : application web utilisée pour la tenue du tableau de tâches
de Scrum et pour l’échange de fichiers entre nous.
Choix technique
Dans cette partie, nous allons justifier les choix techniques du langage de programmation, de
la plateforme de développement et des Framework utilisés.
Avantage du modèle d’architecture 3-tiers
La figure 4.1 illustre le modèle d’architecture 3-tiers.
Figure 4.1 : Modèle d’architecture 3-tiers
Le marché des logiciels libres professionnels continue de se développer à un rythme soutenu.

Après avoir investi initialement les couches basses du système d'information (middleware),
les solutions Open Source commencent maintenant à concurrencer sérieusement les produits
propriétaires dans toute une gamme d'applications d'entreprise, et jusqu'aux logiciels grand
public. Le modèle d'architecture 3-tiers a pour objectif de répondre aux préoccupations
suivantes :
68
• Allégement du poste de travail client (notamment vis-à-vis des architectures

classiques client-serveur de données typiques des applications dans un contexte
Oracle/Unix).
• Prise en compte de l'hétérogénéité des plates-formes (serveurs, clients, langages,
etc.).
• Introduction de clients dits légers (plus liée aux technologies Intranet/HTML qu'au
3-tiers proprement dit).
• Amélioration de la sécurité des données, en supprimant le lien entre le client et les
données. Le serveur a pour tâche, en plus des traitements purement métiers, de
vérifier l'intégrité et la validité des données avant de les envoyer dans la couche de
données.
• Rupture du lien de propriété exclusive entre application et données. Dans ce
modèle, la base de données peut être plus facilement normalisée et intégrée à un
entrepôt de données. Et enfin, meilleure répartition de la charge entre différents
serveurs d'application. C'est pour cette raison, qu’on s'est orienté vers les
applications 3iers. [5]
Avantage du modèle d’architecture MVC :
Le motif MVC a été créé dans le but de mettre en œuvre des interfaces utilisateur. Certains
détails sont alignés avec le langage Smalltalk, mais les grandes lignes peuvent s'appliquer à
n'importe quel environnement.
L’approche MVC apporte de réels avantages:
• Une conception claire et efficace grâce à la séparation des données de la vue et du

contrôleur.
• Un gain de temps de maintenance et d’évolution du site.
• Une plus grande souplesse pour organiser le développement du site entre différents
développeurs (indépendance des données, de l’affichage (webdesign) et des actions).
[6]
69
Choix du standard de développement
Les raisons qui nous ont amené à adopter Laravel 8comme technologie sont :
• La facilité de maintenance, en suivant les principes de développement de Laravel,

on construit de petits fichiers avec de petites méthodes.
• La constitution par un système de routage perfectionné (RESTFul et ressources),
un créateur de requêtes SQL et un ORM performants, un moteur de Template
efficace, un système d'authentification pour les connexions, un système de
validation, un système de pagination, un système de migration pour les bases de
données, un système d'envoi d'emails…
• Sa documentation est complète, précise et de plus en plus de tutoriels et exemples
apparaissent sur la toile.
En bref Laravel [7] est un Framework qui fait gagner du temps et donne l'assurance de
disposer de composants bien codés et fiables. Il est novateur, complet, qui utilise les
possibilités les plus récentes de PHP et qui est impeccablement codé et organisé.
Choix de la technologie
Le choix des outils dans le développement de notre plateforme est basé sur l’avancement des
nouvelles technologies dans le domaine de développement web.
• SGBD « Microsoft SQL Server 2005 »
Microsoft SQL server 2005 est un système de gestion de base de données relationnelle
considérée comme solution complète de base de données pour le développement des
applications web. Nous avons choisi Microsoft SQL server 2005 pour ses avantages. Cette
solution est entièrement conçue pour le web. Ensuite, Microsoft SQL server 2005, d’après le
site officiel de Microsoft, est un outil de base de données pour les applications web le plus
performant actuellement. Enfin, c’est pour ces raisons que nous avons choisi Microsoft SQL
Server 2005.
8
www.laravel.com
70
• Sublime Texte 3
Sublime Text [8] est un éditeur de texte générique codé en C++ et Python, disponible sur
Windows, Mac et Linux. Le logiciel a été conçu tout d'abord comme une extension pour
Vim9, riche en fonctionnalités.
Depuis la version 2.0, sortie le 26 juin 2012, l'éditeur prend en charge 44 langages de
programmation majeurs, tandis que des plugins sont souvent disponibles pour les langages
plus rares.
Notre site web a été développé à l’aide de l’outil sublime text pour lequel nous avons opté car
il est de plus en plus utilisé dans l’industrie. En effet, cet outil de programmation présente un
large avantage car les programmes peuvent être exécutés sur différente systèmes
d’exploitation et architectures matérielles. La liste ci-dessous vous présente quelques
avantages de sublime text.
• La navigation/recherche au travers d’un ensemble de fichiers (ex : trouver un morceau

de code).
• Sélection multiple (ex : faire plusieurs modifications en une fois).
• Mode d’affichage multiple.
• Une colonne à droite permettant de se repérer sur la page.
• Choix et création d’une multitude de raccourcis.
• Un nombre très important de plugins et une belle sélection de thèmes.
• Une API bien documentée pour les développeurs de plugins.
Langages à utiliser
• HTML5 CSS3 :
HTML5 désigne la dernière version du langage de développement web HTML. Il définit deux
syntaxes de DOM : HTML5 et XHTML5. Cette version apporte de nouvelles possibilités en
termes de création d’« applications Web riches » bénéficiant de l'intégration d'éléments
multimédias et d'interactivité Il est généralement appris en parallèle du CSS et plus
précisément dans notre cas avec le CSS3, ce dernier permet en effet d’animer des éléments
HTML tout en effectuant des rotations, des transitions ou des changements.
9
Vim : c’est un logiciel permettant la manipulation de fichiers texte.
71
• JavaScript :
C’est un langage de programmation de scripts principalement utilisé dans les pages web
interactives. Ce langage permet une interaction avec l'utilisateur en fonction de ses actions.
• PHP :
Est un langage de programmation libre, principalement utilisé pour produire des pages web
dynamiques via un serveur, mais pouvant également fonctionner comme n'importe
quel langage interprété de façon locale. PHP est un langage impératif orienté objet.
4.1.3 Diagramme de déploiement
Le diagramme le plus approprié pour spécifier le contexte technique du système c'est le

diagramme de déploiement qui est représenté par la figure 4.2.
application
modèle
controlleur
vue
http
Base de données Client
Couche Donnée Couche Présentation
Figure 4.2 : Diagramme de déploiement
Ce diagramme montre la disposition physique des matériels qui composent le système et la

répartition des composants sur ces matériels. Les ressources matérielles sont représentées sous
forme de nœuds qui sont connectés entre eux, à l'aide d'un support de communication.
72
4.2. Description des interfaces graphiques de l’application

Dans cette partie nous allons présenter les différentes interfaces de notre plateforme.
4.2.1. Interfaces liées à un visiteur

Ce sont les interfaces que n’importe quel visiteur peut consulter.
La première interface vue au démarrage du Plateforme est représentée dans la figure 4.4. A
travers cette page l’utilisateur peut choisir se connecter ou bien s’inscrire en tant que client.
La figure 4.3 représente l’interface de contact qui permet à un utilisateur de contacter

l’administrateur s’il a un besoin spécifique.
Figure 4.3 : Interface de contact
73
Figure 4.4 : Interface d’accueil
74
A travers la page d’inscription l’utilisateur peut créer un compte en tant que client pour qu’il
puisse profiter de nos services. La figure 4.5 représente l’interface d’inscription.
Figure 4.5 : Interface d’inscription
La figure 4.6 illustre l’interface d’authentification. Le rôle de cette interface est de limiter
l’accès aux utilisateurs. L’authentification concerne 5 utilisateurs : Administrateur, agent
d’alerte, agent de service, superviseur et client.
75
Figure 4.6 : Interface d’authentification
4.2.2. Interfaces liées à un client
Ce sont les interfaces que seul le client peut y accéder.
A travers L’interface d’accueil de son compte représenté dans la figure 4.7, un client peut
s’informer sur ses fonctionnalités.
76
Figure 4.7 : Interface d’accueil d’un compte client
La figure 4.8 représente la page d’achat d’un abonnement. Elle est la première étape qu’un
client doit la réalisée pour qu’il puisse demander son service.
Figure 4.8 : Interface d’achat d’un abonnement
77
La figure 4.9 représente l’interface de demande d’un service. Suite à l’achat d’un abonnement
le client peut demander un service.
Figure 4.9 : Interface de demande d’un service
La page de la figure 4.10 représente l’interface de la liste des notifications. A travers cette
page le client peut consulter ainsi que créer des notifications pour le superviseur.
Figure 4.10 : Interface de la liste des notifications
78
4.2.3. Interfaces liées à un superviseur
Ce sont les interfaces que seul le superviseur peut y accéder.
Puisque le superviseur est le seul responsable à la vérification des services, nous avons
développés des interfaces qui lui permettent de gérer les services. La figure 4.11 représente
l’interface de la liste des services.
Figure 4.11 : Interface de la liste des services
Si le superviseur choisit le bouton afficher d’un nouveau service en attente alors une page de
vérification de service s’affiche. Cette interface permet au superviseur de consulter les détails
de services, les taches et les fichiers envoyés avec le service puis il doit choisir accepter ou
refuser le service. La figure 4.12 montre l’interface de consultation d’un nouveau service.
79
Figure 4.12 : Interface de consultation d’un nouveau service
Si le superviseur choisit le bouton accepter le service va être envoyé à l’agent de service sinon
s’il choisit le bouton refuser, il va être redirigé vers une interface de création des notifications
pour exprimer la cause de refus. La figure 4.13 représente l’interface de création d’une
notification.
Figure 4.13 : Interface de création d’une notification
80
4.2.4. Interfaces liées à un agent de service
Ce sont les interfaces que seul l’agent de service peut y accéder.
Suite à l’acceptation de service par le superviseur l’agent de service consulte aussi la liste des
nouveaux services, il peut accepter ou refuser .En cas d’accepte, il va être dirigé vers la page
de traitement de service .Dans cette page l’agent de service modifie le progrès de service à
chaque avancement de travail pour donner un renseignement sur l’état de service. Lorsque le
progrès atteint 100% l’agent de service peut importer le service et l’envoyer. La figure 4.14
illustre l’interface de traitement d’un service.
Figure 4.14 : Interface de traitement d’un service
Si le client accepte le service un nombre d’heure va être ajouté aux heures de travails du
l’agent de service pour qu’il puisse être payé. La figure 4.15 représente l’interface de
payement.
81
Figure 4.15 : Interface de payement
Chaque utilisateur peut consulter ainsi modifier son profile. La figure 4.16 corresponde à
l’interface de modification de profile de l’agent de service.
Figure 4.16 : Interface de modification de profile d’un agent de service
82
4.2.5. Interfaces liées à un agent d’alerte
Ce sont les interfaces que seul l’agent d’alerte peut y accéder.
L’agent d’alerte peut consulter la liste des abonnements .Si un client dispose de 0 nombre
d’heure l’agent d’alerte peut crée une notification pour demander a cet client d’acheter un
abonnement. La figure 4.17 illustre l’interface de la liste des abonnements.
Figure 4.17 : Interface de la liste des abonnements
A travers l’interface de consultation des services l’agent d’alerte peut contrôler le

déroulement des services. Cette interface est représentée dan la figure 4.18.
Figure 4.18 : Interface de consultation des services
83
4.2.6. Interfaces liées à l’administrateur
Ce sont les interfaces que seul l’administrateur peut y accéder.
L’administrateur est celui qui crée les comptes des employés (agent d’alerte, agent de service,
superviseur). La figure 4.19 monte l’interface de création des employés.
Figure 4.19 : Interface de création d’un employé
L’administrateur peut aussi consulter ainsi que ajouter les domaines a travers l’interface de la
liste des domaines illustré dans la figure 4.20.
Figure 4.20 : Interface de la liste des domaines
84
4.3. Evaluation de la qualité du processus de développement
Afin d’atteindre une bonne qualité de processus, nous avons adopté la méthodologie Scrum
dans la gestion de notre projet.
A travers le tableau de tâches qui représente le backlog de sprint, élaboré lors de la réunion de
planification et qui sert à montrer l’avancement des travaux pendant le sprint.
Egalement par, le burndown chart qui est un indicateur temporel de l'évolution des tâches en
cours dans le Sprint, qui permet d'avoir une prévision de l'état d'avancement à la fin de la
période d'activité.
4.3.1. Revue de release 1
Nous allons présenter les différents tableaux de tâches de chaque sprint du premier release,
ainsi que les burndown chart.
Tableaux de tâches
Les figures 4.21 et 4.22 représentent les tableaux des taches qui correspondent aux sprint1 et
sprint2.
Figure 4.21 : Tableau des tâches du sprint1
85
Burndown Chart du Release 1
Comme le montre la figure 4.23, nous remarquons que le premier sprint s’est terminé dans les
délais adéquats mais l’effort estimé restant est inférieur à celui réel tout au long du sprint ce
qui montre que nous n’avons pas bien estimé l’effort.
Burndown chart Sprint1

180
160
140
120
Scrum units
100
80 Remaining
60 Theorical
40
20
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Days
Figure 4.23 : Burndown chart du sprint1
86
Dans le sprint 2 illustré dan la figure 4.24, les taches ont été achevées à temps et aux deux
derniers jours du sprint le travail s’est bien passé puisque l’effort restant estimé est très proche
de celui réel, mais au début du sprint l’effort estimé restant est inférieur à celui réel.

90
80
70
60
Scrum units
50
40 Remaining
30 Theorical
20
10
0
1 2 3 4 5 6 7 8 9 10 11
Days
Figure 4.24 : Burndown chart du sprint2
4.3.2 Revue du release 2
Nous allons présenter les différents tableaux de tâches de chaque sprint du deuxième release,
ainsi que les burndown chart.
Tableaux de tâches
Les figures 4.25 et 4.26 représentent les tableaux des taches qui correspondent aux sprint3 et
sprint4.
87
Burndown Chart du Release 2
Ce sprint n’est pas achevé dans les délais adéquats, nous remarquons qu’au début l’effort
estimé restant est très proche à celui réel mais aux cinq derniers jours l’effort estimé restant
est devenue inferieur à celui réel à cause des obstacles que nous avons rencontré et des
blocages au niveau de l’implémentation du code. Ce qui déduit que l’estimation proposée ne
88
correspond pas à l’effort fourni réellement. La figure 4.27 montre le burndown chart du
sprint3.

250
200
Scrum units
150
Remaining
100
Theorical
50
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
Days
Figure 4. 27: Burndown chart du sprint3
Au niveau de ce sprint, nous remarquons qu’il s’est terminé dans les délais adéquats, ainsi que
l’effort estimé restant est très proche de ce celui réel. La figure 4.28 illustre le Burndown
chart du sprint4.

45
40
35
30
Scrum units
25
20 Remaining
15 Theorical
10
5
0
1 2 3 4 5 6
Days
Figure 4.28: Burndown chart du sprint4
89
4.4. Conclusion
Dans ce chapitre, nous avons présenté les aspects de réalisation de notre système à travers une
description de l’environnement de travail matériel et logiciel et une présentation du
diagramme de déploiement.
Nous avons également présenté un scénario de test avec des imprimes écrans afin d’illustrer le
fonctionnement de notre application. Dans la dernière partie du chapitre nous avons
représenté l’évaluation de la qualité du processus de développement qui contient les revues
des releases dans laquelle nous trouvons les tableaux de tâches et une analyse des burndown
chart de chaque release.
90
Conclusion générale
Dans le cadre de notre projet de fin d’études, nous avons conçu et développé une plateforme
Freelance. Nous sommes arrivés à réaliser les objectifs globaux que nous avons mis au début
de la période de stage au sein de 360dev. Bien que nous avons rencontré des difficultés, les
chemins que nous avons entrepris pour les dépasser constituent des signes de satisfaction. En
se basant sur la formation que nous avons acquise durant notre cursus universitaire ainsi que
les nouvelles notions que nous avons pu assimiler au cours de notre stage, nous sommes
arrivés à réaliser les objectifs que nous nous somme fixés en respectant la durée prévue pour
la mise en place de notre plateforme.
La mission qui nous a été confiée consistait à concevoir et à réaliser une plateforme Freelance
assurant la réalisation des services demandés par les clients dans des conditions favorables et
avec des exigences de qualité. De plus, elle offre des opportunités d'emploi pour les nouveaux
diplômés. Ainsi qu’elle est un moyen du gain de temps et d’argent. Le choix de la technologie
Laravel ainsi que le choix de l’architecture trois tiers sont des choix stratégiques et éclairés de
la part des dirigeants de 360dev sur la base d’arguments essentiellement fonctionnels.
Nous avons essayé d’avancer dans notre travail d’une manière incrémentale en utilisant la
méthodologie Scrum. Et dans notre cas le projet a été réalisé dans 2 releases, le premier divisé
en 2 sprints et le deuxième aussi en 2 sprints.
Tout au long de l’élaboration du projet, nous avons rencontré plusieurs difficultés aussi bien
sur le niveau conceptuel que sur le niveau de la réalisation. Mais tout de même, nous avons
réussi à les surpasser pour aboutir à la fin un système opérationnel. De plus, les apports de ce
projet sont nombreux. En premier lieu, sur un niveau conceptuel, le projet innove en explorant
de nouvelles technologies. Et en deuxième lieu au niveau de la réalisation, nous avons su
exploiter à fond les possibilités offertes par le développement objet.
Certes, cette Plateforme ne prendra pas fin avec l’achèvement du présent projet mais,
plusieurs améliorations restent envisageables. Ces dernières touchent essentiellement les
niveaux avancés de la sécurité, essentiellement au niveau des services web, le moteur de
règles et le reporting des données.
91
Ce projet était une réelle occasion pour intégrer une équipe compétente et professionnelle. Les
situations de blocage, les problèmes techniques et la pression des délais nous ont appris à
mieux gérer le temps, à adopter une méthodologie de travail et à respecter les spécifications
92
Webographie
[1] https://www.agiliste.fr/introduction-methodes-agiles/ (consulté le 23/02/2018)
[2] https://fr.wikipedia.org/wiki/UML_(informatique) (consulté le 05/03/2018)
[3] http://alain.battandier.free.fr/spip.php?article26 (consulté le 17/03/2018)
[4] https://fr.wikipedia.org/wiki/Modèle-vue-contrôleur (consulté le 10/04/2018)
[5] https://fr.wikipedia.org/wiki/Architecture_trois_tiers (consulté le 20/04/2018)
[6] http://www.guillaumevoisin.fr/internet/larchitecture-mvc-dans-le-developpement-dun-
site-internet (consulté le 02/05 /2018)
[7] https://openclassrooms.com/courses/decouvrez-le-framework-php-laravel/presentation-
generale-13 (consulté le 13/05 /2018)
[8] : https://fr.wikipedia.org/wiki/Sublime_Text (consulté le 20/05 /2018)
93

Rapport Mariem VF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Mariem VF

Transféré par

Droits d'auteur :

Formats disponibles

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

MEMOIRE DE PROJET DE FIN D’ETUDES

Mariem Bousaid 3IM4

Islem Ayari 3IM4

Mariem Fallah ISAMM

Khalil Terzi 360DEV

Tayeb Chargui 360DEV

Année Universitaire 2017-2018

Je remercie Dieu le tout puissant pour l’aide, le courage et la patience

A mes chers frères, pour leur appui, leur encouragement et leur

A toute ma famille pour leur soutien tout au long de mon parcours

À tous ceux qui m’ont aidé afin de réaliser ce travail,

Que ce travail soit l’accomplissement de vos vœux tant allégués, et le

Merci d’être toujours là pour moi.

Rapport de projet fin d’études 2017/2018

A mes chers parents : Tous les mots du monde ne sauraient exprimer

Je dédie aussi ce travail à :

Ma binôme Mariem, qui m'a encouragé et m'a soutenu tout au long de

Et à toute ma famille et à tous ceux que j’aime.

Rapport de projet fin d’études 2017/2018

Au terme de ce travail, Nous tenons à exprimer notre profonde

Nous tenons à remercier également nos encadrants M. Khalil Terzi et

Nos remerciements vont à tout le personnel que nous avons contacté

Enfin, nos remerciements à tous ceux qui ont contribué de prés ou de

Rapport de projet fin d’études 2017/2018

CHAPITRE 1 : ETUDE PREALABLE....................................................................................................................... 3

1.1. PRESENTATION DE LA SOCIETE D’ACCUEIL ............................................................................................................... 4

CHAPITRE 2 : SPECIFICATION DETAILLEE ......................................................................................................... 13

2.1. PRESENTATION DE LA METHODOLOGIE ET LANGAGE ADOPTE .................................................................................... 14

CHAPITRE 3 : CONCEPTION DE LA SOLUTION .................................................................................................. 45

3.1. CONCEPTION TECHNIQUE GLOBALE ..................................................................................................................... 46

Rapport de projet fin d’études 2017/2018

CHAPITRE 4 : REALISATION ET TESTS .............................................................................................................. 66

4.1. ENVIRONNEMENT DE TRAVAIL............................................................................................................................ 67

CONCLUSION GENERALE ................................................................................................................................ 91

Rapport de projet fin d’études 2017/2018

Figure 1.1: Page d'accueil d’UpWork....................................................................................................... 5

Rapport de projet fin d’études 2017/2018

Rapport de projet fin d’études 2017/2018

Tableau 2.1: Description textuelle du cas d'utilisation "Authentification" ........................................... 31

Rapport de projet fin d’études 2017/2018

Actuellement, on vit dans un environnement numérique. Toutes les découvertes

La problématique à laquelle on essaie de répondre dans ce projet est de simplifier et faciliter

Rapport de projet fin d’études 2017/2018 1

Le premier chapitre « Etude préalable » comporte la présentation de la société d’accueil

Le troisième chapitre nommé « Conception de la solution ». Ce chapitre représente la partie

Le quatrième et dernier chapitre « Réalisation et tests » suivra à décrire l’environnement du

1.1. Présentation de la société d’accueil

L’entreprise progresse bien évidemment en adéquation permanente avec la révolution

1.2. Présentation du sujet

1.3. Etude de l’existant

Figure 1.1: Page d'accueil d’UpWork

UpWork permet aux utilisateurs de :

• Chercher, trouver et postuler à un emploi

• Fonds reçus transférables en seulement 6 jours pour des raisons de sécurité.

suite à la scission de l'Office des Postes et Télécommunications

• La Plateforme est non disponible en français.

Figure 1.2: Page d'accueil de Freelancer

Freelancer permet aux utilisateurs de :

• poster des offres d’emploi

• certains membres ne sont pas assez sérieux.

Uprod’it7 est la plateforme tunisienne des freelances entreprises et organismes de trois,

Figure 1.3: Page d'accueil de Uprod’it