Rapport Jee Scrum

MEMOIRE
DE STAGE DE FIN D’ETUDES

Pour l’obtention du
«Mastère professionnel en Nouvelles Technologies des
Télécommunications et Réseaux (N2TR)»
Présenté par :
EL OUNI Ilhem
Titre
Conception et Réalisation d’une Plateforme de Détection et Gestion des
Appels d’Offre
Devant le jury :
Président : Mr. BEN BRAIEK E

Encadreur : Mme. AMMARI Imene
Rapporteur : Mme. BOUSNINA Ines
Membre : Mr. MAMI Habib
Année Universitaire : 2017 / 2018

ii
Dédicaces
Je dédie ce modeste travail à mes chers parents Mohamed Najem et

Monia qui ont consenti des sacrifices pour ma réussite dans la vie et
dans mes études .Que Dieu le tout puissant leur procure la bonne santé
et le bonheur. Mes chers frères et soeur Khaled, Zied et Maha qui m'ont
beaucoup encouragée et soutenue.
A mon cher époux Anis qui m'a beaucoup encouragée et soutenue

tout au long de ce projet ainsi que mes chers enfants Meriam et
Hammadi.
A tous ceux qui me connaissent et contribuent du près ou de loin à

entamer ce travail et auxquels je dois être reconnaissante
Illhem EL OUNI
iii
Remerciements
D'emblée je tiens à remercier DIEU le tout puissant de nous avoir aidé

à entamer et à terminer ce travail.
Je dois être reconnaissante en remerciant infiniment mon encadrante

universitaire Mme AMMARI Imene ainsi que mon encadrant de stage
MAMI Mohamed qui m'ont beaucoup aidée et soutenue pour que ce travail
soit bien organisé en me mettant sur la bonne voie sur tous les plans et que
sans eux ce travail ne pourrait voir le jour.
Tous mes remerciements les plus sincères à toute personne m'a aidé de
près ou de loin pour réaliser et présenter ce projet dans de bonnes conditions
iv
v
Table des matières
Dédicaces .............................................................................................................................. iii
Remerciements ..................................................................................................................... iv
Table des matières ................................................................................................................ vi
Liste des figures ..................................................................................................................... x
Liste des tableaux ................................................................................................................ xii
Liste des abréviations ......................................................................................................... xiii
INTRODUCTION GÉNÉRALE .......................................................................................................................... 1
CHAPITRE I. CADRE GÉNÉRAL DU PROJET ......................................................................................... 2
Introduction.............................................................................................................................................. 3
I.1 Présentation de Société ................................................................................................................... 3
I.1.1 Présentation du l’organisme d’accueil .................................................................................. 3
I.1.2 Service de Cynapsys ............................................................................................................. 3
I.2 Cadre de Projet ............................................................................................................................... 5
I.2.1 Contexte de Projet ................................................................................................................. 5
I.2.2 Analyse de l’existant :........................................................................................................... 6
I.2.2.1 Étude de l'existant........................................................................................................ 6

I.2.2.2 Description de l’existant .............................................................................................. 6
I.2.2.3 Critiques de l'existant .................................................................................................. 7
I.2.2.4 Solution proposée ........................................................................................................ 8
I.3 Méthodologies de travail ................................................................................................................ 8
I.3.1 Méthodologie agile ............................................................................................................... 8
I.3.2 Pourquoi Scrum .................................................................................................................... 9
I.3.3 Langages de modélisation ................................................................................................... 11
Conclusion ............................................................................................................................................. 11
CHAPITRE II. PRÉPARATION.DE PROJET ............................................................................................ 12
Introduction............................................................................................................................................ 13
II.1 Capture du Besoin ........................................................................................................................ 13
II.1.1 Spécifications des Besoins .................................................................................................. 13
II.1.1.1 Spécifications des Besoins Fonctionnels ................................................................... 13
vi
II.1.1.2 Spécification des Besoins non fonctionnels .............................................................. 14
II.1.2 Modélisation du besoin ....................................................................................................... 15
II.1.2.1 Identification des acteurs ........................................................................................... 15

II.1.2.2 Diagramme de cas d'utilisation globale ..................................................................... 16
II.2 Pilotage du Projet avec Scrum ...................................................................................................... 16
II.2.1 Equipe et rôle ...................................................................................................................... 16
II.2.2 Le Backlog du produit ........................................................................................................ 17
II.2.3 Planification de Release ...................................................................................................... 22
II.3 Environnement de travail ............................................................................................................. 23
II.3.1 Environnement matériel ...................................................................................................... 24
II.3.2 Environnement Logiciel...................................................................................................... 24
II.3.2.1 Outils de développement et modélisation :................................................................ 24

II.3.2.2 Plateforme de développement : ................................................................................. 25
II.3.2.3 Langages de programmation : ................................................................................... 27
II.3.2.4 Framework utilisé ...................................................................................................... 29
II.4 Architecture .................................................................................................................................. 30
II.4.1 Architecture du système ...................................................................................................... 30
II.4.2 Architecture n-Tiers ............................................................................................................ 30
II.4.3 Architecture de l’application............................................................................................... 31
Conclusion ............................................................................................................................................. 32
CHAPITRE III. RELEASE 1 ..................................................................................................................... 33
Introduction............................................................................................................................................ 34
III.1 Développement du Sprint1 « Authentification, Inscription et Gestion de profil » ....................... 34
III.1.1 Analyse .......................................................................................................................... 36
Diagramme de cas d’utilisation .................................................................................................... 36

III.1.1.1 Description de l’item « S’inscrire »........................................................................... 36
III.1.1.2 Description de l’item « S’authentifier » .................................................................... 37
III.1.1.3 Description de l’item « Gérer profil » ....................................................................... 39
III.1.2 Conception ..................................................................................................................... 40
III.1.2.1 Diagrammes de séquence .......................................................................................... 40

III.1.2.2 Diagrammes de classes .............................................................................................. 41
III.1.3 Réalisation...................................................................................................................... 43
III.1.3.1 Architecture logique .................................................................................................. 43

III.1.3.2 Description des interfaces utilisateurs ....................................................................... 43
vii
III.2 Développement du Sprint 2 « gestion des abonnées et des prestataires» .................................... 48
III.2.1 Analyse .......................................................................................................................... 50
Diagramme de cas d’utilisation global ......................................................................................... 50

III.2.1.1 Descriptions de l’item «Gérer prestataires » ............................................................. 50
III.2.1.2 Description de l’item « Gérer les types d’abonnements » ......................................... 53
III.2.1.3 Diagramme de séquence ............................................................................................ 56
III.2.1.4 Diagramme de classe ................................................................................................. 58
III.2.1.5 Schéma Relationnel ................................................................................................... 58
III.2.2 Réalisation...................................................................................................................... 59
III.2.2.1 Description des interfaces ......................................................................................... 59
III.3 Conclusion :.................................................................................................................................. 62
CHAPITRE IV. RELEASE2 ...................................................................................................................... 63
Introduction............................................................................................................................................ 64
IV.1 Développement du Sprint1 « Gestion des appels d’offre, des infrastructures, des progiciels, des
services» ................................................................................................................................................ 64
IV.1.1 Analyse .......................................................................................................................... 68
IV.1.1.1 Diagramme de cas d’utilisation du sprint1 ................................................................ 68

IV.1.1.2 Description de l’item « Gérer les appels d’offre » .................................................... 68
IV.1.2 Conception ..................................................................................................................... 72
IV.1.2.1 Diagramme de séquence ............................................................................................ 72

IV.1.2.2 Diagramme de classe ................................................................................................. 75
IV.1.2.3 Schéma Relationnel ................................................................................................... 76
IV.1.3 Réalisation...................................................................................................................... 76
IV.1.3.1 Description des interfaces ......................................................................................... 76
IV.2 Développement du Sprint 2 « gestion des abonnées et statistique »............................................. 80
IV.2.1 Analyse .......................................................................................................................... 82
IV.2.1.1 Diagramme de cas d’utilisation du sprint 2 ............................................................... 82

IV.2.1.2 Description de l’item « Gérer les abonnements »...................................................... 82
IV.2.1.3 Description de l’item « Gérer les statistique » .......................................................... 85
IV.2.1.4 Diagramme de séquence ............................................................................................ 86
IV.2.1.5 Diagramme de classe ................................................................................................. 88
IV.2.1.6 Schéma Relationnel ................................................................................................... 89
IV.2.2 Réalisation...................................................................................................................... 90
IV.2.2.1 Architecture physique................................................................................................ 90

IV.2.2.2 Description des interfaces ......................................................................................... 90
viii
IV.3 Conclusion .................................................................................................................................... 93
CONCLUSION GÉNÉRALE ........................................................................................................................... 94
Bibliographie ....................................................................................................................... 95
ix
Liste des figures
Figure 1:Place de marché "Tunisia Trading" ..................................................................................... 6

Figure 2:Place de marché "LMI": ...................................................................................................... 7
Figure 3:Méthodologie agile ............................................................................................................ 10
Figure 4:Diagramme de cas d'utilisation globale ............................................................................. 16
Figure 5: Schéma de Release ........................................................................................................... 23
Figure 6:Architecture de système ..................................................................................................... 30
Figure 7:Architecture n-Tiers ........................................................................................................... 31
Figure 8:Architecture de l’application : MVC ................................................................................. 31
Figure 9: Décomposition sprint 1 en Items ...................................................................................... 34
Figure 10: Diagramme de cas d’utilisation du sprint1 ..................................................................... 36
Figure 11: Diagramme de cas d’utilisation du « S’inscrire » ........................................................... 36
Figure 12:Diagramme de cas d’utilisation « S’authentifier» ........................................................... 37
Figure 13:Diagramme de cas d’utilisation « Gérer profil » ............................................................. 39
Figure 14:Diagrammes de séquence User story 1.3 « Modifier Profil » .......................................... 41
Figure 15:Diagramme de classes du sprint 1.................................................................................... 42
Figure 16:Diagramme de composants « S’authentifier » ................................................................. 43
Figure 17:Page d'accueil 1 ............................................................................................................... 44
Figure 18:Interface de connexion..................................................................................................... 44
Figure 19:Interface d'inscription ...................................................................................................... 45
Figure 20:Page d'accueil .................................................................................................................. 45
Figure 21:Interface de Dashboard .................................................................................................... 46
Figure 22:Consultation de profil ...................................................................................................... 46
Figure 23:Modifier photo ................................................................................................................. 47
Figure 24:Modification de profil ...................................................................................................... 47
Figure 25: Décomposition sprint 2 en Items .................................................................................... 48
Figure 26: Diagramme de cas d’utilisation du sprint 2 .................................................................... 50
Figure 27:Diagramme de cas « Gérer des prestataires » .................................................................. 51
Figure 28:Diagramme de cas « Gérer les types des abonnements » ................................................ 54
Figure 29:Diagrammes de séquences User story 4.2 « Valider des prestataires » ........................... 56
Figure 30: Diagrammes de séquences User story 7.3 « Modifier type d’abonnement » .................. 57
Figure 31:Diagramme de class de sprint 2 ....................................................................................... 58
Figure 32:Menu de Prestataires ........................................................................................................ 59
x
Figure 33: liste des prestataires ........................................................................................................ 60
Figure 34: liste des prestataires non validés ..................................................................................... 60
Figure 35:Liste des prestataires ........................................................................................................ 61
Figure 36:Message de confirmation pour supprimer un prestataire ................................................. 61
Figure 37:liste type des abonnements .............................................................................................. 62
Figure 39: Diagramme de cas d’utilisation du sprint1 ..................................................................... 68
Figure 40:Diagramme de cas d’utilisation « Gérer les appels d’offre » par prestataire ................... 69
Figure 41: Diagramme de cas d’utilisation « Gérer les appels d’offre » par l’administrateur ......... 71
Figure 42:Diagrammes de séquences User story 8.3 « Valider les appels d’offres » ...................... 73
Figure 43:Diagrammes de séquences User story 10.3 « Modifier Infrastructure ».......................... 74
Figure 44 :Diagramme de class de sprint 1 ...................................................................................... 75
Figure 45:Menu des appels d'offres ................................................................................................ 76
Figure 46:Formulaire pour ajouter appel d'offre .............................................................................. 77
Figure 47:Consulter les appels d'offres ............................................................................................ 77
Figure 48: détails appel d’offre ........................................................................................................ 78
Figure 49:Liste des appels d'offres à valider .................................................................................... 79
Figure 50:Consulter les appels d'offres ............................................................................................ 79
Figure 51:Consulter en détails un appel d'offre ............................................................................... 80
Figure 52:liste type des abonnements .............................................................................................. 80
Figure 54: Diagramme de cas d’utilisation Sprint 2......................................................................... 82
Figure 55: Diagramme de cas d’utilisation « Gérer les abonnements» ............................................ 83
Figure 56:La Diagramme de cas d’user story 12 " Gestion des statistique " ................................... 85
Figure 57: Diagrammes de séquences User story 14.1« Modifier la date d’expiration d’un
abonnement »........................................................................................................................... 86
Figure 58: Diagrammes de séquences User story 13.1 « Abonnée» ................................................ 87
Figure 59: Diagrammes de séquences User story 15.1« afficher la liste des statistiques»............... 87
Figure 60:Diagramme de class ......................................................................................................... 88
Figure 61: Diagramme de déploiement ............................................................................................ 90
Figure 62:Liste des abonnements ..................................................................................................... 91
Figure 63: contacter l'administrateur ................................................................................................ 91
Figure 64: Statistiques ...................................................................................................................... 92
Figure 65: Statistiques :nombre des appels d’offre par mois ........................................................... 92
Figure 66: Statistiques : Bénéfices abonnement par mois ................................................................ 92
xi
Liste des tableaux
Table 1:Description des acteurs ....................................................................................................... 15

Table 2:Présentation de l’équipe SCRUM ....................................................................................... 17
Table 3:Backlog du produit .............................................................................................................. 22
Table 4:Environnement matériel ...................................................................................................... 24
Table 5:les user stories de sprint 1 ................................................................................................... 35
Table 6: Backlog du sprint 1 ............................................................................................................ 35
Table 7: Description textuelle du cas d’utilisation « S’inscrire » .................................................... 37
Table 8: Description textuelle du cas d’utilisation « S’authentifier » .............................................. 38
Table 9: Description textuelle du cas d’utilisation « Modifier profil » ............................................ 40
Table 10:les user stories de sprint 2 ................................................................................................. 49
Table 11: Backlog du sprint 2 .......................................................................................................... 50
Table 12:Description textuelle du cas d’utilisation « Valider prestataire» ...................................... 52
Table 13: Description textuelle du cas d’utilisation « Activer prestataire» ..................................... 52
Table 14: Description textuelle du cas d’utilisation « Supprimer prestataire» ................................ 53
Table 15: Description textuelle du cas d’utilisation « Supprimer un type d’abonnement» ............. 55
Table 16: Description textuelle du cas d’utilisation «Ajouter un type d’abonnement » .................. 55
Table 17:les user stories de sprint 1 ................................................................................................. 66
Table 19: Description textuelle du cas d’utilisation « Ajouter appel d’offre» ................................. 70
Table 20: Description textuelle du cas d’utilisation « Postuler appel d’offre» ................................ 71
Table 21: Description textuelle du cas d’utilisation « Postuler appel d’offre» ................................ 72
Table 22: les user stories de sprint 2 ................................................................................................ 81
Table 24: Description textuelle du cas d’utilisation « Activer abonnement» .................................. 84
Table 25: Description textuelle du cas d’utilisation « modifier la date d’expiration d’un
abonnement»............................................................................................................................ 84
Table 26:Description détaillée du user story 6.3 .............................................................................. 86
xii
Liste des abréviations
IT Informatique Technologie
ESN Entreprise Service Numérique
GFI Groupe Français d'Informatique
CA Chiffre d’affaire
TMA Tierce Maintenance Applicative
UML Unified Lodeling Language
OMG Object Management Group
OMT Object Modeling Technique
OOSE Object Oriented Software Engineering
MVC Modèle Vue Contrôleur
HTTP Hyper Text Transfer Protocol
IHM Homme Machine
SQL Structured Query Language
MYSQL My1 Structured Query Language
J2EE Java Entreprise Edition
HTML Hyper Text Markup Langage
CSS Cascading Style Skee
xiii
CHAPITRE I CADRE GÉNÉRAL DU PROJET
Introduction générale
Au cours des dernières décennies, la révolution d'informatique a balayé tous les pays du
monde, cela inclut notre pays la Tunisie qui a connu un fort développement incontestable
dans ce domaine.
Parmi les outils qui ont impulsé le marché informatique, nous citons les applications, qui se
définissent comme des programmes gratuits ou payants et exécutables à partir du système
d’exploitation. Conjugués à l’essor d’Internet, ils permettent généralement un accès plus
confortable et plus efficace à des sites ou à des services accessibles par ailleurs en versions
web.
Dans ce contexte, l’entreprise « Cynapsys » dans laquelle nous avons effectué notre stage
de fin d’études, voudrait mettre en place une application Web intégrant.
Dès lors, notre projet de fin d’études consiste à concevoir et à réaliser une application Web
de gestion des appels d’offre, des prestataires, des services, des infrastructures et des
progiciels. Cette application est Web qui permet de gérer les appels, les prestataires, les
abonnements, les infrastructures, les progiciels et de services.
Le présent rapport est organisé en cinq chapitres :
 Le premier chapitre intitulé « Cadre Général du projet » présente l’organisme
d’accueil, décrit le contexte de notre projet ainsi que la méthodologie adoptée.
 Le deuxième chapitre « Préparation.de Projet» explique notre démarche, soit,
l’identification des futurs acteurs de notre système et l’analyse des besoins. Et aussi
la description de l’architecture choisie pour réaliser notre solution.
 Le troisième chapitre comporte la première version (release) de notre projet défini
en se basant sur la méthodologie Scrum. Nous présentons tout au long de ce
chapitre la spécification, la conception et la réalisation des deux premiers sprints.
 Le quatrième chapitre est dédié à la réalisation du deuxième release.
1
Chapitre I. Cadre Général du Projet
2
Introduction
Le présent chapitre, est consacré à la présentation du cadre général du projet. Tout d’abord,
nous présentons l'organisme d'accueil, le travail demandé. Ensuite, nous effectuons une
étude de l’existant. Enfin, nous expliquons notre méthode du travail, le chronogramme du
projet et le langage de modélisation que nous avons adoptée au cours de notre travail.
I.1 Présentation de Société
I.1.1 Présentation du l’organisme d’accueil
Cynapsys est une ESN Tunisienne fondée en 2004 qui s’est ralliée au groupe GFI depuis le
05 Février 2018. GFI Informatique représente un acteur européen de référence des services
informatiques à valeur ajoutée et des logiciels.
Il occupe un positionnement stratégique différenciant entre les opérateurs de taille
mondiale et les acteurs de niche. GFI Informatique figure parmi les premières sociétés
européennes de services informatiques avec ses 15 000 consultants dans le monde et un
CA de plus de 1.2 Milliard d’Euros.
E Digitales est la filiale française de Cynapsys dirigée par Mr Fares Belghith. Elle est
rattachée au groupe GFI.
Comme Cynapsys est proche culturellement et géographiquement de ses clients, elle est
présente avec ses services dans le continent européen, notamment en France à Paris et en
Allemagne à Munich. Cynapsys met à la disposition de ses clients ses compétences en
.Net, Java J2EE, Oracle, SAP, Solutions Web, Systèmes embarqués et Applications
Mobiles [B1].
I.1.2 Service de Cynapsys
L'approche adoptée par Cynapsys est basée sur les services. En effet Cynapsys fournit des
prestations à haute valeur ajoutée dans les domaines des systèmes embarqués, des systèmes
d’information et des applications pour la mobilité. Les services offerts par Cynapsys sont
les suivants :
3
 Développement spécifique :
Face aux besoins particuliers de ses clients opérants dans les différents secteurs, Cynapsys,
expert en « It consulting » propose ses services de développement spécifique software et
hardware.
 Développement spécifique : Méthodologie

Sa méthodologie de développement spécifique consiste en première phase à accompagner
le client dans la formulation de ses besoins, étudier la faisabilité de son projet et l’assister
dans l’élaboration du cahier des charges.
 Développement spécifique : Processus

Pour la bonne réalisation du produit, les ingénieurs affectés au projet mettent en œuvre
tous les processus prédéfinis et rodés conformément aux termes du cahier des charges.
En étroite collaboration avec le client, l’équipe projet transfert le produit développé en
assurant son bon fonctionnement dans l’environnement de déploiement et s’engage dans la
formation de l’équipe client.
 Tierce Maintenance Applicative :
La valeur ajoutée TMA (Tierce Maintenance Applicative), réside dans la capacité à allier
un très haut niveau d’expertise technique et une approche souple et évolutive qui permet de
bénéficier de multiples avantages :
 Performance et disponibilité.
 Réactivité et proximité.
 Engagements d’un service qualité.
Tierce Qualification Applicative :

Cynapsys garantit à ses clients un service de Qualification applicative qui se décompose en
plusieurs types :
 Une validation fonctionnelle : Ce type vérifie si les différents modules ou

composants implémentent correctement les exigences client.
 Une validation de la solution informatique : Cette validation assure la conformité
des livrables aux exigences et aux attentes des clients d'un point de vue « use
cases».
4
 Une validation de performance : La validation de performance permet de parapher

la conformité de la solution par rapport aux résultats escomptés.
 Conseil informatique :
Une équipe d’Experts spécialisée dans les études stratégiques et opérationnelles, l’audit et
le conseil informatique. Ils ont pour mission :
 Assister, conseiller et accompagner les clients sur tous les thèmes en
rapport avec l'organisation de systèmes d'information.
 Evaluer les systèmes informatiques, réseau et communications.
 Elaborer les schémas directeurs informatiques, plans d’actions et
assister les clients à leurs mises en œuvre.
 Auditer la sécurité informatique selon les normes en vigueur.
I.2 Cadre de Projet
I.2.1 Contexte de Projet
Le présent projet intitulé « Place de marché IT » est réalisé dans le cadre de projet de fin
d'études pour l'obtention du diplôme master en Nouvelle Technologie et
Télécommunication Réseaux « N2TR » au sein de l’Université virtuelle de Tunis « UVT».
Ce projet a été réalisé dans la société Cynapsys durant la période s'étalant du 02 avril
2018 jusqu'à 02 juillet 2018.
La plateforme « Place de marché » permet de gérer les prestataires, les abonnements, les
infrastructures, les services, les progiciels et les appels d’offre disposant d’un délai défini
par une date de début et une date de fin précisé par le donneur d’ordre.
Elle offre, également, la possibilité aux prestataires IT, déjà inscrits, à répondre aux
appels d’offres et à interagir. Une place de marché contient un annuaire de prestataire IT
construit à partir de leurs inscriptions.
5
I.2.2 Analyse de l’existant :
L’analyse de l’existant permet de détecter les problèmes et les difficultés du système actuel
pour trouver les adéquates.
I.2.2.1 Étude de l'existant
I.2.2.2 Description de l’existant
Il existe plusieurs plateformes en ligne qui permettent aux entreprises de trouver les appels
d’offre souhaités mais ils existent uniquement quelques solutions qui sont largement
utilisées.
Après l’investigation que nous avons faite au milieu des experts métiers ainsi qu’au milieu
de développeurs « free lancers » et après les recherches sur Google, nous avons noté
qu'uniquement les deux plateformes « Tunisia trading » et « LMI » sont fréquemment
visitées par les internautes.
Figure 1:Place de marché "Tunisia Trading"
6
Figure 2:Place de marché "LMI":
I.2.2.3 Critiques de l'existant
Les solutions existantes n'utilisent pas les techniques modernes de développement surtout
au niveau du front end.
Les solutions déjà présentées rencontrent plusieurs problèmes critiques :
 Problèmes de performance : Temps de réponse important surtout en cas d’un grand
trafic (lorsque l’application est utilisée simultanément par plusieurs utilisateurs).
 Problèmes au niveau de l’expérience utilisateur :
- Pour les solutions existantes, l’utilisateur ne peut pas accéder à toutes les
fonctionnalités en cas où il se connecte à travers son mobile (une grande partie des
interfaces est totalement cachée).
- Pour chaque tâche, l’utilisateur doit passer par plusieurs interfaces pour accomplir
celle-ci. Le principe de fonctionnement de ces solutions n’est pas basé sur l’approche de
page web unique (Single web page).
C’est cette approche qui caractérise les applications modernes et c’est la tendance actuelle
au sein de grosses boîtes de développement international comme GOOGLE qui a réalisé
tout un Framework pour faciliter le développement des applications suivant cette approche.
De même au niveau ergonomique, ces applications ont des interfaces non conviviales
pourront avoir des effets négatifs sur la psychologie de l’être humain.
 Problèmes au niveau fonctionnel :
7
Les outils existants ne répondent pas parfaitement aux besoins des professionnels IT : que
ce soit pour les chercheurs de missions (Product Développer) ou pour les entrepreneurs
(Product Owners). Il est très important de réaliser un produit de qualité et dans une courte
durée d’où permettre aux utilisateurs de maintenir une communication instantanée sans
passer par un tiers.
 Les solutions existantes n’offrent pas une sorte de chambre de discussion (chat
room) pour les utilisateurs.
I.2.2.4 Solution proposée
Pour garantir une haute disponibilité et une bonne performance, l’utilisation des nouveaux
outils de développement est indispensable avec une architecture solide et évolutive.
L’interaction des utilisateurs à l’application est une partie importante pour les fidéliser,
nous avons pensé à des interfaces simples et des actions faciles à utiliser en réduisant le
passage entre l’interface afin de garantir que l’utilisateur accède à l’information le plus
rapide possible sans passer par un workflow lourd.
I.3 Méthodologies de travail

Pour la performance de notre système de gestion d’informations, et pour satisfaire les
exigences du client en moindre coût et délai, nous avons utilisé une méthode agile pour le
déroulement du projet.
I.3.1 Méthodologie agile
Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit
collaboratif.
On citera comme méthodes de développement Agile :
 Dynamics System Développement Méthode (DSDM, 1995)

 Scrum (1996)
 Rapid Application Développent (RAD, 1991)
 Extrême Programming (XP, 1999)
8
 Adaptive Software Développement (ASD, 2000)

 Test Drivent Développement (TDD, 2002)
 Crystal Clédar(2004)
I.3.2 Pourquoi Scrum
Dans le cadre de notre projet et afin d’assurer le bon déroulement des différentes phases
de ce dernier, nous avons opté pour la méthode agile Scrum pour la conception et le
développement de notre système pour des raisons bien déterminées en effet le processus
Scrum s’adapte parfaitement à la décomposition du notre projet de fin d’étude, il se base
sur les avantages suivants :
 Plus de souplesse et de réactivité,
 Grande capacité d’adaptation au changement grâce à des itérations courtes,
 Satisfaire au mieux les besoins du client.
Scrum :
Est une méthodologie agile qui consiste à avoir une équipe soudée orientant le projet au fil
de son avancement afin d’atteindre un but. Cette approche est à la fois dynamique et
productive, engendre la réalisation des fonctionnalités par itération en incluant la
participation du client. Chaque itération peut durer de deux à quatre semaines, à la fin de
chaque sprint un produit fonctionnel doit être livré. En effet, Scrum définit trois rôles qui
sont
Le Product Owner est responsable du produit de l’équipe projet client et il représente les
utilisateurs finaux, son rôle est de :
 Définir la liste des fonctionnalités du produit.
 Prioriser les fonctionnalités en fonction de leur importance et leur valeur ajoutée
pour l’entreprise qu’il présente.
 Choisir la date de livraison des versions ainsi que leurs contenus.
 Valider les lots livrés avec l’équipe de développement
 Clarifier les besoins à l’équipe de développement si nécessaire
Le Scrum master assure les tâches suivantes :
 S’assurer que Scrum est bien appliquée et respectée
9
 Encourager l’équipe à apprendre et à progresser pour qu’elle soit fonctionnelle,

productive et créative durant le projet
 Eliminer les obstacles pouvant perturber la progression du travail.
L’équipe de projet contient généralement de 2 à 10 développeurs. Elle regroupe tous les
rôles habituellement nécessaires à un projet, à savoir l’architecte, le concepteur, le
développeur, le testeur, etc. Elle est « auto organisée » et elle reste inchangée pendant toute
la durée du sprint. Son rôle principal est :
 Transformer les besoins exprimés dans le Sprint Backlog (est défini ci-dessous) en
fonctionnalités utilisables.
 Livrer régulièrement une version fonctionnelle du produit.
La figure ci-dessous présente le déroulement de la gestion de projet par Scrum.
Figure 3:Méthodologie agile
Backlog produit (ou catalogue des besoins)

 Besoins priorisés par le Product Owner.
 Besoins évalués par l’équipe.
Sprint Backlog
 Extrait du Backlog produit.
Sprint (itération)
 Développement des fonctionnalités du Backlog de sprint.
 Aucune modification du Backlog de sprint possible.
 Mêlée quotidienne (Rencontre quotidienne)
10
 Point de contrôle quotidien de l’équipe.

 Intervention régulées – 2 min par personne.
Produit livrable livré au Product Owner à la fin du sprint.
I.3.3 Langages de modélisation
Pour Faciliter notre tâche nous avons fait recours au langage de modélisation unifié UML.
L’Uml était développée en réponse à l’appel à propositions lancées par l’OMG dans le but
de définir la notation standard pour la modélisation des applications construites à l’aide
d’objets. Elle est héritée de plusieurs autres méthodes telles qu’OMT et OOSE et Booch.
Les principaux auteurs de la notation UML sont Grady Booch, Ivar Jacobson et Jim
Rumbaugh.
Nous considérons que le langage le mieux adapté pour fournir à Cynapsys une présentation
compréhensible du devenir de sa nouvelle vitrine web. Les divers diagrammes UML
permettent de bien exposer nos solutions. [N2]
Conclusion
Dans ce chapitre, nous avons donné un aperçu du projet en décrivant l'organisme d'accueil,
Cynapsys, et le contexte du projet. Nous avons présenté aussi notre méthodologie de
travail pour réaliser notre projet, comme la méthode Scrum.
Le reste du rapport est organisé selon cette méthodologie. Le chapitre suivant traite la
préparation du projet.
11
CHAPITRE II PRÉPARATION DU PROJET
Chapitre II. Préparation.de Projet
12
Introduction
Dans Ce chapitre est consacré à la capture des besoins fonctionnels et non fonctionnels de
notre système, au pilotage de projet avec scrum, par élaboration du Backlog du produit
avec une planification des sprints ainsi qu’à la description de l’environnement de travail.
II.1 Capture du Besoin
II.1.1 Spécifications des Besoins
II.1.1.1 Spécifications des Besoins Fonctionnels
Définition : Un besoin fonctionnel est un besoin direct exprimant une réponse à une action,
demande ou information système.
Notre application offre une interface web pour accéder aux espaces suivants :
Mode non connecté:
 Consulter les offres d’appels et les entreprises aussi les filtre selon des mots-clés
proposés de plateforme ou bien leurs propres mots- clés
 Fournir une aide en ligne pour rester en communication avec les utilisateurs et
facilement on peut répondre à ses besoins
 S’inscrire : Pour posséder un compte un prestataire doit remplir un formulaire
d’inscription contenant toutes ses informations nécessaires.
 Assurer la sécurité du site par L’authentification (login / mot de passe)
Mode connecté:
 Contrôler la gestion des prestataires (valider/ refuser/ activer/désactiver)
 Inspecter la gestion des appels d’offres (valider/ refuser/ activer/désactiver)
 Garantir la réactivité vis-à-vis des messages envoyés par les utilisateurs.
 Quadriller en permanence les prestataires selon le type d leurs abonnements
(1mois/ 3mois/ 6mois/1an)
13
 Poser sa candidature pour les appels d’offre, commander les produits, et contacter
les entreprises
 Envoyer aux clients des emails de notifications pour chaque nouvel appel d’offre et
s’il y’a quelqu'un postulé à votre appel d’offre pour faciliter la recherche et
l’obtention de l’offre souhaitée
 La sécurité des informations avec l’option de modification de coordonnées.
 La faculté d’une recherche avancée par des checks box.
 La fiabilité de la procédure du paiement et la garantie du téléchargement.
 La possibilité d’opter pour le système d’abonnement et bénéficier des privilèges
accordés.
 Contacter facile de l’administrateur en cas de besoin.
 Générer des rapports (statistique pour les abonnements et les appels d’offres)
II.1.1.2 Spécification des Besoins non fonctionnels
Une fois les besoins fonctionnels sont bien définis, les besoins non fonctionnels doivent
être pris en compte tout au long du processus de développement de l’application à savoir :
 Performance : Un minimum de délai d’attente.
 Simplicité d’utilisation : un utilisateur avec un minimum de connaissance en
application mobile doit être capable de manipuler les différentes tâches de
l’application avec un minimum de clicks (touche écran) possibles.
 Extensibilité : l’application doit permettre à tout moment l’ajout d’autres modules.
 Portabilité : L’application doit être portable et fonctionnelle sur n’importe quel
système d’exploitation.
14
II.1.2 Modélisation du besoin
II.1.2.1 Identification des acteurs
Un acteur est la personne ou le matériel qui interagit avec notre système afin de réaliser
une valeur ajoutée. La plateforme de Place de marché IT fait intervenir quatre acteurs
principaux comme le montre le tableau ci-après.
Rôle Fonctions
Administrateur Un administrateur devra pouvoir ajouter, modifier et supprimer

les utilisateurs et les données de référence. Il dispose de toutes
les autorisations sur l’application.
Commanditaire Après sa connexion, il devra pouvoir ajouter un appel d’offre.
Prestataire Le prestataire : est connecté individuellement, il cherche des

offres d’appel et y postule
Internaute c’est un utilisateur qui n’est pas inscrit et qui peut consulter les
appels d’offres mais avec un minimum des informations
Table 1:Description des acteurs
Notre projet comprend acteurs :

 Administrateur : il doit assurer la sécurité de site et contrôler la gestion des
prestataires et des appels d’offres aussi, il doit être réactif à toute demande
 Prestataire : Il bénéficiera d’une protection de ses informations personnelles avec

une recherche avancée qui lui facilitera sa requête en poursuivant une procédure de
paiement fiable et un téléchargement garanti
Le prestataire est de trois types : Commanditaire, Soumissionnaire et Internaute
15
II.1.2.2 Diagramme de cas d'utilisation globale
Figure 4:Diagramme de cas d'utilisation globale
II.2 Pilotage du Projet avec Scrum
II.2.1 Equipe et rôle
Pour notre application les rôles sont repartis comme suit :
16
Rôles Scrum Personnes Affectées

Product Owner Cynapsys
Scrum Master Mr.Kais AZZOUZ
Team Ilhem EL OUNI, M.Imen AMMARI et Mr. Habib
MAMI
Table 2:Présentation de l’équipe SCRUM
II.2.2 Le Backlog du produit
Le Backlog du produit est l’artefact le plus important de Scrum. En effet, c’est l’ensemble
des caractéristiques fonctionnelles qui compose le produit. Ces caractéristiques sont
appelées des histoires utilisateurs (user story). Chaque histoire utilisateur est caractérisée
par une priorité définie par le Product Owner.
Le Backlog produit de notre futur système notre projet est le suivant :
Sprint User story En tant que … Je veux… Priorité
Authentification Abonné M’authentifier 1

« Authentification, Inscription, Gestion de profil»
Inscription Non abonné M’inscrire 2
Gestion de profil Prestataire Afficher mon profil 3
Gestion de profil Prestataire Modifier mon profil 3
17
Gestion de profil Prestataire Modifier image 3
Gestion de profil Prestataire Désactiver profil 3
Gérer les Administrateur Afficher les prestataires 4

prestataires
Gérer les Administrateur Consulter la liste des inscriptions 4

prestataires pour valider ou refuser le
prestataire
Gérer les Administrateur Consulter la liste des prestataires 4

prestataires pour rechercher un prestataire
« Gestion prestataires et types d’abonnements »

prestataires pour activer ou désactiver le
prestataire

prestataires pour supprimer un prestataire
Gérer les Prestataire Consulter la liste des prestataires 5

prestataires
Gérer les Prestataire Rechercher le prestataire 5

prestataires
Gérer les Prestataire Choisir l’abonnement 6

abonnements
18
Gérer les Administrateur Afficher la liste des types 7

abonnements d’abonnement
Gérer les Administrateur Ajouter un type d’abonnement 7

abonnements
Gérer les Administrateur Modifier un type d’abonnement 7

abonnements
Gérer les Administrateur Supprimer un type d’abonnement 7

abonnements
Gérer les appels Administrateur afficher les appels d’offres 8

« Gestion des appels d’offre, des infrastructures, des progiciels, des services»
d’offres
Gérer les appels Administrateur Consulter la liste des appels 8

d’offres d’offres pour chercher un appel
d’offre

d’offres d’offres pour valider ou refuser
ou refuser

d’offres d’offres pour activer ou désactiver
un appel d’offre
Gérer les appels Prestataire Consulter la liste des appels 9

d’offres d’offres
Gérer les appels Prestataire Rechercher un appel d’offre 9

d’offres
19
Gérer les appels Prestataire Consulter la liste mes appels 9

d’offre d’offres validées
Gérer les appels Prestataire Consulter l’appel d’offre en 9

d’offres détails et télécharger le cahier de
charge.
Gérer les appels Prestataire Remplir un formulaire pour 9

d’offres ajouter un appel d’offre avec son
cahier de charge.
Gérer les appels Prestataire Postuler à un appel d’offre en 9

d’offres uploadant les fichiers
Gérer Infrastructure Administrateur Consulter des infrastructures 10
Gérer les Administrateur Ajouter une infrastructure 10

Infrastructures
Gérer les Administrateur Modifier une infrastructure 10

Infrastructures
Gérer les Administrateur Supprimer une infrastructure 10

Infrastructures
Gérer les Administrateur Consulter des Progiciels 11

Progiciels
Gérer les Progiciels Administrateur Ajouter un Progiciels 11
Gérer les Progiciels Administrateur Modifier un Progiciels 11
20
Gérer Services Administrateur Supprime un Progiciels 12
Gérer les Services Administrateur Consulter des Services 12
Gérer les Services Administrateur Ajouter un Services 12
Gérer les Services Administrateur Modifier un Services 12
Gérer les Services Administrateur Supprimer un Services 12
Gérer les Prestataire Abonner 13

abonnements
Gérer les Prestataire Afficher mes abonnements 13

« Statistique, gestion des abonnées»
abonnements
Gérer les Administrateur Modifier la date d’expiration d’un 14

abonnements abonnement
Gérer les Administrateur Activer ou désactiver un 14

abonnements abonnement
Statistique Administrateur Afficher la liste des statistiques 15

qui peuvent être affichés dans le
Dashboard
21
Statistique Administrateur Cacher ou afficher une statistique 15

dans le Dashboard
Table 3:Backlog du produit
II.2.3 Planification de Release
Un plan de très haut niveau pour plusieurs sprints est créé pendant la planification de la
diffusion. C'est une ligne directrice qui reflète les attentes quant aux fonctionnalités qui
seront mises en œuvre et quand elles seront terminées. Il sert également de base pour
suivre les progrès au sein du projet. Les sorties peuvent être des livraisons intermédiaires
effectuées pendant le projet ou la livraison finale à la fin.
Pour créer un plan de diffusion, les éléments suivants doivent être disponibles:
 Un backlog de produits Scrum hiérarchisé et estimé
 La vitesse de l'équipe Scrum
 Conditions de satisfaction (objectifs pour l'emploi du temps, portée, ressources).
Dans notre cas, nous avons découpé notre projet en deux Release.
22
Figure 5: Schéma de Release
II.3 Environnement de travail

Dans cette partie, nous présenterons l'environnement matériel et technique relatif à la
réalisation de l'application.
23
II.3.1 Environnement matériel
L'architecture matérielle utilisée pour la réalisation de l'application est la suivante :

PC portable USUS X556U
RAM 8 Go
Microprocesseur Intel® Core™ i7-6500U CPU@2.50Hz
Disque dur 1 To
Système d’exploitation Windows 10
Table 4:Environnement matériel
II.3.2 Environnement Logiciel
II.3.2.1 Outils de développement et modélisation :
Visual code studio :

Pour le développement front-end, nous avons utilisé un nouvel éditeur développé
récemment par Microsoft : c’est Visual code studio.
Cet éditeur a gagné une très bonne satisfaction au sein de développeur front-end, c’est un
outil open source qui facilite le développement avec la nouvelle version de JavaScript
appelée TypeScript.
StarUML :
Est un logiciel Open Source de modélisation Uml, développé en Delphi.
24
Il est modulaire et propose plusieurs générateurs de code.

Il propose également plusieurs nouveaux Template de projets. [N2]
II.3.2.2 Plateforme de développement :
Plate-forme cloud : AWS

Amazon Web Services, ou AWS, est une plate-forme de cloud computing d'Amazon qui
fournit aux clients une large gamme de services cloud. Parmi les options de cloud offertes
par Amazon AWS figurent Amazon Elastic Compute Cloud (Amazon EC2), Amazon
Simple Storage Service (Amazon S3), Amazon Private Cloud (Amazon VPC), Amazon
SimpleDB et Amazon WorkSpaces.
Amazon a d'abord lancé ses Amazon Web Services en 2006 afin de permettre l'utilisation
de services en ligne par des applications côté client ou d'autres sites Web via des
protocoles HTTP, REST ou SOAP. Amazon facture les clients pour Amazon AWS en
fonction de leur utilisation des divers services Web Amazon.
En 2012, Amazon a lancé AWS Marketplace pour héberger et développer l'écosystème
émergent des offres AWS provenant de fournisseurs tiers ayant construit leurs propres
solutions sur la plate-forme Amazon Web Services. AWS Marketplace est un magasin en
ligne permettant aux clients Amazon Web Services de rechercher, de comparer et de
commencer à utiliser les logiciels et services techniques AWS
Donc pour mettre l'application en valeur, plus développer et répond aux besoins du marché
nous implémentons les web services suivants :
25
 Amazon S3 : est un stockage d'objets conçu pour stocker et récupérer n'importe

quelle quantité de données, n'importe où : sites web, applications mobiles,
applications d'entreprise et données de capteurs ou d'appareils IoT. [B14]
 Amazon CloudWatch : est un service de surveillance pour les ressources du

cloud AWS et les applications que vous exécutez sur AWS. utiliser pour collecter
et suivre des métriques, regrouper et contrôler des fichiers journaux, régler des
alarmes et réagir automatiquement aux modifications apportées. [B15]
 Amazon Lambda : est un service de calcul sans serveur qui exécute le code en
réponse à des événements et gère automatiquement les ressources de calcul sous-
jacentes. [B16]
 Amazon Identity and Access Management (IAM) : permet de contrôler de

façon sécurisée l'accès aux services et ressources AWS. Avec IAM, vous pouvez
créer et gérer des utilisateurs ainsi que des groupes AWS, et configurer des
autorisations afin de leur permettre ou non d'accéder aux ressources AWS. [B17]
26
 Amazon Relational Database Service (RDS) : configurez, gérez et

dimensionnez facilement une base de données relationnelle dans le cloud. Ce
service offre une capacité économique et ajustable ainsi qu'une automatisation
des tâches administratives chronophages, telles que l'allocation de matériel, le
paramétrage de bases de données, l'application de correctifs et les sauvegardes.
[B18]
II.3.2.3 Langages de programmation :
TypeScript :
C’est un langage de programmation libre et open source développé par Microsoft qui a
pour but d'améliorer et de sécuriser la production de code JavaScript. C'est un sur-
ensemble de JavaScript (c'est-à-dire que tout code JavaScript correct peut être utilisé avec
TypeScript). Le code TypeScript est transcompilé en JavaScript, pouvant ainsi être
interprété par n'importe quel navigateur web ou moteur JavaScript.
JavaScript :
C'est un langage de programmation qui est inclus dans le code HTML. Il permet d'apporter
des améliorations au langage HTML en permettant d'exécuter des commandes.
Mais dans notre projet en travaille par un outil de Java Script appelle TypeScript
Type script est un langage de programmation libre et open source développée par
Microsoft qui a pour but d'améliorer et de sécuriser la production de code JavaScript. [B5]
27
HTML5 :
« Hyper Text Markup Langage 5 » considéré comme l’une des nouvelles
Technologies les plus importantes, qui étaient émergées en 2010, et qui sont encore un
travail ne sont pas totalement finalisées par le W3C. [B12]
Elle est un langage de balisage conçu pour la création des pages Web.
CSS3 :
« Cascading Style Sheets » permet d’arrondir les images, faire des ombres sur les divas,
des ombres sur du texte, des polices de caractères plus fun, des bordures d’images, etc. Et
surtout l’ajout de l’animation.
Il utilisait pour la description des styles et la disposition des éléments des pages HTML
[B13].
28
II.3.2.4 Framework utilisé
Angular5 :
Un Framework de développement, utilisé notamment par Gmail et Google +. Il permet de
faire des interfaces plus réactives et « one page », c’est-à-dire sans rechargement de la
page.
La meilleure solution technique qui présente un vrai gain de productivité pour le
développement d’applications web ergonomiques. [B3]
Bootstrap :
C'est le Framework HTML, CSS et JS le plus populaire pour le développement des sites
Web mobile et responsive.
Serverless :
Le Framework Serverless est un outil CLI qui permet aux utilisateurs de créer et de
déployer des fonctions auto-scaling, pay-per-execution et événementielles.
Écrivez votre code, configurez les événements pour déclencher vos fonctions, puis
déployez et exécutez ces fonctions sur votre fournisseur de cloud via l'interface CLI
Serverless.
29
II.4 Architecture
II.4.1 Architecture du système
Notre solution utilise l’architecture opérationnelle trois tiers. Comme illustrée dans la
figure ci-après, la solution que nous avons choisie obéit à la même structure laissant
apparaitre les tiers suivants :
 Un client léger qui n’est autre qu’un navigateur web permettant

à son utilisateur d’accéder à l’application via internet.
 Un middle tiers : le serveur d’application qui héberge toutes les

couches de l’application.
 Un tiers de données qui n’est autre que le serveur de base de

données.
Figure 6:Architecture de système
II.4.2 Architecture n-Tiers
L’architecture.N-tier, ou aussi.encore.appelée.multi-tier, est une architecture.client-

serveur.dans la quelle une.application.est exécutée par plusieurs composants logiciels
distincts. [B19]
30
Figure 7:Architecture n-Tiers
II.4.3 Architecture de l’application
Dans cette section, on commence par la présentation de l'architecture MVC que nous avons
choisi pour réaliser notre application.
Bien évidemment, le choix de l’architecture adéquate dans la phase de conception de toute
application est primordial, afin de garantir un fonctionnement correct, une meilleure
performance et une maintenance facile.
Dans cette logique nous avons opté pour l'architecture MVC.
Figure 8:Architecture de l’application : MVC
31
L’application place de marché IT est basée sur le concept MVC qui signifie Modèle, vue et
contrôleur pour mieux organiser le code de notre système.
Cette architecture, comme dans l’illustration en haut, se sépare sur trois couches : entités
de données, interface et traitement de données.
Le modèle représente les données de l'application stockées dans une base de données.
La vue correspond à l'IHM (Interface Homme Machine).
Le contrôleur assure les échanges entre la vue et le modèle.
Le rôle du contrôleur est d’orchestrer la procédure entre une vue et un modèle. Il analyse
la requête envoyée par un client de notre site, effectue les contrôles nécessaires afin
d'appeler le modèle convenable.
Ce dernier réalise les différentes requêtes MYSQL afin de récupérer les données en
question.
Ce modèle passe les données récupérées au contrôleur pour qu'il puisse les retourner à la
vue concernée.
Finalement, la vue affichera les interfaces demandées par l'utilisateur de notre application.
Conclusion
Dans ce chapitre, on a planifié notre travail, identifié les besoins fonctionnels et non
fonctionnels de notre application, les rôles des utilisateurs, par la suite on a présenté le Backlog
de notre système. Ainsi on a détaillé la phase de planification des sprints. Enfin on a choisi
l’architecture de notre projet ainsi que notre environnement de travail.
32
CHAPITRE III Release 1 « Authentification et gestion de profil »
Chapitre III. Release 1
33
CHAPITRE III Release 1
Introduction
Dans ce chapitre, nous allons détailler le travail réalisé durant le premier release. En effet,
chaque release, qui est l’ensemble d’itérations (sprint), représente une vision distribuée de
la période de la production du livrable. Ce premier Release comprend deux sprints :
 Sprint1 « Authentification, Inscription et Gestion de profil »
 Sprint 2 « Gestion des abonnées et des prestataires »
Le développement de chaque sprint passe par les étapes d’analyse, de conception et de
réalisation.
III.1 Développement du Sprint1 « Authentification, Inscription

et Gestion de profil »
Ce premier sprint s’étale sur 18 jours et se décompose en trois items
 S’inscrire
 S’authentifier
 Gérer profil
Figure 9: Décomposition sprint 1 en Items
34
ID U.S User Story

1.1 En tant qu’utilisateur, je dois m’authentifier pour accéder à mon espace
1.2 En tant qu’utilisateur, je peux m’inscrire
2.1 En tant qu’utilisateur je peux uploader une image de profil
2.2 En tant qu’utilisateur je peux afficher mon profil
2.3 En tant qu’utilisateur je peux modifier mon profil
2.4 En tant qu’utilisateur je peux désactiver mon profil
Table 5:les user stories de sprint 1
Le backlog du sprint1 est le suivant :
Item User Story Description Priorité
S’inscrire S’inscrire En tant qu’utilisateur, je peux m’inscrire 1

S’authentifier S’authentifier En tant qu’utilisateur, je dois m’authentifier 2
pour accéder à mon espace
Gérer profil Consulter En tant qu’utilisateur je peux consulter mon 3
profil profil
Modifier profil En tant qu’utilisateur je peux modifier mon
profil
Modifier En tant qu’utilisateur je peux uploader modifier
image de une image de profil
profil
Désactiver En tant qu’utilisateur je peux désactiver mon
profil profil
Table 6: Backlog du sprint 1
35
III.1.1 Analyse
Diagramme de cas d’utilisation
Figure 10: Diagramme de cas d’utilisation du sprint1
III.1.1.1 Description de l’item « S’inscrire »
A. Diagramme de cas d’utilisation « S’inscrire »
Figure 11: Diagramme de cas d’utilisation du « S’inscrire »
36
B. Description textuelle du cas d’utilisation « S’inscrire »

Cas d’utilisation S’inscrire
Acteur Internaute
Précondition Utilisateur non inscrit
Post-condition Utilisateur inscrit
Scénario principal 1. L’utilisateur remplit le formulaire.

2. L’utilisateur clique sur Bouton
«S’inscrire ».
3. Le système enregistre la demande et
affiche le message « Merci, votre
demande sera traitée ».
Scénario alternatif Le système affiche un message d’erreur «
Vérifiez votre saisie ».
Table 7: Description textuelle du cas d’utilisation « S’inscrire »
III.1.1.2 Description de l’item « S’authentifier »
A. Diagramme de cas d’utilisation
Figure 12:Diagramme de cas d’utilisation « S’authentifier»
37
B. Description textuelle du cas d’utilisation « S’authentifier »

La description détaillée de l’user story 1 « s’authentifier » est donnée par le tableau
suivant :
Cas d’utilisation S’authentifier

Acteur Utilisateur du système
Préconditions l’utilisateur doit être activé.
Post-condition Utilisateur Authentifié
Scénario Nominal 1. L’utilisateur saisit son login et son mot
de passe
2. L’utilisateur confirme la saisie de ses
données d’identification
3. Le système vérifie les données
d’identification
4. Le système affiche l’interface d’accueil
l’utilisateur.
Scénario D’exception E1. Si le login et/ou le mot de passe sont
incorrects
L’enchaînement démarre au point 3. Le
système affiche un message d’erreur
informant l’utilisateur que son login ou
mot de passe sont incorrects et le scénario
reprend à l’action1.
Table 8: Description textuelle du cas d’utilisation « S’authentifier »
38
III.1.1.3 Description de l’item « Gérer profil »
A. Raffinement du cas d’utilisation « Gérer profil »

La figure suivante présente le raffinement de l’item « Gérer profil » par prestataire.
Figure 13:Diagramme de cas d’utilisation « Gérer profil »
B. Descriptions textuelles des cas d’utilisation de l’item «Gérer profil »
Cas d’utilisation Modifier profil

Acteur Utilisateur
Pré conditions L’utilisateur doit être authentifié
Scénario nominal 1. L’utilisateur demande la page
« Paramètre ».
2. Le système affiche les informations de
l’utilisateur.
3. L’utilisateur modifie les informations
39
qu’il veut changer il peut aussi

modifier son image
4. L’utilisateur clique sur le bouton
« modifier ».
5. L’utilisateur modifie ses informations
et clique sur le bouton « Terminer »
6. le système vérifie les données saisies
7. Le système enregistre les modifications
effectuées.
8. Le système notifié l’utilisateur
Post-condition Profil modifié.
Table 9: Description textuelle du cas d’utilisation « Modifier profil »
III.1.2 Conception
III.1.2.1 Diagrammes de séquence
III.1.2.1.1 Diagramme de séquences « Modifier Profil »
40
Figure 14:Diagrammes de séquence User story 1.3 « Modifier Profil »
III.1.2.2 Diagrammes de classes
Dans la figure suivante nous présentons les classes associées à ce sprint.
41
Figure 15:Diagramme de classes du sprint 1
III.1.2.3 Schéma relationnel

La base de données relationnelle est une base de donnés comprenant des relations
dynamiques entre les différents objets contenus dans les tables :
Utilisateur (id_utilisateur, login, motpass, role)
Prestataire (#id_utilisateur, nom, prenom, email, registre, tél, raison_sociale, abonné,
pays, is_active, is_delete, site_web, fax, ville, Capital)
Administrateur (#id_utilisateur)
42
III.1.3 Réalisation
III.1.3.1 Architecture logique
Figure 16:Diagramme de composants « S’authentifier »
III.1.3.2 Description des interfaces utilisateurs
Nous présentons dans ce qui suit quelques interfaces représentant le travail élaboré dans ce
sprint.
43
L’accès à la page principale du site s’effectue sans authentification. C’est la première

interface de notre plateforme qui contient une bande de publicité, quelques appels d’offres,
la liste des prestataires et la liste des abonnés.
Figure 17:Page d'accueil 1
Pour se connecter, l’utilisateur saisit son login et mot de passe et coche son statut soit
prestataire ou administrateur.
Figure 18:Interface de connexion
44
Un nouveau utilisateur doit créer un compte, pour s’inscrire il remplit le formulaire et

choisit un mot de passe.
Après l'inscription le nouveau prestataire attend la validation de l’administrateur,
Figure 19:Interface d'inscription
D’après son login et mot de passe, le système contrôle le statut de l’utilisateur,

administrateur ou prestataire.
Front office :
La page principale du prestataire connecté sur notre plateforme
Figure 20:Page d'accueil
45
Back office :
Mais pour l’administrateur il y a une autre interface pour gérer les prestataires, les appels
d’offres, les infrastructures, les progiciels, les services et les abonnements.
Figure 21:Interface de Dashboard
Par l’utilisateur connecté à l’accès d’afficher son profil et ses appels offres
Figure 22:Consultation de profil
46
L'utilisateur peut modifier son profil par un simple clic sur le bouton "Modifier" qui permet
d’afficher le formulaire pour changer son information et sa photo
Figure 23:Modifier photo
Figure 24:Modification de profil
47
III.2 Développement du Sprint 2 « gestion des abonnées et des

prestataires»
Ce deuxième sprint s’étale sur 18 jours et se décompose en deux items
 Gérer prestataires
 Gérer types d’abonnements
ID U.S User Story
4.1 En tant qu’administrateur je peux afficher les prestataires
4.2 En tant qu’administrateur je peux valider ou refuser une demande d’inscription

d’un prestataire
4.3 En tant qu’administrateur je peux rechercher un prestataire
4.4 En tant qu’administrateur je peux activer ou désactiver un prestataire
4.5 En tant qu’administrateur je peux supprimer un prestataire
5.1 En tant que prestataire je peux consulter la liste des prestataires.
48
5.2 En tant que prestataire je peux rechercher un prestataire
6.1 En tant qu’un prestataire je peux Choisir l’abonnement
6.2 En tant qu’un prestataire je peux abonner
7.1 En tant qu’un administrateur je peux afficher la liste des types d’abonnement
7.2 En tant qu’un administrateur je peux ajouter un type d’abonnement
7.3 En tant qu’un administrateur je peux modifier un type d’abonnement
7.4 En tant qu’un administrateur je peux supprimer un type d’abonnement
Le backlog du sprint 2 est le suivant :

Gérer Afficher les En tant qu’administrateur je peux afficher 4

prestataires prestataires les prestataires
Valider prestataire En tant qu’administrateur je peux valider 4
ou refuser une demande d’inscription
d’un prestataire
Rechercher En tant qu’administrateur je peux 4
prestataire rechercher un prestataire
Active prestataire En tant qu’administrateur je peux activer 4
ou désactiver un prestataire
Supprimer En tant qu’administrateur je peux 4
prestataire supprimer un prestataire
Consulter la liste En tant que prestataire je peux consulter 5
des prestataires la liste des prestataires.
Rechercher un En tant que prestataire je peux rechercher 5
prestataire un prestataire
Gérer types Choisir En tant qu’un prestataire je peux Choisir 6
d’abonnements l’abonnement l’abonnement
Afficher la liste En tant qu’un administrateur je peux 7
des types afficher la liste des types d’abonnement
d’abonnement
Ajouter un type En tant qu’un administrateur je peux 7
d’abonnement ajouter un type d’abonnement
Modifier un type En tant qu’un administrateur je peux 7
d’abonnement modifier un type d’abonnement
49
Supprimer un type En tant qu’un administrateur je peux 7

d’abonnement supprimer un type d’abonnement
III.2.1 Analyse
Diagramme de cas d’utilisation global
Figure 26: Diagramme de cas d’utilisation du sprint 2
III.2.1.1 Descriptions de l’item «Gérer prestataires »
A. Raffinement du cas d’utilisation « Gérer prestataire »
La figure suivante présente le raffinement de l’item « Gérer des prestataires » par

l’administrateur.
50
Figure 27:Diagramme de cas « Gérer des prestataires »
B. Descriptions textuelles des cas d’utilisation de l’item « Gérer prestataire »
Cas d’utilisation Valider prestataire

Acteurs L’administrateur
Pré conditions L’administrateur doit être authentifié
Il y a des nouveaux utilisateurs inscrits
Scénario Principal 1. l’administrateur demande la consultation
de la liste des nouveaux utilisateurs.
2. le système affiche la liste.
3. l’administrateur parcoure la liste des
nouveaux comptes et au-dessous de chaque
compte il y a deux buttons (valider ou
refuser).
4. le système offre la possibilité de valider
ou refuser un compte.
5. L’administrateur clique sur le bouton
« Valider ».
6. Le système enregistre l’opération.
51
Exceptions
Post conditions de succès Prestataire Validé ou refusé
Post conditions d’échec Message erreur
Table 12:Description textuelle du cas d’utilisation « Valider prestataire»
La description détaillée de l’user story 4.4 « Activer prestataire » est donnée par le tableau
suivant :
Cas d’utilisation Activer prestataire
Scénario Principal 1. l’administration demande la consultation
de liste des prestataires.
2. le système affiche la liste des utilisateurs.
3. l’administrateur parcoure la liste ou lance
une recherche.
4. pour chaque prestataire il y a un « slide-
toggle » pour activer ou désactiver le
compte.
5. le système enregistre l’opération.
Exceptions
Post conditions de succès Prestataire activé ou désactivé.
Post conditions d’échec
Table 13: Description textuelle du cas d’utilisation « Activer prestataire»
La description détaillée de l’user story 4.5 « Supprimer prestataire » est donnée par le
tableau suivant :
Cas d’utilisation Supprimer prestataire

52

Scénario Principal 1. l’administration demande la consultation
de liste des prestataires.
2. le système affiche la liste des utilisateurs.
3. l’administrateur parcoure la liste ou lance
une recherche.
4. l’administrateur clique sur une icône de
suppression un compte de chaque
prestataire.
5. le système affiche un message de
confirmation à l’administrateur pour valider
son choix.
6. le système exécute l’opération.
Exceptions
Post conditions de succès Prestataire supprime de la base de données.
Table 14: Description textuelle du cas d’utilisation « Supprimer prestataire»
III.2.1.2 Description de l’item « Gérer les types d’abonnements »
A. Raffinement du cas d’utilisation « Gérer les types d’abonnements »

Le raffinement de l’item « Gérer les types d’abonnements » est présenté par la figure
suivante
53
Figure 28:Diagramme de cas « Gérer les types des abonnements »
B. Descriptions textuelles des cas d’utilisation de l’item « Gérer les types des
abonnements»
La description détaillée de l’user story 7.4 « Supprimer un type d’abonnement » est donnée
par le tableau suivant :
Cas d’utilisation Supprimer un type d’abonnement

1. L’administrateur demande la page
« Types d’abonnements ».
2. le système affiche les types
Scénario Principal d’abonnements
« supprimer ».
4. le système demande la confirmation pour
terminer la suppression
5. L’administrateur clique sur valider.
6. le système notifie l’utilisateur
Exceptions
54
Post conditions de succès Type d’abonnement supprimé.

Table 15: Description textuelle du cas d’utilisation « Supprimer un type

d’abonnement»
La description détaillée de l’user story 7.2 « Ajouter un type d’abonnement » est

donnée par le tableau suivant :
Cas d’utilisation Ajouter un type d’abonnement

1. L’administrateur demande la page
« Types d’abonnements ».
2. le système affiche les types
Scénario Principal d’abonnements
3. L’administrateur cliqué sur le bouton
« ajouter ».
4. L’administrateur remplit le formulaire et
clique sur « terminer »
5. le système notifie l’utilisateur
Exceptions
Post conditions de succès Type d’abonnement ajouté.
Post conditions d’échec Les données saisies ne sont pas valides,
message d’erreur affiché à l’utilisateur.
Table 16: Description textuelle du cas d’utilisation «Ajouter un type d’abonnement »
55
III.2.1.3 Diagramme de séquence
III.2.1.3.1 Diagrammes de séquences « Valider des prestataires »
Figure 29:Diagrammes de séquences User story 4.2 « Valider des prestataires »
56
III.2.1.3.2 Diagrammes de séquences « Modifier type d’abonnement »
Figure 30: Diagrammes de séquences User story 7.3 « Modifier type d’abonnement »
57
III.2.1.4 Diagramme de classe
Figure 31:Diagramme de class de sprint 2
III.2.1.5 Schéma Relationnel
La base de données relationnelle est une base de donnés comprenant des relations
dynamiques entre les différents objets contenus dans les tables :
Utilisateur (id_utilisateur, login, motpass)
Administrateur (#id_utilisateur, nom)
Type_abonnement (id_type_abonnement, nom, prix)
Abonnement (id_abonnement, #id_utilisateur, #id_type_abonnement, date_debut,
date_fin)
58
III.2.2 Réalisation
III.2.2.1 Description des interfaces
Nous allons consacrer cette partie pour la présentation de quelques interfaces élaborées
dans ce sprint.
Front office :
Sur cette partie on va voir sur notre plateforme le menu de Prestataires qui contient la liste
des prestataires et la liste des abonnés.
Figure 32:Menu de Prestataires
On voit exemple "liste des prestataires" qui permet d’afficher les prestataires trier par
l’activation et le nombre des appels d’offre ajoutes et postules.
59
Figure 33: liste des prestataires
Back office :
En tant qu’administrateur, il permet de valider ou refuser les nouveaux prestataires pour
sécurise la plateforme
Figure 34: liste des prestataires non validés
60
Figure 35:Liste des prestataires
Le système affiche Message de confirmation pour la suppression d’utilisateur de notre

plateforme
Figure 36:Message de confirmation pour supprimer un prestataire
En tant qu’administrateur, il permet de consulter la liste des abonnements sur notre

plateforme ainsi il permet de modifier ou supprimer les abonnements.
61
Figure 37:liste type des abonnements
III.3 Conclusion :
Dans ce chapitre, on a réussi à produire un incrément de valeur pour le client et utile dans
un environnement de production.
Et on a effectué la conception et la réalisation du module de sprint 1 et sprint 2.
Le release a été présenté dans le cadre d'une réunion de fin de release et préparation au
prochain. Cette réunion était à la présence de l'équipe du projet et quelques chefs de projets
de la société Cynapsys.
Dans le chapitre qui suit, nous allons produire un nouveau release couvrant les
fonctionnalités suivantes : Gestion des appels d’offre, des infrastructures, des progiciels,
des services et statistique.
62
CHAPITRE IV Release 2
Chapitre IV. Release2
63
Introduction
Dans ce chapitre, nous allons détailler le travail réalisé durant le deuxième release. Tout
d’abord, un release, qui est l’ensemble de sprint (itérations), représente une vision
distribuée de la période de la production du livrable. Ce deuxième Release comprend deux
sprints :
 Sprint1 « gestion des appels d’offre, des infrastructures, des progiciels, des
services»
 Sprint 2 «gestion des abonnées et statistique »
Le développement de chaque sprint passe par les étapes d’analyse, de conception et de
réalisation.
IV.1 Développement du Sprint1 « Gestion des appels d’offre,

des infrastructures, des progiciels, des services»
Ce premier sprint s’étale sur 23 jours et se décompose en quatre items :
 Gérer les appels d’offres
 Gérer les infrastructures
 Gérer les progiciels
 Gérer des services
64
ID User Story
U.S
8.1 En tant qu’administrateur je peux afficher les appels d’offres
8.2 En tant qu’administrateur je peux chercher un appel d’offre
8.3 En tant qu’administrateur je peux valider ou refuser une demande d’ajout d’un
appel d’offre.
8.4 En tant qu’administrateur je peux Consulter la liste des appels d’offres pour activer
ou désactiver un appel d’offre
9.1 En tant que prestataire je peux consulter la liste des appels d’offres.
9.2 En tant que prestataire je peux rechercher un appel d’offre.
9.3 En tant que prestataire je peux consulter la liste mes appels d’offres validées
9.4 En tant que prestataire je peux consulter en détails et télécharger un cahier de

charge d’un appel d’offre.
65
9.5 En tant que prestataire je peux Remplir un formulaire pour ajouter un appel d’offre
avec son cahier de charge.
9.6 En tant que prestataire je peux postuler à un appel d’offre en uploadant les fichiers
nécessaires.
10.1 En tant qu’un administrateur je peux consulter des infrastructures
10.2 En tant qu’un administrateur je peux ajouter une infrastructure
10.3 En tant qu’un administrateur je peux modifier une infrastructure
10.4 En tant qu’un administrateur je peux supprimer une infrastructure
11.1 En tant qu’un administrateur je peux consulter la liste des progiciels
11.2 En tant qu’un administrateur je peux ajouter un progiciel
11.3 En tant qu’un administrateur je peux modifier un progiciel
11.4 En tant qu’un administrateur je peux supprimer un progiciel
12.1 En tant qu’un administrateur je peux consulter la liste des services
12.2 En tant qu’un administrateur je peux ajouter un service
12.3 En tant qu’un administrateur je peux modifier un service
12.4 En tant qu’un administrateur je peux supprimer un service
Le backlog du sprint1 est le suivant :
Gérer les Afficher les En tant qu’administrateur je peux afficher les 8

appels d’offres appels d’offres
appels d’offres
Chercher un En tant qu’administrateur je peux chercher un
appel d’offre
appel d’offre
Valider l’appel En tant qu’administrateur je peux valider ou
d’offre
66
refuser une demande d’ajout d’un appel d’offre.

Activer l’appel En tant qu’administrateur je peux Consulter la
d’offre liste des appels d’offres pour activer ou désactiver
un appel d’offre
Gérer les Consulter la En tant que prestataire je peux consulter la liste 9
appels d’offres liste des appels
des appels d’offres.
d’offres.
Rechercher un En tant que prestataire je peux rechercher un appel
appel
d’offre.
Consulter la En tant que prestataire je peux consulter la liste
liste mes
mes appels d’offres validées
appels d’offres
validées
Consulter en En tant que prestataire je peux consulter en détails
détails l’appel
l’appel d’offre et télécharger un cahier de charge
d’offre
d’un appel d’offre.
Ajouter appel En tant que prestataire je peux Remplir un
d’offre
formulaire pour ajouter un appel d’offre avec son
cahier de charge.
Postuler à un En tant que prestataire je peux postuler à un appel
appel d’offre d’offre en uploadant les fichiers nécessaires.
Gérer les Consulter En tant qu’un administrateur je peux consulter 10
infrastructures infrastructure infrastructure
Ajouter En tant qu’un administrateur je peux ajouter
infrastructure infrastructure
Modifier En tant qu’un administrateur je peux modifier
infrastructure infrastructure
Supprimer En tant qu’un administrateur je peux supprimer
progiciel infrastructure
Gérer les Consulter En tant qu’un administrateur je peux consulter la 11
progiciels progiciels liste de progiciel
progiciel progiciel
Modifier En tant qu’un administrateur je peux modifier
progiciel progiciel
progiciel progiciel
67
Consulter En tant qu’un administrateur je peux consulter

services service
Gérer les services service 12
services Modifier En tant qu’un administrateur je peux modifier
services service
services service
IV.1.1 Analyse
IV.1.1.1 Diagramme de cas d’utilisation du sprint1
Figure 39: Diagramme de cas d’utilisation du sprint1
IV.1.1.2 Description de l’item « Gérer les appels d’offre »
A. Raffinement du cas d’utilisation «Gérer les appels d’offre » par le prestataire
68
Figure 40:Diagramme de cas d’utilisation « Gérer les appels d’offre » par prestataire
B. Descriptions textuelles des cas d’utilisation de l’item «Gérer les appels d’offre»
par le prestataire
Cas d’utilisation Ajouter un appel d’offre.

Acteurs Le prestataire
Pré conditions Le prestataire doit être s’authentifié
Scénario Principal 1. Le prestataire clique sur le bouton
« ajouter un appel d’offre ».
2. Le système affiche le formulaire qui
permet de créer un appel d’offre.
3. Le prestataire saisi les coordonnées
relatives de l’appel d’offre et faire le
téléchargement du cahier charge sur le site.
4. le système vérifie la demande.
5. le système affiche l’appel d’offre sur
l’interface de l’administrateur pour valider
69
ou refuser.
Exceptions
Post conditions de succès Appel d’offre validée
Post conditions d’échec Les données saisies ne sont pas valides,
message d’erreur affiché à le prestataire.
Table 19: Description textuelle du cas d’utilisation « Ajouter appel d’offre»
Cas d’utilisation Postuler appel d’offre

Acteurs Le prestataire
Pré conditions Le prestataire doit être authentifié
Scénario Principal 1. Le prestataire demande la consultation de

la liste des appels d’offre.
2. Le système affiche la liste des appels
d’offre.
3. Le prestataire parcoure la liste des appels
d’offre (où lance une recherche).
4. Le prestataire cliqué sur le bouton «
détail » au-dessous de chaque prestataire.
5. Le système affiche fiche descriptive
complète et se finit par un bouton Répondre
à l’appel d’offre.
6. Après la vue de la fiche descriptive si
aime l’appel d’offre alors l’utilisateur
clique sur lien « Télécharger le cahier des
charges » et le bouton « Postuler »
7. le système affiche interface de postuler
pour uploader les fichiers nécessaires.
8. le système envoie un message de
70
postulation au prestataire qui ajoute cet

appel.
Exceptions
Post conditions de succès Message de confirmation
Table 20: Description textuelle du cas d’utilisation « Postuler appel d’offre»
C. Raffinement du cas d’utilisation «Gérer les appels d’offre » par

l’administrateur
Figure 41: Diagramme de cas d’utilisation « Gérer les appels d’offre » par
l’administrateur
D. Descriptions textuelles des cas d’utilisation de l’item «Gérer les appels d’offre»
par l’administrateur
Cas d’utilisation Valider appel d’offre

Il y a des nouveaux Appels d’offre ajoutes.
Scénario Principal 1. L’administrateur demande la consultation
de la liste des nouveaux appels d’offre.
71
2. Le système affiche la liste.

3. L’administrateur parcoure la liste des
nouveaux appels d’offre et au-dessous de
chaque appel d’offre il y a deux boutons
(valider ou refuser).
4. Le système offre la possibilité de valider
ou refuser un appel d’offre.
(valider ou activer).
6. Le système enregistre l’opération.
Exceptions
Post conditions de succès Appel d’offre validé ou refusé
Table 21: Description textuelle du cas d’utilisation « Postuler appel d’offre»
IV.1.2 Conception
IV.1.2.1 Diagramme de séquence
IV.1.2.1.1 Diagramme de séquences « Valider les appels d’offres »
72
Figure 42:Diagrammes de séquences User story 8.3 « Valider les appels d’offres »
IV.1.2.1.1 Diagramme de séquences « Modifier Infrastructure »
73
Figure 43:Diagrammes de séquences User story 10.3 « Modifier Infrastructure »
74
IV.1.2.2 Diagramme de classe
Figure 44 :Diagramme de class de sprint 1
75
IV.1.2.3 Schéma Relationnel
Utilisateur (id_utilisateur, login, motpass, role)

Infrastructures (id_Infrastructures, nom)
Pogiciels (id_progiciels, nom)
Services (id_services, nom)
Appel d'offre (id_appel, #id_Infrastructures, #id_progiciels, # id_services, #id_utilisateur,
description, fonction, effectif, titre, date_de_dépôt, date_de_fin, nom_responsable,
prenom_responsable, is_active, is_deleted)
IV.1.3 Réalisation
IV.1.3.1 Description des interfaces
Nous présentons dans ce qui suit quelques interfaces du travail réalisé dans ce sprint
Front office :
En tant qu’utilisateur, il permet de gère les appels d’offre à partir de l’ajout et postulation
des appels d’offre
Figure 45:Menu des appels d'offres
76
Pour ajouter un appel d'offre, l'utilisateur doit remplir le formulaire par saisir le titre, la
description et la date de début et la date de fin du projet.
Figure 46:Formulaire pour ajouter appel d'offre
En tant qu’utilisateur, il permet de rechercher, consulter la liste des appels d’offre.
Figure 47:Consulter les appels d'offres
77
En cliquant sur le bouton «Détails » pour afficher les détails d’appel d’offre, parmi les
détails on peut voir la description de cahier des charges par « Télécharger le cahier des
charges ».
Figure 48: détails appel d’offre
Back office :
Dans la figure comme la validation des nouveaux prestataires, l’administrateur permet de
valider ou refuser les appels d’offres
78
Figure 49:Liste des appels d'offres à valider
Comme il permet de consulter la liste des appels d’offre
Figure 50:Consulter les appels d'offres
Pour plus de détail, il faut de sélectionner à un appel d’offre, le système affiche l’affiche
descriptive complet de l’appel d’offre
79
Figure 51:Consulter en détails un appel d'offre
En tant qu’administrateur, il permet de consulter la liste des infrastructures sur notre

plateforme ainsi il permet de modifier ou d’ajouter les infrastructures.
Figure 52:liste type des abonnements
Même chose pour les Progiciels et les Services
IV.2 Développement du Sprint 2 « gestion des abonnées et

statistique »
Ce deuxième sprint s’étale sur 21 jours et se décompose en deux items :
 Statistique
 Gérer les abonnées
80
ID U.S User Story
13.1 En tant qu’un prestataire je peux abonner à la plateforme.
13.2 En tant qu’un prestataire je peux afficher mes abonnements.
14.1 En tant qu’administrateur je peux modifier la date d’expiration d’un abonnement.
14.2 En tant qu’un administrateur je peux activer ou désactiver un abonnement.
15.1 En tant qu’administrateur je peux afficher la liste des statistiques qui peuvent être
affichés dans le Dashboard.
15.2 En tant qu’administrateur je peux cacher ou afficher une statistique dans le
Dashboard
Table 22: les user stories de sprint 2
Gérer les Abonner En tant qu’un prestataire je peux abonner 13

abonnées à la plateforme.
Afficher mes En tant qu’un prestataire je peux afficher
abonnements. mes abonnements.
Modifier la date En tant qu’administrateur je peux 14
d’abonnement modifier la date d’expiration d’un
81
abonnement.
Activer En tant qu’un administrateur je peux
l’abonnement activer ou désactiver un abonnement.
Statistique Consulter les En tant qu’administrateur je peux afficher 15
statistiques la liste des statistiques qui peuvent être
affichés dans le Dashboard.
afficher ou cacher En tant qu’administrateur je peux cacher
une statistique ou afficher une statistique dans le
Dashboard
IV.2.1 Analyse
IV.2.1.1 Diagramme de cas d’utilisation du sprint 2
Figure 54: Diagramme de cas d’utilisation Sprint 2
IV.2.1.2 Description de l’item « Gérer les abonnements »
A. Raffinement du cas d’utilisation «Gérer les abonnements»
82
Figure 55: Diagramme de cas d’utilisation « Gérer les abonnements»
B. Descriptions textuelles des cas d’utilisation de l’item «Activer abonnement »
Cas d’utilisation Activer abonnement

L’existence des prestataires abonnés
de la liste des abonnements des prestataires.
abonnements et grâce à un Toggle switch à
coté de chaque abonnement, il choisit
d’activer ou désactiver un abonnement.
5. L’administrateur glisse le Toggle vers
activer ou désactiver.
6. Le système enregistre l’opération et
notifie l’administrateur.
Exceptions
Post conditions de succès Abonnement Activé ou Désactivé
83
Table 24: Description textuelle du cas d’utilisation « Activer abonnement»
La description détaillée de l’user story 8.2 «modifier la date d’expiration d’un

abonnement» est donnée par le tableau suivant :
Cas d’utilisation Modifier la date d’expiration d’un
abonnement
L’existence des prestataires abonnés
de la liste des abonnements des prestataires.
2. Le système affiche la liste.
abonnements et choisit l’abonnement à
modifier
5. L’administrateur clique sur l’icône
modifié.
6. Le système affiche un formulaire qui
contient la date de fin ancienne.
7. L’administrateur remplit par la date
souhaitée et clique sur valider.
8. le système notifie que la date est modifiée
Exceptions Nouvelle date inferieur à l’ancienne
Post conditions de succès Date modifié
Table 25: Description textuelle du cas d’utilisation « modifier la date d’expiration

d’un abonnement»
84
IV.2.1.3 Description de l’item « Gérer les statistique »
A. Raffinement du cas d’utilisation «Gérer les statistique»
Figure 56:La Diagramme de cas d’user story 12 " Gestion des statistique "
B. Descriptions textuelles des cas d’utilisation de l’item «Gérer les statistique »
Cas d’utilisation Cacher ou afficher une statistique dans le

Dashboard
Scénario Principal 1. l’administrateur demande la consultation
de la liste des statistiques.
3. l’administrateur parcoure la liste des
abonnements
4. L’administrateur coche les statistiques
qui il veut les voir dans le Dashboard
6. Le système enregistre l’opération et
85
notifie l’administrateur.
Exceptions
Post conditions de succès Statistique affiché ou caché dans le
Dashboard
Table 26:Description détaillée du user story 6.3
IV.2.1.4 Diagramme de séquence
IV.2.1.4.1 Diagrammes de séquences «Modifier la date d’expiration d’un

abonnement »
Figure 57: Diagrammes de séquences User story 14.1« Modifier la date d’expiration
d’un abonnement »
IV.2.1.4.2 Diagrammes de séquences «Abonnée »
86
Figure 58: Diagrammes de séquences User story 13.1 « Abonnée»
IV.2.1.4.3 Diagrammes de séquences « afficher la liste des statistiques »
Figure 59: Diagrammes de séquences User story 15.1« afficher la liste des
statistiques»
87
IV.2.1.5 Diagramme de classe
Figure 60:Diagramme de class
88
IV.2.1.6 Schéma Relationnel
Utilisateur (id_utilisateur, login, motpass,role)

Infrastructures (id_Infrastructures, nom)
Progiciels (id_progiciels, nom)
Services (id_services, nom)
Appel d'offre (id_appel, #id_Infrastructures, #id_progiciels, # id_services, #id_utilisateur,
description, fonction, effectif, titre, date_de_dépôt, date_de_fin, nom_responsable,
prenom_responsable, is_active, is_deleted)
Cahier de charge (id_CahierCharge,# id_appel, #id_utilisateur, nom,)
Type_abonnement (id_type_abonnement, nom, prix)
Abonnement (id_abonnement, #id_utilisateur, #id_type_abonnement, date_debut,
date_fin)
MSG (#id_utilisateur 1, #id_utilisateur 2, textem, date_mes)
Message (#id_prestataire, #id_administrateur, textem, date_mes)
Details_statistique (id_detailStatistique, #id_utilisateur,# id_statistique, etat)
89
IV.2.2 Réalisation
IV.2.2.1 Architecture physique
Figure 61: Diagramme de déploiement
IV.2.2.2 Description des interfaces
Front office :
Pour abonner à notre site, il faut de choisir un abonnement et faire le paiement.
Les types des abonnements sont quatre types à partir de la dure
90
Figure 62:Liste des abonnements
Figure 63: contacter l'administrateur
Back office :
En tant qu’administrateur, il permet de consulter des statistiques sur notre plateforme :
« Nombre de prestataires » « Nombre d’appels d’offre » « Nombre d’abonnements »
91
Figure 64: Statistiques
Figure 65: Statistiques :nombre des appels d’offre par mois
Figure 66: Statistiques : Bénéfices abonnement par mois
92
IV.3 Conclusion
A la fin de ce chapitre, nous avons réussi à produire un incrément répondant aux besoins
du client et étant utilisé dans un environnement de production. Nous clôturons ce rapport
par une conclusion général.
93
Conclusion générale
Le développement de notre projet intitulé « Conception et réalisation de détection et

gestion des appels d’offres » nous a permis de répondre aux besoins de notre client la
société Cynapsys.
Notre application web consiste à gérer les appels d’offres, les prestataires, les
infrastructures, les progiciels, le service et les abonnements.
La mise en place de cette application nous a permis de mettre en œuvre nos connaissances
théoriques acquises tout au long de notre formation à l’Université virtuelle de Tunis
« UVT ».
Ce travail nous a fourni également un grand apport au niveau de plusieurs niveaux. Sur le
plan technique, nous avons appris à manipuler le Framework Angular 5, les services
développés par Amazone web Service et pleins d’autres outils.
Nous avons également eu l’opportunité de maîtriser la conception en utilisant UML.
Le stage quotidien au sein de la société a aussi été pour nous une occasion unique qui nous
a apporté beaucoup d’enrichissement sur le plan relationnel.
Bien que les principaux objectifs de notre projet aient été atteints, le système que nous
avons développé pourrait être enrichi par d’autres fonctionnalités avancées et améliorations
selon des nouveaux besoins demandés par notre client.
Aussi, Vu le grand volume de données de la direction, une extension de ce travail pourra
avoir lieu via l’utilisation de l’informatique décisionnelle qui englobe les solutions IT et
qui leur apporte une nouvelle vision contenant des rapports et des tableaux de bord de suivi
des activités de l’entreprise à la fois analytiques et prospectifs.
94
Bibliographie
[B1] https://www.cynapsys.de/
[B2] https://www.agilecockpit.com/what-is-scrum/
[B3] https://angular.io/
[B5] https://www.youtube.com/ Mohamed Youssefi chaine
[B6] https://pixinvent.com/
[B7] https://getbootstrap.com/
[B8] https://material.angular.io/
[B9] https://github.com/
[B10] https://www.jhipster.tech/
[B11] https://www.primefaces.org/
[B12] https://weekiz.fr/html-5-la-revolution-sur-internet-367/
[B13] https://www.w3.org/Style/CSS
[B14] https://aws.amazon.com/fr/s3/
[B15] https://aws.amazon.com/fr/cloudwatch/
[B16] https://aws.amazon.com/fr/lambda/features/
[B17] https://aws.amazon.com/fr/iam/
[B18] https://aws.amazon.com/fr/rds/
[B19] http://cedric.cnam.fr/~farinone/SMB111/annee1011/architectureNTiers.pdf
[N1] *Véronique Messager Rota (2008), Gestion de projet Vers les méthodes
agiles (978-2212-12165-0). Groupe Eyrolles, Paris, France.
[N2] *Pierre Gérard (2013). Cours UML. IUT de Villetaneuse DUT

informatique, Université Paris.
95
[N3] *Aurélien VANNIEUWENHUYZE Scrum une méthode agile pour vos
projets
96
Conception et Réalisation d’une Plateforme de Détection et Gestion des Appels
d’Offres
Rapport de Stage PFE, Mastère N2TR UVT 2017-2018
_________________________________________________________________
RESUME
L’objectif principal de ce projet est d’élaborer un système de place de marché qui sert
essentiellement à gérer les appels d’offres et les transactions commerciales, assurer la
sureté et sécurité des données, le suivi des appels d’offres, la gestion les prestataires, la
gestion des abonnements et la statistique de tous les processus précédents.
Le travail présenté dans ce rapport concerne essentiellement le module les appels d’offres
qui sert à faciliter les contacts B2B qui se divise en deux catégories : des inscriptions sous
régime de prestataires et des inscriptions sous régime d’employé et aussi à gérer les
transactions entre eux comme il implique le module sureté et sécurité des données qui a
pour but d’authentifier les utilisateurs : prestataires ou employés ainsi de crypter les
données nécessaires.
Mots clés : Angular 5, AWS, Place marché, Appel d’offre, Scrum, MVC
_________________________________________________________________
SUMMARY
The main objective of this project is to develop a marketplace system that is mainly used to
manage tenders and commercial transactions, security and data security, the monitoring of
tenders, manage providers, manage subscriptions, manage and statistics of all previous
processes.
The work presented in this report focuses on the competitive bidding module used to
facilitate B2B contacts, which is divided into two categories: claim registrations and
employee enrollment and also to manage transactions between them as it involves the
security and data security module that aims to authenticate users: providers or employees
as well to encrypt the necessary data.
Key words: Angular 5, AWS, Marketplace, Tender, Scrum, MVC

Rapport Jee Scrum

Transféré par

Droits d'auteur :

Formats disponibles

Rapport Jee Scrum

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Jee Scrum

Transféré par

Droits d'auteur :

Formats disponibles

MEMOIRE

DE STAGE DE FIN D’ETUDES

Président : Mr. BEN BRAIEK E

Année Universitaire : 2017 / 2018

Je dédie ce modeste travail à mes chers parents Mohamed Najem et

A mon cher époux Anis qui m'a beaucoup encouragée et soutenue

A tous ceux qui me connaissent et contribuent du près ou de loin à

D'emblée je tiens à remercier DIEU le tout puissant de nous avoir aidé

Je dois être reconnaissante en remerciant infiniment mon encadrante

Dédicaces .............................................................................................................................. iii

Table des matières ................................................................................................................ vi

Liste des figures ..................................................................................................................... x

Liste des tableaux ................................................................................................................ xii

Liste des abréviations ......................................................................................................... xiii

INTRODUCTION GÉNÉRALE .......................................................................................................................... 1

CHAPITRE I. CADRE GÉNÉRAL DU PROJET ......................................................................................... 2

I.1 Présentation de Société ................................................................................................................... 3

I.1.1 Présentation du l’organisme d’accueil .................................................................................. 3

I.1.2 Service de Cynapsys ............................................................................................................. 3

I.2 Cadre de Projet ............................................................................................................................... 5

I.2.1 Contexte de Projet ................................................................................................................. 5

I.2.2 Analyse de l’existant :........................................................................................................... 6

I.2.2.1 Étude de l'existant........................................................................................................ 6

I.3 Méthodologies de travail ................................................................................................................ 8

I.3.1 Méthodologie agile ............................................................................................................... 8

I.3.2 Pourquoi Scrum .................................................................................................................... 9

I.3.3 Langages de modélisation ................................................................................................... 11

CHAPITRE II. PRÉPARATION.DE PROJET ............................................................................................ 12

II.1 Capture du Besoin ........................................................................................................................ 13

II.1.1 Spécifications des Besoins .................................................................................................. 13

II.1.1.1 Spécifications des Besoins Fonctionnels ................................................................... 13

II.1.2 Modélisation du besoin ....................................................................................................... 15

II.1.2.1 Identification des acteurs ........................................................................................... 15

II.2 Pilotage du Projet avec Scrum ...................................................................................................... 16

II.2.1 Equipe et rôle ...................................................................................................................... 16

II.2.2 Le Backlog du produit ........................................................................................................ 17

II.2.3 Planification de Release ...................................................................................................... 22

II.3 Environnement de travail ............................................................................................................. 23

II.3.1 Environnement matériel ...................................................................................................... 24

II.3.2 Environnement Logiciel...................................................................................................... 24

II.3.2.1 Outils de développement et modélisation :................................................................ 24

II.4 Architecture .................................................................................................................................. 30

II.4.1 Architecture du système ...................................................................................................... 30

II.4.2 Architecture n-Tiers ............................................................................................................ 30

II.4.3 Architecture de l’application............................................................................................... 31

CHAPITRE III. RELEASE 1 ..................................................................................................................... 33

III.1 Développement du Sprint1 « Authentification, Inscription et Gestion de profil » ....................... 34

III.1.1 Analyse .......................................................................................................................... 36

Diagramme de cas d’utilisation .................................................................................................... 36

III.1.2 Conception ..................................................................................................................... 40

III.1.2.1 Diagrammes de séquence .......................................................................................... 40

III.1.3.1 Architecture logique .................................................................................................. 43

III.2.1 Analyse .......................................................................................................................... 50

Diagramme de cas d’utilisation global ......................................................................................... 50

III.2.2.1 Description des interfaces ......................................................................................... 59

III.3 Conclusion :.................................................................................................................................. 62

CHAPITRE IV. RELEASE2 ...................................................................................................................... 63

IV.1.1 Analyse .......................................................................................................................... 68

IV.1.1.1 Diagramme de cas d’utilisation du sprint1 ................................................................ 68

IV.1.2 Conception ..................................................................................................................... 72