1. Tunisian Republic
Ministère de l’Enseignement Supérieur de la Recherche Scientifique
Université de Carthage
Faculté des Sciences Economiques et de Gestion de Nabeul
Rapport de Stage
Présenté en vue d’obtenir le diplôme de la LICENCE FONDAMENTALE :
Informatique Appliquée à la Gestion
Elaboré par
Moifek MAIZA
Conception et développement d’une application Hybride
pour la gestion des projets immobiliers
Réalisé au sein de
YASMINE ENGINEERING SYSTEMS
Encadré par
Mr.Mehdi MAHJOUB Mme.Dalila TRAD

2. DÉDICACE
A MES CHÈRES PARENTS
AUCUN MOT SI SACRÉ SOIT-IL, NE SUffiRA À APPRÉCIER À SA JUSTE VALEUR, LE SOUTIEN MATÉRIEL ET
SPIRITUEL, LES SACRICES QUE VOUS NE M’AVEZ CESSÉS DE DÉPLOYER.
JE VOUS OffRE EN GUISE DE RECONNAISSANCE, CE MODESTE TRAVAIL EN VOUS SOUHAITANT SANTÉ,
BONHEUR ET LONGUE VIE POUR QUE JE PUISSE COMBLER À MES TOUR.
A MES CHÈRES FRÈRES
JE DÉDIE CE TRAVAIL POUR VOUS SERVIR DE REPÈRE À DÉPASSER.
POUR VOUS RAPPELER QUE TOUT EST POSSIBLE UNE FOIS QUE VOUS FAITES LE PREMIER PAS.
A MES AMI(E)S, À QUI NOUS SOUHAITONS LE SUCCÈS, POUR L’AMITIÉ QUI NOUS A TOUJOURS UNIS
A TOUS CEUX QU’ON AIME ET CEUX QUI NOUS AIMENT.
i

3. REMERCIEMENT
je profite de cette page du ce rapport pour exprimer mes vifs remerciements à toutes personnes
contribuant de près ou de loin à l’élaboration de ce travail.
je tiens tout particulièrement à remercier Mr.Mhedi MAHJOUB, pour son accueil de joindre son
personnel durant quatre mois et de nous offrir l’opportunité de faire ce travail.
je remercie spécialement Mme.Dalila TRAD, notre encadrant universitaire à l’Institut Supérieur de
l’Informatique, pour les conseils qu’elle m’a donné, pour son suivi permanent,sa patience et son
intérêt porté sur le travail que nous avons réalisé.
je présent aussi, ma gratitude et reconnaissances à Mr.Nizar JALLANI responsable technique, pour
sa disponibilité, ses conseils, et son encouragement permanent.
Tous ceux qui ont contribué à mener à bien ce stage, trouvent ici l’expression de nos parfaite
considérations.
ii

4. TABLE DES MATIÈRES
Introduction générale 1
1 ETUDE PREALABLE N°1 3
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Cadre de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Présentation du cadre de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Présentation de la société . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Organisme d’acceuil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.3 Orgarnigramme de la société . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Etude de l’existant : Description et critique de l’existant . . . . . . . . . . . . . 6
1.3.1.1 Solution adoptée par l’entreprise . . . . . . . . . . . . . . . . . . . . 7
1.3.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.1 Méthode en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.2 SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.2.1 Étude comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
iii

5. 1.5 Pilotage du projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 PLANIFICATION ET SPÉCIFICATION DES BESOINS 17
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1 Identification des Acteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.1 Besoins fonctionels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.2 Besoins non fonctionels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Product BackLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Répartition des Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5 Diagrame de cas d’utilisation géneral . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6 Prototypage Des Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.7 Language de modélisation et outil de conception . . . . . . . . . . . . . . . . . . . . . 26
2.8 La Base de données et serveur utilisée . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.9 Les langages de programmation utilisée . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.10 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.10.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.10.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.11 Architecture Physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3 Etude et réalisation du release 1 34
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1 organisation du release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 Spécification Fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.1 Diagramme de cas D’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.2 Rafinement et description textuelle des cas d’utilisations . . . . . . . . . . . . 36
3.3 Diagramme de classe du Release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
iv

6. 4 Etude et réalisation du release 2 50
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1 BackLog du Release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.1 Diagramme de cas D’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.1.2 Rafinement et description textuelle des cas d’utilisations . . . . . . . . . . . . 52
4.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3 Diagramme de classes du release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5 Etude et réalisation du release 3 69
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.1 BackLog du Release 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.1.1 Diagramme de cas D’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.1.2 Rafinement et description textuelle des cas d’utilisations . . . . . . . . . . . . 71
5.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3 Diagramme de classe du release 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Conclusion générale 84
v

7. TABLE DES FIGURES
1.1 Yasmine Engineering Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Figure de L’orgarnigramme de la société . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Présentation OMRANEstate : Consulter Prospection . . . . . . . . . . . . . . . . . . . 7
1.4 Présentation OMRANEstate : Ajout Prospet . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Présentation OMRANEstate : Ajout Prospection . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Représentation Modèle 2-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.7 Le Cycle en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.8 Méthode SCRUM [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1 Répartition des releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 Figure de cas d’utilisation Géneral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 Prototype Interface Gérer licence web . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Prototype Interface Gérer Droits web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5 Prototype interface Consulter
prospection mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6 Prototype interface
Disponibilié Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.7 Prototype Interface Calendrier Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.8 Prototype Interface Login Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.9 Logo SSMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
vi

8. 2.10 Logo Dart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.11 Logo C# 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.12 Logo HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.13 Logo HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.14 Logo visual studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.15 Logo android studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.16 Logo .NET 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.17 Logo Blazor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.18 Logo Flutter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.19 Logo IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.20 Logo Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.21 Logo Draw.io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.22 Logo Adobe Xd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.23 Architecture de notre projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1 Diagramme de Cas d’utilisation du premier Sprint . . . . . . . . . . . . . . . . . . . . 36
3.2 Diagramme de séquence Vérifier Licence . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3 Diagramme de séquence Authentifier pour Admin YES . . . . . . . . . . . . . . . . . 42
3.4 Diagramme de séquence S’authentifier Pour Client et Administrateur Entreprise . . 43
3.5 Diagramme de séquence Ajouter Droit . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.6 Diagramme des Classes du premier Release Serveur Licence . . . . . . . . . . . . . . . 46
3.7 Diagramme de classe du premier Release serveur Client . . . . . . . . . . . . . . . . . 46
3.8 Interface Login Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.9 interface Gérer Droits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.10 interface login Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.11 (a)interface vérifier Licence
(b)interface Licence expirée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1 Diagramme de Cas d’utilisation du deuxième release . . . . . . . . . . . . . . . . . . . 52
4.2 Diagramme de séquence Détecter Appel . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3 Diagramme de séquence Ajouter Prospection . . . . . . . . . . . . . . . . . . . . . . 60
4.4 Diagramme de séquence Ajouter Licence . . . . . . . . . . . . . . . . . . . . . . . . 62
vii

9. 4.5 Diagramme des Classes du deuxieme Release Serveur Client . . . . . . . . . . . . . . . 64
4.6 Diagramme de classe du deuxieme Release serveur Licence . . . . . . . . . . . . . . . 65
4.7 interface Detecter Appel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.8 Interface Liste Licence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.9 Interface Modifier Licence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.10 interface Ajout prospect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.11 interface vérifier Licence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.1 Diagramme de Cas d’utilisation du Troisième release . . . . . . . . . . . . . . . . . . . 71
5.2 Diagramme de séquence Recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.3 Diagramme de séquence Consulter Disponibilité . . . . . . . . . . . . . . . . . . . . 76
5.4 Diagramme de séquence Consulter Rendez-vous . . . . . . . . . . . . . . . . . . . . 77
5.5 Diagramme de séquence Modifier Rendez-vous . . . . . . . . . . . . . . . . . . . . 78
5.6 Diagramme des Classes du troisième release Serveur Client . . . . . . . . . . . . . . . 80
5.7 Diagramme de classe du troisième release serveur Client . . . . . . . . . . . . . . . . 81
5.8 Interface Disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.9 Interface recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.10 Interface Gérer Rendez-vous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
viii

10. LISTE DES TABLEAUX
1.1 Tableau d’Étude comparative entre scrum et V . . . . . . . . . . . . . . . . . . . . . . 14
1.2 Équipes et Rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1 Tableau des Acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Tableau de BackLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1 organisation du release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 Déscription textuelle de Verifier licence . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3 Déscription textuelle de S’authentifier . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4 Description textuelle de réinitialiser mot de passe . . . . . . . . . . . . . . . . . . . 39
3.5 Description textuelle de Consulter Droits . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6 Description textuelle de Ajouter droit . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1 organisation du release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2 Description textuelle de Détecter appel . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3 Description textuelle de Ajouter Prospection . . . . . . . . . . . . . . . . . . . . . . 54
4.4 Description textuelle de Consulter Prospection . . . . . . . . . . . . . . . . . . . . . 55
4.5 Description textuelle de Modifier Prospection . . . . . . . . . . . . . . . . . . . . . 56
4.6 Déscription textuelle de Consulter liste licences . . . . . . . . . . . . . . . . . . . . 57
4.7 Déscription textuelle de Ajouter licence . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.8 Déscription textuelle de Modifier licence . . . . . . . . . . . . . . . . . . . . . . . . 58
ix

11. 5.1 organisation du release 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2 Description textuelle de Recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.3 Description textuelle de Disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.4 Description textuelle de Consulter Rendez-vous . . . . . . . . . . . . . . . . . . . . 73
5.5 Description textuelle de Modifier Rendez-vous . . . . . . . . . . . . . . . . . . . . . 74
x

12. LISTE DES ABRÉVIATIONS
YES - Yes - yes Yasminees Engineering Systems
UML Unified Modeling Language
ERP Enterprise Resource Planning
GUID Global Unique Identifier
EFC Entity Framework Core
LINQ Language-Integrated Query
API Application Programming Interface
SSMS Sql Server Management Studio
IIS Internet Information Services
xi

13. INTRODUCTION GÉNÉRALE
E
N raison de l’augmentation de la population et de l’augmentation globale de la demande dans le
domaine de l’immobilier, YES 1 a construit son projet OMRANEstate© 2 qui accélère le trai-
tement des clients et de nombreuses tâches d’une entreprise d’immobiliers.
ce dernier apporte du stabilité dans la vie professionnel des entreprise d’immobilier par son capacités
à traiter l’information dans des délais raisonnables, mais il reste encore des insuffisances.
Comme la technologie ne cesse d’avancer, Aujourd’hui en cherche à bien bénificier de ces nouvelles
technologies pour encore mieux optimiser ses traitements.
Cette idée était né de l’inquiétude que les agents commerciaux prennent encore notes dans des ca-
hiers, même à ce jour, ensuite l’agent devrait remplir l’information acquise dans le logiciel OMRA-
NEstate© à l’entreprise.
Avec l’émergence de la notion de la mobilité qui permet un accès distant, instantané et un flux
sans interruption d’informations, qui est symbolisée par l’apparition des appareils mobiles, comme
les smartphones et les tablettes qui ont connu une révolution technologique.
La tâche de gestion doit être plus facile, plus rapide et efficace. Par la proposition d’une application
mobile nous aspirons d’achever ce but.
Notre objectif principal est la sauvegarde des données des prospects et de l’activité principale dont
1. Yesminee Engineering Systems
2. Projet existant
1

14. un promoteur immobilier a besoin, Recherche de clients potentiels et ou de clients.
En raison de la taille et de la délicatesse de leur projet initial, cette procédure prend du temps et
pourrait même risquer de perdre des informations car leurs commerciaux ont besoin de se souvenir
de tous les détails qu’ils peuvent récolter sur un prospect, ce qui est fondamentalement la ressource
la plus précieuse recherchée par les promoteurs immobiliers.
Dans ce contexte YES a décidé que cette tâche doit être plus facile a faire et à accéder.
Durant notre stage, nous avons décidé à développer une application mobile intitulé “OMRANMo-
bile©” 3 , que nous présenterons le long de ce rapport :
• 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 du Projet » explique notre démarche, soit l’identification des
futurs acteurs de notre système, l’analyse des besoins et la description de l’architecture choisie pour
réaliser notre solution.
• Le troisième chapitre comporte le premier release de notre projet défini en se basant sur la méthodo-
logie Scrum et la Langage de Modélisation Unifié(UML). Nous présentons tout au long de ce chapitre
la spécification, la conception et la réalisation des trois premiers sprints.
• Le quatrième chapitre est consacré à la réalisation du deuxième release
• Le cinquième chapitre est dédié à la réalisation du troisième release.
• Enfin, nous allons clôturer ce rapport par une conclusion générale.
3. Projet réaliser
2

15. CHAPITRE 1
ETUDE PREALABLE N°1
3

16. Introduction
Dans ce chapitre, nous détaillerons le contexte général de notre projet. Premièrement, nous pré-
senterons l’organigramme de l’organisation hôte qui nous a donné l’opportunité de réaliser notre pro-
jet de fin d’études. Plus tard, nous décrirons les problèmes qui nous ont conduit à l’idée de ce projet
et les études détaillés qui ont été faites Pour arriver à la solution proposée. Se terminant a la fin par la
méthodologie de développement utilisée et une conclusion.
1.1 Cadre de travail
Le contexte de ce projet est solicite en tant que produit pour obtenir la licence fondamentale en
informatique appliquée à la gestion de la Faculté des Sciences Economiques et de Gestion de Nabeul
(FSEGN) en le préréglant comme mon projet de fin d’études et une nouvelle implémentation tech-
nologique pour l’entreprise hôte, tout en utilisant les connaissances acquises au cours des 5 derniers
semestres. Notre stage a été effectué dans la boite de développement Yasmine Engineering Systems
une société qui se spécialise dans la Gestion des projets immobilières en maintenant leur projet
OMRANEstate© depuis 2005. Le stage a duré 3 mois et le titre de notre projet est OMRANMobile©
1.2 Présentation du cadre de projet
1.2.1 Présentation de la société
Yasmine Engineering Systems est une entreprise privée tenu par ses propriétaires qui prennent
une participation active dans le développement de l’entreprise et de ses produits.
Yasmine Engineering Systems est un éditeur et intégrateur de logiciel, créé en 2005, suite à la
convergence de plusieurs pionniers dans le domaine des nouvelles technologies, l’étude des besoins,
la conception et l’implémentation de système d’informations intégrées.
Via son département de recherche et développement, ils sont à jour sur les nouvelles technologies.
La formation continue, pour répondre aux besoins de leur clientèle qui couvre un large spectre 1Ref[2]
1. Description pris de la présentation du YES
4

17. 1.2.2 Organisme d’acceuil
la société offre également ses services à plusieurs autres sociétés, opérant dans secteurs immobi-
lière Par mises principales réalisations, il est possible de distinguer :
| La Gestion des terrains : La gestion des terrains assure le suivi de tous les terrains acquis, en
cours d’acquisition, avec projet (bâtiment ou lotissement) et surtout toutes les opportunités de
terrains intéressants actuellement ou ultérieurement.
| La Gestion des projets : Planification des projets, contrôle des coûts et des délais, calcul des prix
de revient et analyse de la rentabilité.
| La Gestion des Réunions de chantiers : Historisation des réunions de chantier, suivi des ré-
serves et des décisions, Suivi des critères et des indicateurs d’avancement.
| Marketing : Capture et stockage des préférences des prospects, catégorisation des prospections
par nature de projet, par type d’article, par catégorie d’article, par orientation.
| Services Après Vente : Suivre les réclamations client depuis leurs saisies jusqu’à leurs clôtures,
accroître la réactivité face aux réclamations.
| Trésorerie : Maîtriser et optimiser les flux et la gestion des besoins en trésorerie, simuler le bilan
et la trésorerie d’une nouvelle opération.
| La gestion Commerciale : Situation du stock en temps réel, Groupement du stock par projets,
par bloc, par statut.
FIGURE 1.1 – Yasmine Engineering Systems
5

18. 1.2.3 Orgarnigramme de la société
La société oû nous avons effectuer notre stage est construit comme suit dans la figure 1.2, nous
avons effectuer notre stage dans l’organisme Direction Recherche Developpement.
FIGURE 1.2 – Figure de L’orgarnigramme de la société
1.3 Présentation du projet
Après avoir présenté l’association hôte et le contexte général de ce projet, nous nous concentrerons
sur la présentation du projet proprement dit et de ses détails. comme mentionné précédemment, ce
projet est principalement une implémentation d’un module existant dans une version mobile.
1.3.1 Etude de l’existant : Description et critique de l’existant
Nous ne pouvions débuter ce travail sans avoir une idée claire et précise sur l’existant du projet sur
lequel on va travailler. L’application existante est dédiée â tous les employés des sociétés immobilières,
pour cela une enquête effectuée auprès des responsables de la dite application, Il s’agit principalement
de Mr.Nizar JILANI ingénieur informatique et de Mr.Mahdi MAHJOUB directeur général.
6

19. 1.3.1.1 Solution adoptée par l’entreprise
OMRANEstate© est un logiciel de gestion intégré conçu pour les promoteurs Immobiliers. Solution
globale et intégrée qui couvre l’ensemble des Principaux aspects de la gestion des projets immobiliers.
Depuis l’étude d’une opportunité jusqu’à la réalisation et la commercialisation d’un projet.
F Front-End : pour qu’un utilisateur peut accèder au Module Vente 2, il doit utilisé le logiciel
principale 3.
Lafigure1.3représentl’interfacede«Consulterprospection»,àtraverslaquellel’utilisateurpeut
consulter tous les prospections.
FIGURE 1.3 – Présentation OMRANEstate : Consulter Prospection
2. Module qui nous concerne
3. OMRANEstate©
7

20. La figure 1.4 représente l’interface de «ajout prospet», à travers laquel l’utilisateur peut ajouter
un prospet.
FIGURE 1.4 – Présentation OMRANEstate : Ajout Prospet
La figure 1.5 représente l’interface de «Ajout prospection» , à travers de laquelle l’utilisateur rem-
plit le formulaire approprié pour ajouter une achat potentiel(prospection).
FIGURE 1.5 – Présentation OMRANEstate : Ajout Prospection
8

21. F Back-End :
Le Back-end du projet OMRANEstate est réaliser avec l’ecosysteme .NET en C#.
.NET est une plate-forme de développement open source multiplateforme gratuite pour la créa-
tion de nombreux types d’applications.
Avec .NET on peut utiliser plusieurs langues, éditeurs et bibliothèques pour créer des applica-
tion Web, mobile, bureau, jeux et l’IoT.
Omran Estate est une application dont l’architecture est 2-tiers orient serveur dans laquelle la
couche de présentation s’exécute sur un client (PC) et les données sont stockées sur un serveur
appelé deuxième niveau.
FIGURE 1.6 – Représentation Modèle 2-tiers
1.3.2 Critique de l’existant
A travers,l’analyse précédente correspondante à l’application existante nous avons pu cerner les
insuffisances suivantes :
F Portabilité : il n’est pas possible pour un employé d’utiliser le logiciel que s’il a accès aux ordina-
teurs de l’entreprise .
F Complexité : la procédure d’ajout d’un prospect ou d’une prospection est complexe et prend un
certain temps .
F Perte de temps et non-informatisation : les commerçants sur le terrain doivent porter un carnet
pour enregistrer toutes les informations qu’ils ont collecté et passer plus de temps à les ajouter
à la base de données
9

22. 1.3.3 Solution proposée
La solution proposée convertit le module le plus important et le plus utilisé de «OMRANEstate» qui
est celui de la vente; «Module vente»; en son équivalent dans une application mobile. Cette dernière
permet d’enrichir et remédier les insuffisances et les défaillances énumérées précédemment.
F Sur le plan technique,
R Ce projet permet aux informations d’être accessibles et actualisables partout, en introdui-
sant un serveur intermédiaire entre l’application Mobile, Web et le serveur Client.
R Ce projet agit également comme un projet indépendant avec des emplacement limité pour
chaque Licence. qui permettra au client de donner le droit de choisir les commerciaux qui
auront l’autorisation de se connecter a l’application.
F Sur le plan fictionnel l’application mobile apporte deux avantages principaux : le premier c’est
le gain de temps relatif au traitement des données et le second c’est la simplification de la tâche
de la gestion.
Nous envisageons alors de concevoir et de développer une application mobile qui permet de :
F Simplifier la gestion des prospets et des prospections en combinant les deux formulaires
F Donner l’accès direct au répertoire téléphonique et lancer des appels depuis l’application
F Offrir les fonctionalité d’un calendrier / rappel pour des événements ou des réunions.
F Fournir des informations utiles au commerçant en temps réel (disponibilité / prospets et pros-
pections)
F Garantir une meilleure expérience utilisateur avec une interface graphique moderne et ergono-
mique
F Deminuer ou enlever certains champs qui ne sont pas utiles.
Notre application contient une partie visible qui sert à afficher le contenu souhaité qu’on appelle front-
end qui est réalisé avec le Framework Flutter et language Dart. Elle doit egalement s’appuyer sur une
10

23. partie invisible back-end, qui permet de manipuler les données en utilisant des requêtes formulées
par une Application Programming Interface(API), qui joue le rôle de facilitateur d’échanges entre
l’application et la base de données. Les requêtes de l’API dites REST sont assez simples : sous la forme
d’un verbe non ambigu GET, POST, PUT, DELETE, elles manipulent la base de données pour réaliser
la tâche demandée et satisfaire l’utilisateur.
1.4 Méthodologie de développement
1.4.1 Méthode en V
z Terminologie
Le cycle en V est une méthode traditionnelle de gestion de projet conçue tout d’abord pour l’in-
dustrie puis adaptée à l’informatique en 1980. Il est une évolution du cycle en cascade qui man-
quait de réactivité. Il évite les retours en cas d’anomalie rencontrées. Il est composé d’une phase
descendante puis montante, la phase montante envoie des informations vis-à-vis de la phase
descendante. ([3])
FIGURE 1.7 – Le Cycle en V
On peut y distinguer 3 grandes parties : La phase de conception, la phase de réalisation (codage)
et la phase de validation.
z La phase de conception se réduit à 2 étapes
11

24. Ù Les spécifications fonctionnelles, qui représentent l’ensemble des besoins du client et/ou
définissent ce que doit faire le produit fini.
Ù Les spécifications techniques, qui détaillent comment le produit va être réalisé technique-
ment.
z La phase de réalisation
Ù Codage,c’est la phase de réalisation à proprement parler, pendant laquelle sont dévelop-
pées des briques qui sont ensuite assemblées pour créer le produit fini.
Ù Test unitaires, assurent que les briques logicielle modélisée et codée durant les étapes pré-
cédentes respectent de manière individuelle la cahier des charges.([3])
z La phase de validation contient 3 étapes
Ù Les test d’intégration, pendant lesquels on vérifie que l’intégralité du produit est valide
techniquement.
Ù Les tests de validation, qui sont un mélange de tests techniques et fonctionnels, et sur
lesquels le client se base souvent pour décider du lancement du produit.
Ù La recette, qui est utilisée pour vérifier que le produit est valide par rapport aux spécifica-
tion fonctionnelles, mais qui a tendance à intervenir qu’après la mise en production.([3])
1.4.2 SCRUM
SCRUM Est une méthodologie qui a pour principe, le développement d’une manière incrémentale
et itérative en incluant la participation du client. Chaque itération (Sprint) peut occuper de deux à 4
semaines, chaque sprint se termine par un produit fonctionnel livrable. ([4])
12

25. FIGURE 1.8 – Méthode SCRUM [1]
Scrum est la plus connue des méthodes agiles, elle met en avant l’aspect soudé d’une équipe auto-
organisée cherchant à atteindre un but partagé. La particularité de Scrum est de placer l’utilisateur
final au cœur de l’équipe et de valoriser l’individu, l’équipe, le concret, l’application, la collaboration
et l’adaptation.
F Répartitions des Rôles dans Scrum En mettant l’accent sur le fonctionnement en équipe, Scrum
remplace les chefs de projets, maîtres d’œuvre et d’ouvrage par d’autres rôles et fonctions
Ý Animateur de projet (Scrum Master) Le Scrum Master s’assure que le Scrum est correc-
tement appliqué. Pour cela, il doit enseigner au Product Owner et à l’équipe de développe-
ment leur rôle respectif et la bonne façon de l’exercer.
Ý L’équipe de développement Elle est composée idéalement de deux à neuf personnes. C’est
elle qui réalise le travail nécessaire pour aboutir à un incrément utilisable et livrable à la fin
de chaque itération.
Ý Propriétaire de prodtuit (Product Owner) C’est lui qui porte la vision du produit. En effet,
il représente les utilisateurs et les commanditaires du projet. Il est donc avant tout chargé
de maximiser la valeur du produit et le travail de l’équipe de développement. [4]
13

26. 1.4.2.1 Étude comparative
Le tableau 1.1 représente la comparaison entre la méthode en V et la méthode SCRUM [5]
TABLE 1.1 – Tableau d’Étude comparative entre scrum et V
Début du Tableau
Thème Méthode en V Scrum
Cycle de vie phases séquentielles Processus itératif
Livraison La livraisonest tardive puisqu’onattend
la réalisation de toutes les fonctionnali-
tés
Livraisonplusrapideetl’utilisationpar-
tielle du produit se fait trèstôt.
Contrôle Qualité Â la livraison finale (fin du cycle de dé-
veloppement) ce qui provoque un effet
tunnel
Le client visualise le produit partiel as-
sez tôt
Spécification Le changement nécessite de revenir à
la phase des spécifications, et repasser
par toutes les autres phases,temps et un
coût supplémentaire
Les spécifications sont beaucoup plus
souples on peut ajouter ou modifier
une nouvelle fonctionnalité dans des
sprints suivants qui n’était pas prévue
au départ
Planification Caractérisée par des plans détaillés sur
la base d’exigences stables et définies
tout au début du projet
Elle est adaptative avec ajustements si
nécessaires au fil de l’eau en fonction
des nouvelles demandes
14

27. Thème Méthode en V Scrum
Équipe L’équipe intervient uniquement dans la
phase de développement et n’a pas de
vision globale du projet
Chaque membre de l’équipe peut s’im-
pliquer plus dans le projet en parti-
cipant à des prises de décisions, en
échangeant sur les difficultés rencon-
trées
Documentation Produite en quantité importante Réduite au strict nécessaire
fin du Tableau
1.5 Pilotage du projet avec Scrum
Nous avons choisi la méthode Scrum aprés la comparer avec la méthode en V puisqu’elle satisfait
nos plans mieux :
• Fixer des but pour chaque semaine
• re-visiter la planification avec ajustements au fil de l’eau
• toute l’équipe participe dans tous les couches pour avoir une meilleur expérience au cours du
stage
le tableau 1.2 spécifie les Rôles qui nous avons adoptée.
Personne Role Mission
Mehdi Mahjoub Product Owner Définition des besoins et des
fonctionnalités à développer
Dalila Trad SCRUM Master Approbation du projet
Moifek Maiza
Moslem Gannoun
SCRUM Team Conception, développement,
tests et validation et déploiement
TABLE 1.2 – Équipes et Rôles
15

28. Conclusion
Durant ce premier chapitre nous avons présenté un aperçu général sur notre projet en mettant
le sujet dans son contexte en contiguïté avec l’organisme d’accueil au sein du quel nous avons passé
notre stage.
dans le chapitre Suivant, nous détaillerons Les technologies et stratégies que nous avons utilisées
pour réaliser ce projet
16

29. CHAPITRE 2
PLANIFICATION ET SPÉCIFICATION DES
BESOINS
17

30. Introduction
Ce chapitre permet de recueillir d’analyser, d’organiser les besoins et de recenser les grandes fonc-
tionnalités de notre application. Le but est d’aboutir à un diagramme de cas d’utilisation. Nous mon-
trons les exigences fonctionnelles du système, à savoir les fonctionnalités requises par l’utilisateur.
Puis nous ajouterons ensuite les exigences non fonctionnelles. Finalement, nous dresserons le pro-
duit back-log qui contient toutes les fonctionnalités que nous les classerons par release.
2.1 Identification des Acteur
Le tableau 2.1 représente l’ensemble des acteurs de notre application.
TABLE 2.1 – Tableau des Acteurs
Acteur Fonction
Administrateur d’Entreprise Il achete License Mobile et il gére ses employés .
Utilisateur(Commerciale) Il a pour fonction de chercher les prospects et prospec-
tions et ainsi les gérer. Il doit également consulter ses
tranches et Items disponible sans oublier de gérer ses
rendez-vous
Administrateur de Y.E.S il gère les comptes des licenciés et le nombre des
comptes des commerciaux de ses derniers.
2.2 Spécification des besoins
2.2.1 Besoins fonctionels
Les besoins fonctionnels sont les différentes fonctionnalités qui caractérisent un système. Dans ce
cadre, notre solution doit assurer les fonctionnalités suivantes :
F Le système doit permettre de s’identifier : le système offre aux employés de Omran l’accès à l’ap-
plication via une interface qui exige l’authentification.
18

31. F Système doit permettre de gérer une prospection : l’utilisateur a le pouvoir d’ajouter modifier et
consulter une prospection.
F Le système doit permettre de consulter les tranches disponibles de l’utilisateurs ainsi que les
items triés par le type et ses détailles .
F système doit permettre de gérer un prospect : l’utilisateur peut ajouter, modifier et consulter un
prospect.
F Le système doit permettre de consulter la calendrier de l’utilisateur ainsi l’ajout , la modification
et la suppression des rendez-vous .
F Le système doit permettre de consulter et gérer les licenciés : l’administrateur YES peut ajouter,
supprimer,modifier et consulter les Licences.
F L’application doit détecter les appels reçu ou sortant .
F Le système doit permettre à l’administrateur entreprise de gérer les droits de ces utilisateur.
F L’application doit permettre de chercher une prospection ou prospect.
F L’application doit permettre de vérifier/valider une licence acheté.
2.2.2 Besoins non fonctionels
Notre système devra respecter un ensembe de propriétes contribuant à une meilleure qualité de la
solution obtenue :
F La Sécurité : à travers la prise en compte des mesures assurant la sécurité tel que : L’utilisation
de la technologies EFC 1 qui rend toutes les requêtes SQL codées en C# avec LINQ 2 cet étape
élimine toute possibilité d’attacke SQL injection, l’utilisation de .NET User Secrets qui cache le
lien versla Basede donnée enfichier JSONcryptée pourla protectionau niveau DLL.L’utilisation
de JWT qui fonctionne comme un API key (OAuth) et controle de session.
F La performance : En garantissant un temps de réponse et de traitement acceptable pour toutes
lesfonctionnalitésdusystème(ouvertured’écran,chargementdel’application,importationsou/et
exportations de données,interrogation de données etc.).
1. Entitiy Framework Core, partie de .NET expliquer dans le chapitre suivant
2. Expliquer dans le chapitre suivant
19

32. F L’intégrité de données les données personnelles liées aux clients ne sont modifiées, exploitées
ou traitées que par les entités autorisées. Ceci est garanti par la capture et le traitement des en-
trées/sorties et La gestion des droits d’accès
F La fiabilité : le système doit etre disponible à tout moments pour l’utilisateur avec un accées
sécurisé par l’authentification
F L’ergonomie : Par la conformité aux standards d’ergonomie (la densité d’éléments, la conces-
sion, les couleurs, gestion des erreurs etc.) et les lois (loi de clôture, loi de la bonne forme, loi de
proximité etc.).
F La maintenabilité : par le choix d’une qualité des logiciels facilitant la compré- hensibilité de
l’objet des éléments, la modification qui est le degré de facilité de modification du système et la
testabilité d’un système.
20

33. 2.3 Product BackLog
Le backlog définit l’ensemble des fonctionnalités attendues de notre projet. Le Scrum Master devra
donc les classer selon un ordre de priorité. le tableau 2.2 présente le backlog produit de nos fonction-
nalités .
TABLE 2.2 – Tableau de BackLog
Début du Tableau
ID Nom Estimation Priorité Description
1 Authentification 2 semaines elevée Comme Utilisateur et Administra-
teur YES et Administrateur Entre-
prise, je dois m’authentifier afin
d’effectuer certaines fonctionna-
lités
2 Gestion des droits
d’accès
1 semaines Moyenne Comme Administrateur Entre-
prise, je veux choisir qui parmi
mes employés peut utiliser
l’application mobile.
3 L’octroi d’une licence 1 semaines elevée Comme Administrateur En-
treprise je veux acheter une
licence pour me pouvoir utiliser
l’application.
4 Gestion des Prospec-
tions et Prospects
2 semaines elevée Comme utilisateur, je veux ajou-
ter, modifier et consulter les pros-
pections ainsi que les prospects
associés.
21

34. Continuation du Tableau 2.2
ID Nom Estimation Priorité Description
5 Gestion des Licences 1 semaines moyenne Comme Administra-
teur YES je veux Ajou-
ter,supprimer,consulter,bloquer
et modifier les Licences. Je veux
également contrôler le nombre
maximal des utilisateurs pour
chaque licence.
6 Détection d’appels 1 semaines elevée Comme utilisateur je veux que
l’application détecte les appels et
me dérige vers la procédure ap-
propriée.
7 Gestion des rendez-
vous
1 semaines moyenne Comme utilisateur, je veux que
l’application me notifie des
rendez-vous et actions program-
mer durant ma journée.
8 Consultation des dis-
ponibilités
1 semaines elevée Comme utilisateur je veux
Consulter la disponibilités des
établissements.
9 Recherche 3 jours Moyenne Comme utilisateur, je veux cher-
cher le prospect ou la prospection
dans les plus brefs délais.
End of Tableau
22

35. 2.4 Répartition des Release
Après avoir définit le back-log produit nous organisons dans cette partie le plan et nous estimons
la durée de chaque release.
FIGURE 2.1 – Répartition des releases
23

36. 2.5 Diagrame de cas d’utilisation géneral
la figure2.2 représente la Cas d’utilisation Général de notre Application.
FIGURE 2.2 – Figure de cas d’utilisation Géneral
24

37. 2.6 Prototypage Des Interfaces
Le prototypage est la clé de voûte du développement itératif. Les prototypes se différencient selon
leur degré de réalisme. Un prototype d’interface présente la partie visible du logiciel, c’est à dire les
fenêtres de l’application ou la page d’accueil du site.
Il permet de réaliser un test de perception. Cela peut être réaliser avec des outils spécialiser tel que
Adobe Xd ou balsamiq.
Les figures suivantes son des prototypes d’interface proposé de notre système réaliser avec Adobe Xd.
FIGURE 2.3 – Prototype Interface Gérer licence web
FIGURE 2.4 – Prototype Interface Gérer Droits web
FIGURE 2.5 – Prototype interface Consulter
prospection mobile
FIGURE 2.6 – Prototype interface
Disponibilié Mobile
25

38. FIGURE 2.7 – Prototype Interface Calendrier Mobile
FIGURE 2.8 – Prototype Interface Login Mobile
2.7 Language de modélisation et outil de conception
F Terminologie
La language UML a pour but de faciliter les transitions, lors du développmenet d’un projet du
besoin originale à la phase d’implementation. UML se définit comme un langage de modélisa-
tion graphique et textuel destiné à comprendre et décrire des besoins, spécifier et documenter
des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer
des points de vue. [6]
26

39. 2.8 La Base de données et serveur utilisée
SSMS :
FIGURE 2.9 – Logo SSMS
SQL Server Management Studio (SSMS) est un environne-
ment intégré pour la gestion de toute infrastructure SQL.
Utilisez SSMS pour accéder, configurer, gérer, administrer et
développer tous les composants de SQL Server, Azure SQL
Database et Azure Synapse Analytics. SSMS fournit un seul
utilitaire complet qui combine un large groupe d’outils gra-
phiques avec un certain nombre d’éditeurs de scripts riches
pour fournir un accès à SQL Server pour les développeurs et
les administrateurs de base de données de tous les niveaux de
compétence. d’applications.[7]
2.9 Les langages de programmation utilisée
Dart :
FIGURE 2.10 – Logo Dart
Dart is a client-optimized language for developing fast apps
on any platform. Its goal is to offer the most productive pro-
gramming language for multi-platform development, paired
with a flexible execution runtime platform for app frame-
works. d’applications.[8]
27

40. C# :
FIGURE 2.11 – Logo C# 9
C# est un langage de programmation orienté objet et orienté
objet . C# fournit des constructions de langage pour prendre
en charge directement ces concepts, en faisant de C# un lan-
gage naturel dans lequel créer et utiliser des composants logi-
ciels. Depuis son origine, C# a ajouté des fonctionnalités pour
prendre en charge de nouvelles charges de travail et des pra-
tiques de conception de logiciels émergentes.[9] La version
qui nous utilisont est C#9.
Html :
FIGURE 2.12 – Logo HTML
HTML signifie Hyper Text Markup Language. Il est utilisé
pour concevoir des pages Web à l’aide d’un langage de bali-
sage. HTML est la combinaison de l’hypertexte et du langage
de balisage. L’hypertexte définit le lien entre les pages Web. Le
langage de balisage est utilisé pour définir le document texte
dans la balise qui définit la structure des pages Web.[10]
Kotlin :
FIGURE 2.13 – Logo HTML
Kotlin est un langage de programmation « pragmatique » à
usage général, gratuit, open source, de type statique, initiale-
ment conçu pour la JVM (Java Virtual Machine) et Android,
qui combine des fonctionnalités de programmation orien-
tées objet et fonctionnelles. Il est axé sur l’interopérabilité, la
sécurité, la clarté et le support de l’outillage.ref.[11]
28

41. 2.10 Environnement de travail
2.10.1 Environnement matériel
Pour la conception et la réalisation de notre projet, nous avons utilisé deux périphérique dont la
configuration suivant :
è Ordinateur portable :
• Fabricant : HP
• Processeur : intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz 2.81GHz
• RAM : 12Go
• système d’exploitation : Windows 10 x64
è Telephone portable :
• Fabricant : Samsung
• Processeur : Samsung Galaxy S7
• RAM : 4Go
• système d’exploitation : Android 8
29

42. 2.10.2 Environnement logiciel
• Visual Studio 2019 :
FIGURE 2.14 – Logo visual studio
L’environnement de développement intégré de Visual Studio
est une plateforme de lancement créative avec laquelle vous
pouvez modifier, déboguer et générer du code, puis publier
une application. Un environnement de développement inté-
gré (IDE) est un programme riche en fonctionnalités qui peut
être utilisé pour de nombreux aspects du développement de
logiciels. Au-delà de l’éditeur et du débogueur standard four-
nis par la plupart des IDE, Visual Studio inclut des compila-
teurs, des outils de complétion de code, des concepteurs gra-
phiques et de nombreuses autres fonctionnalités afin de faci-
liter le processus de développement logiciel.[12]
• Android studio 4.0 :
FIGURE 2.15 – Logo android studio
Android Studio est l’environnement de développement inté-
gré (IDE) officiel pour le développement d’applications An-
droid, basé sur IntelliJ IDEA. En plus du puissant éditeur de
code et des outils de développement d’IntelliJ, Android Stu-
dio offre encore plus de fonctionnalités qui améliorent votre
productivité lors de la création d’applications Android.[13]
• .NET :
FIGURE 2.16 – Logo .NET 5.
Le framework open-source et multiplateforme pour créer des
applications pour tous les systèmes d’exploitation, y com-
pris Windows, Mac et Linux. .NET prend en charge UWP et
ASP.NET Core. UWP est utilisé pour créer des cibles Windows
10 Windows et des applications mobiles. ASP.NET Core est
utilisé pour créer des applications Web. .NET 5. et la combi-
naison de .NET Framework et .NET Core anciennement divi-
sée et spécialisée dans différents domaines.
30

43. • Blazor :
FIGURE 2.17 – Logo Blazor
Blazor est un framework Web gratuit et open-source qui per-
met aux développeurs de créer des applications Web en utili-
sant C et HTML.[14]
• Flutter :
FIGURE 2.18 – Logo Flutter
Flutter est un framework open source utilisé pour créer des
applications iOS et Android natives à partir d’une base de
code unique. Il a été créé par Google en 2015.[15]
• IIS :
FIGURE 2.19 – Logo IIS
Internet Information Services (IIS) for Windows® Server is a
flexible, secure and manageable Web server for hosting any-
thing on the Web. From media streaming to web applications,
IIS’s scalable and open architecture is ready to handle the
most demanding tasks.[16]
•
31

44. Postman :
FIGURE 2.20 – Logo Postman
Postman est une plateforme de collaboration pour le déve-
loppement d’API. Les fonctionnalités de Postman simplifient
chaque étape de la création d’une API et rationalisent la colla-
boration afin que vous puissiez créer de meilleures API, plus
rapidement.[17]
• Draw.io :
FIGURE 2.21 – Logo Draw.io
Draw.io est une application gratuite en ligne, accessible via
son navigateur (protocole https) qui permet de dessiner des
diagrammes ou des organigrammes. Cet outil vous propose
de concevoir toutes sortes de diagrammes, de dessins vec-
toriels, de les enregistrer au format XML puis de les expor-
ter. Draw.io est un veritable couteau suisse de la frise chro-
nologique, de la carte mentale et des diagrammes de tout
genre.[18]
• Adobe Xd :
FIGURE 2.22 – Logo Adobe Xd
Adobe XD est un outil de conception numérique vectoriel
pour les sites Web et les applications. Utilisez-le pour créer et
collaborer sur tout, des prototypes aux maquettes en passant
par les conceptions complètes.
32

45. 2.11 Architecture Physique
Notre projet fonctionne Généralement comme un projet 3-tiers avec l’addition d’un serveur inter-
médiaire . Visualiser dans la figure 2.23
FIGURE 2.23 – Architecture de notre projet
Conclusion
Dans ce chapitre nous avons présenté un apperçu général sur note projet en mettant le sujet dans
son contexte et en identifiant les acteurs, les besoins, le backlog et le cas d’utilisation générale. ensuite
nous avons présenter l’environnement de développmenet et les technologies utilisée pour atteindre le
but que nous souhaitons.
33

46. CHAPITRE 3
ETUDE ET RÉALISATION DU RELEASE 1
34

47. Introduction
Après avoir analyser et spécifier les besoins de notre projet nous passerons maintenant au premier
release de notre rapport, Ce chapitre s’étale sur trois parties, la première est dédiée à détailler le back-
log et le diagramme de cas d’utilisation. La deuxième partie décrit la conception en se basant sur la
description textuelle des Cas d’utilisation et les diagrammes de séquence. Et pour finir, la troisième
partie est consacrée à l’exposition du travail réalisé par le biais de captures d’écrans.
3.1 organisation du release 1
Le tableau 3.1 présente l’organisation du release 1 .
ID User Story Description Priorité
1 S’authentifier En tant qu’administrateur je peux vérifier ma li-
cence et s’authentifier
Elevée
2 géstion des droits En tant qu’administrateur Entreprise je peut :
-ajouter des droits
-supprmier les droits
-consulter les utilisateurs
Elevée
Elevée
Elevée
3 en tant qu’administra-
teur YES je peux M’au-
thentifier
M’authentifier pour accéder au panneau admin Elvée
TABLE 3.1 – organisation du release 1
3.2 Spécification Fonctionnelle
Les spécifications décrit précisément l’ensemble des fonctions d’un logiciel ou d’une application,
fixe ainsi le périmètre fonctionnel du projet,Elles va donc définirles aspects métier de l’application,
leur mise en place ainsi que leur organisation. Dans notre cas la spécification fonctionnelle se traduit
par le diagramme des cas d’utilisation et on va donner plus de détails à travers la description textuelle
de ces derniers ainsi que leurs diagrammes de séquence.
35

48. 3.2.1 Diagramme de cas D’utilisation
La figure 3.1 presente le diagramme des cas d’utilisation du premier Sprint .
FIGURE 3.1 – Diagramme de Cas d’utilisation du premier Sprint
3.2.2 Rafinement et description textuelle des cas d’utilisations
Dans cette partie, on va clarifier le déroulement de la fonctionnalité et décrire la chronologie des
actions qui devront être réalisées par le systéme et par les acteurs .
36

49. n déscription textuelle de cas d’utilisation Verifier licence
Nom vérifier licence
Acteur Utilisateur(employé/administrateur de l’entreprise)
Objectif Lors de l’accès au système par la premiére fois l’utilisateur doit véri-
fier la licence pour pouvoir s’authentifier
Pré-Condition L’utilisateur doit avoir une licence et connaît son identifiant
Démarrage L’utilisateur démarre le systeme pour la premiére fois
Scénario nominale 1. L’utilisateur saisie ses paramètres d’identification
2. Le système vérifie l’information saisies par l’utilisateur, puis il ren-
voie l’utilisateur vers sa page approprié
Scénario alternatif 2.a[paramètre(s) d’identification incorrect(s)] : Le système signale
l’erreur et redemande les paramètres retour au point 1. du Scénario
nominale
TABLE 3.2 – Déscription textuelle de Verifier licence
37

50. n Déscription textuelle de cas d’utilisation Authentifier
Nom Authentifier
Acteur Utilisateur(employé/administrateur de l’entreprise)
Objectif Lors de l’accès au système, l’utilisateur doit se connecter pour y ac-
céder
Pré-Condition L’utilisateur doit avoir un compte enregistré dans la base de données
et connaît ses informations d’identification
Démarrage L’utilisateur démarre le systeme
Scénario nominale 1. L’utilisateur saisie ses paramètres d’identification
2. Le système vérifie l’information saisies par l’utilisateur, puis il ren-
voie l’utilisateur vers sa page approprié
Scénario alternatif 2.a[paramètre(s) d’identification incorrect(s)] : Le système signale
l’erreur et redemande les paramètres retour au point 1. du Scénario
nominale
TABLE 3.3 – Déscription textuelle de S’authentifier
38

51. n Déscription textuelle de cas d’utilisation «Réinitialiser mot de passe»
Nom Réinitialiser mot de passe
Acteur Employée
Objectif L’utilisateur doit pouvaoir réinitialiser son mot de passe en cas d’ou-
bli
Pré-Condition L’utilisateur doit avoir un compte enregistré dans la base de données
et connaît ses informations d’identification
Démarrage L’utilisateur a demandé la page de réinitialisation mot de passe en
cliquant sur mot de passe oublié.
Scénario nominale 1. L’utilisateur clique sur mot de passe oublié.
2.Le systeme affiche la page de réinitialisation de mot de passe.
3.L’utilisateur remplit le champ e-mail.
4. L’utilisateur clique sur valider
5. Le système confirme l’email et envoi un e-mail contenant un lien
avec URL unique pour réinitialiser le mot de passe.
Scénario alternatif 5.a[e-mail incorrecte] : Le système signale l’erreur et redemande les
paramètres retour au point 3. Du Scénario nominale
TABLE 3.4 – Description textuelle de réinitialiser mot de passe
39

52. n description textuelle de cas d’utilisation Consulter Droits
Nom Consulter Liste des employées
Acteur Administrateur de l’entreprise
Objectif Lors de l’accès au système, la page d’accueil contient l’interface
Consulter liste des employées
Pré-Condition Une authentification préalable
Démarrage l’utilisateur démarre le système
Scénario nominale 1. accède a la page d’accueil
2. Le système affiche la liste des employées
Scénario alternatif pas de scénario exceptionnel
TABLE 3.5 – Description textuelle de Consulter Droits
n description textuelle de cas d’utilisation Ajouter droit
Nom Ajouter droit
Acteur Administrateur de l’entreprise
Objectif Ajout droit a un commercant
Pré-Condition Une authentification préalable
Démarrage La page appropriée à Consulter liste des employées est visualisée
Scénario nominale 1. l’administrateur de l’entreprise clique sur le bouton approprié
2. Le système exécute la requête et affiche un message de confirma-
tion
Scénario alternatif 2.a[exception type employé] le système affiche un message d’erreur
2.b[nombre maximum d’utilisateurs mobiles dépassé] le Système af-
fiche un message d’erreur
TABLE 3.6 – Description textuelle de Ajouter droit
40

53. n Diagramme de séquence «Vérifier Licence»
FIGURE 3.2 – Diagramme de séquence Vérifier Licence
Afin d’accéder à l’application, l’employé doit vérifier sa licence la première fois qu’il utilise l’ap-
plication Omran en saisissant l’id de sa licence.
en appuyant sur «vérifier» l’application vérifie le champs contre la forme GUID 1 en suite le
contrôleur se charge de vérifier l’existence de l’id saisie dans l’entité «AdmLicence » dans le ser-
veur administrateur afin d’afficher l’interface d’authentification si elle existe, sinon le contrôleur
avertit l’interface «vérifier licence» d’afficher un message d’erreur.
1. Global Unique Identifier
41

54. n Diagramme de séquence «S’authentifier» pour l’administrateur YES
FIGURE 3.3 – Diagramme de séquence Authentifier pour Admin YES
Pour d’accéder à l’application, l’administrateur Y.E.S doit s’authentifier en saisissant son login et
son mot de passe.
Un premier contrôle se fait au niveau de l’interface « Login » pour vérifier la validité des champs,
si les champs sont valides, le controleur verifie l’existance des donne saisies dans l’entité «AdmU-
ser» afin de charger sa session s’il existe, sinon le contrôleur avertit l’interface «Login» d’afficher
un message d’erreur.
42

55. n Diagramme de Séquence «S’authentifier» Pour Client et Administrateur Entreprise
FIGURE 3.4 – Diagramme de séquence S’authentifier Pour Client et Administrateur Entreprise
Pour accéder à l’application, l’utilisateur ( client licencié et commerciale) doit s’authentifier.
Suite à une clique sur «Se connecter», un premier contrôle se fait au niveau de l’interface « Login
» pour vérifier la validité des champs, si les champs sont valides, le contrôleur contrôle premiè-
rement l’existance et la validité du licence dans le serveur centrale puis il se charge de vérifier
l’existence des donnes saisies dans le serveur client, sinon le contrôleur avertit l’interface «Au-
thentification» par l’affichage d’un message d’erreur.
43

56. n Diagramme de séquence «Ajouter Droit»
FIGURE 3.5 – Diagramme de séquence Ajouter Droit
L’administrateur réseau accède à (Dashboard Admin) la plate-forme web, s’identifie et visua-
lise l’interface Consulter liste des employées. l’administrateur peut changer les droits, ajouter
et supprimer ses employé dans cet interface sous forme des boutons dynamique. en appuyant
sur le bouton pour associé le droit Mobile User à un employé le Système exécute la requête,
le commerçant devient authentifier et peut utiliser l’application sinon si le nombre maximum
d’utilisateurs mobiles est dépassé le Système affiche un message d’erreur.
44

57. 3.3 Diagramme de classe du Release 1
Dans cette partie nous présentons le diagramme de classe de release 1, qui représente les classes
utilisées dans notre système.
ä Serveur Licence :
u La classe AdmLicence contient l’id et la description du licence et la date d’activation , la date
d’expiration du licence , le nombre des utilisateur et l’url de serveur de la licence aussi l’e-mail
du l’administrateur de l’entreprise.
u La Classe AdmUser représente l’employé YES, elle contient l’e-mail, l’Id et plusieurs informations
sur l’utilisateur(ne sont pas nécessaire pour nos procedure).
u La classe CfgTier contient l’email et l’adresse et l’id de type de CfgTier.
u La classe SysRestPasswordRequest contient l’url pour la requête unique pour réinitialiser le mdp
du client, son ID, date de creation du requête et l’id du licence de son employer.
u La classe CfgTierType contient une description ( entreprise , personne ...)
u La classe AdmAppSession présentent les Session Actives et non-actives, cette classe fonctionne
comme un Journal d’accées. Elle contient un ID de session, L’id de la Licence utilisée, début et
fin de la session, la version de l’application, le MAC de la machine et une copie de la JWT 2 .
u La classe SysBlackListToken présentent JWT et Session bloqués ,cette classe contient l’id de ses-
sion et le JWT Approprié.
ä Serveur Client :
u La Classe AdmUser représente les employées de l’entreprise, cet classe contient l’id, le role et le
type de l’employé elle continet aussi le champ MobileUser.
La Figure 3.7 représente le serveur côté client et la Figure 3.6 représente le serveur côté administration
SERVEUR CENTRALE .
2. JSON Web Token
45

58. FIGURE 3.6 – Diagramme des Classes du premier Release Serveur Licence
FIGURE 3.7 – Diagramme de classe du premier Release serveur Client
46

59. 3.4 Réalisation
• Page Log in Administrateur YES/ Administrateur Entreprise :
La figure 3.8 et la page de login utilisé
par l’administratuer YES et L’administra-
teur de l’entreprise licencié pour accéder
a leur interface respective.
FIGURE 3.8 – Interface Login Web
• Page Gérer Droits :
La Figure 3.9 Liste les Utilisateur(Agent Commerciale) des Entreprise avec des information et la
possibilitédegérerleurdroits.depuiscetinterfacel’administrateurEntreprisepeutajout/supprimer
le droits d’un de ces utilisateur pour utiliser l’application mobile.
FIGURE 3.9 – interface Gérer Droits
47

60. • Interface login Mobile
l’utilisateur mobile accède a cette
interface après vérifier sa licence.
L’utilisateur s’authentifie pour accéder a
l’interface d’accueil.
FIGURE 3.10 – interface login Mobile
• Interface vérifier Licence
L’utilisateur mobile accède a cette
interface après avoir démarrer
l’application pour la première fois.
l’utilisateur rempli le formulaire par la
licence pour accéder à l’interface de
l’authentification. Si la licence est
incorrecte l’interface demande que le
code soit resaisie. sinon la licence est
expirée. 3.11(b)
(a) (b)
FIGURE 3.11 – (a)interface vérifier Licence
(b)interface Licence expirée
48

61. Conclusion
L’étudeetlaréalisationdupremierrelease(contenantlestroispremierssprint)sontachevées,nous
passons maintenant au deuxième release; Objet du quatrième chapitre.
49

62. CHAPITRE 4
ETUDE ET RÉALISATION DU RELEASE 2
50

63. Introduction
Aprèsavoiranalyseretspécifierlesbesoinsdenotreprojetnouspasseronsmaintenantaudeuxième
release de notre rapport, Ce chapitre s’étale sur trois parties, la première est dédiée à détailler le back-
log et le diagramme de cas d’utilisation. La deuxième partie décrit la conception en se basant sur la
description textuelle des Cas d’utilisation et les diagrammes de séquence. Et pour finir, la troisième
partie est consacrée à l’exposition du travail réalisé par le biais de captures d’écrans.
4.1 BackLog du Release 2
Le tableau présente le Backlog de release 2 avec la priorité
ID User Story Description Priorité
1 Detection d’appel Le Système doit détecter les appels entrant et sor-
tant et offre l’option d’ajouter une prospection ou
prospect apres l’appel
Elevée
2 Géstion des prospec-
tions
En tant qu’utilisateur je peut :
-ajouter des Prospections
-Modifier les Prospections
-consulter les Prospections
Elevée
Elevée
Elevée
3 Gestion des licences en tant qu’administrateur YES je peut :
-Ajouter des licences
-Modifier les Licences
-Supprimer Les Licences
Elvée
Elvée
Elvée
TABLE 4.1 – organisation du release 2
51

64. 4.1.1 Diagramme de cas D’utilisation
La figure 4.1 présente le diagramme des cas d’utilisation du deuxième release .
FIGURE 4.1 – Diagramme de Cas d’utilisation du deuxième release
4.1.2 Rafinement et description textuelle des cas d’utilisations
Dans cette partie ,on va décrire la chronologie des actions qui devront être réalisées par le système
et par les acteurs , clarifier le déroulement de la fonctionnalité et décrire la chronologie des actions qui
devront être réalisées.
52

65. n description textuelle de cas d’utilisation Détecter appel
Nom Détecter appel
Acteur Utilisateur(employé)
Objectif Dés qu’un appel terminé est détecté sur la machine (téléphone) de
l’utilisateur l’application demande si un appel professionnel ou pri-
vée
Pré-Condition Une Authentification préalable
Démarrage L’utilisateur termine un appel
Scénario nominale 1. L’utilisateur termine un appel
2. Le système demande si un appel professionnel ou privée
Scénario alternatif Pas de scénario exceptionnel
TABLE 4.2 – Description textuelle de Détecter appel
53

66. n Déscription textuelle de cas d’utilisation Ajouter Prospection
Nom Ajouter Prospection
Acteur Utilisateur(employé)
Objectif L’utilisateur veut ajouter une nouvelle prospection
Pré-Condition L’utilisateur doit être identifier et à accès a l’internet
Démarrage L’utilisateur accède a l’interface ajout prospection
Scénario nominale 1. L’utilisateur remplie le formulaire d’ajout
2. Le système vérifie l’information saisies par l’utilisateur, puis il ren-
voie l’utilisateur vers sa page approprié
Scénario alternatif 2.a[paramètre(s) ou champs incorrect(s)] : Le système signale l’er-
reur et redemande les paramètres retour au point 1. du Scénario no-
minale
TABLE 4.3 – Description textuelle de Ajouter Prospection
54

67. n Description textuelle de cas d’utilisation «consulter Prospection»
L’interface Consulter Prospection et l’interface d’accueil pour notre application, fonctionne dy-
namiquement pour charger les prospection en temps réel lorsque l’utilisateur atteint presque la
fin de la page.
Nom Consulter Prospection
Acteur Utilisateur(employé)
Objectif L’utilisateur veut visualiser les prospections
Pré-Condition L’utilisateur doit être identifier et à accès a l’internet
Démarrage L’utilisateurdémarrel’application/l’utilisateuraccèdealapaged’ac-
cueil
Scénario nominale 1. L’utilisateur démarre l’application / l’utilisateur accède a la page
d’accueil
2. Le système affiche la liste des prospections
Scénario alternatif 2.a[pas d’accès a l’internet] : Le système affiche un message d’erreur
avec une visualisation approprié en attendant l’accès a l’internet
TABLE 4.4 – Description textuelle de Consulter Prospection
55

68. n Déscription textuelle de cas d’utilisation Modifier Prospection
L’interface Ajout Prospection est accessible de l’action détecter appel et aussi de n’importe
ou dans l’application, cet interface contient plusieurs formulaire qui aide a créer un nouveau
client en même temps que créer une prospection détailler avec le plus nécessaire
Nom Modifer Prospection
Acteur utilisateur(employé)
Objectif L’utilisateur veut Modifier une prospection
Pré-Condition L’utilisateur doit être identifier et à accès a l’internet
Démarrage l’utilisateur choisie une prospection a modifier dans l’interface
consulter prospections
Scénario nominale 1. L’utilisateur remplie le formulaire de Modification
2. Le système vérifie l’information saisies par l’utilisateur, puis il ren-
voie l’utilisateur vers sa page approprié
Scénario alternatif 2.a[paramètre(s) ou champs incorrect(s)] : Le système signale l’er-
reur et redemande les paramètres retour au point 1. du Scénario no-
minale
TABLE 4.5 – Description textuelle de Modifier Prospection
56

69. n Déscription textuelle de cas d’utilisation «Consulter liste des licences»
Nom Consulter liste licences
Acteur Administrateur YES
Objectif L’utilisateur doit consulter la liste des licences
Pré-Condition L’utilisateur doit être authentifié.
Démarrage L’utilisateur a demandé la liste des licences
Scénario nominale 1. L’utilisateur demande la page.
2.Le systéme affiche la liste des licences.
Scénario alternatif Pas d’exception.
TABLE 4.6 – Déscription textuelle de Consulter liste licences
n Déscription textuelle de cas d’utilisation «Ajouter Licence»
Nom Ajouter licence
Acteur Administrateur YES
Objectif l’utilisateur doit pouvoir ajouter une licence
Pré-Condition L’utilisateur doit être authentifié.
Démarrage L’utilisateur a demandé d’ajouter un licencié
Scénario nominale 1. L’utilisateur demande la page d’ajout des licences.
2.le systéme affiche le formulaire.
3.l’utilisateur remplis le formulaire
4. le système confirme les données et ajoute la licence.
Scénario alternatif 4.a[données invalides ou introuvables] Le système signale l’erreur et
redemande les paramètres retour au point 3. du Scénario nominale
TABLE 4.7 – Déscription textuelle de Ajouter licence
57

70. n Déscription textuelle de cas d’utilisation «Modifier licence»
Nom Modifier licence
Acteur Administrateur YES
Objectif L’utilisateur doit pouvoir modifier une licence
Pré-Condition L’utilisateur doit être authentifié et le licence doit être existante dans
la base de données
Démarrage L’utilisateur a demandé de modifier une licence
Scénario nominale 1. L’utilisateur choisi de modifer une licence.
2.Le systéme affiche le formulaire rempli déja des donnée existante.
3.L’utilisateur remplis/modifie le formulaire
4. le système confirme les données et Modifie la licence.
Scénario alternatif 4.a[données invalides ou introuvables] Le système signale l’erreur et
redemande les paramètres retour au point 3. du Scénario nominale
TABLE 4.8 – Déscription textuelle de Modifier licence
4.2 Conception
Danscettepartie,nousallonsélaborerlesdiagrammesdesequenceainsiquelesdiagrammesdes
classes participantes et clôturer par l’établissement du diagramme de classes global de sprint.
Pour chaque cas d’utilisation, nous réaliserons un diagramme de séquence ou plusieurs repré-
sentant notre choix d’allocation de responsabilités dynamiques.
58

71. n Diagramme de séquence «Détecter Appel»
FIGURE 4.2 – Diagramme de séquence Détecter Appel
Après terminer un appel le système affiche l’interface Détecter Appel et demande si s’était un
appelprofessionnelouprivée.Sic’estunappelprofessionnellesystèmeaffichel’interfaced’ajout
de prospection avec des informations du client s’il existe déjà. Sinon si c’est un appel privée le
système ne fait rien.
59

72. n Diagramme de séquence «Ajouter Prospection»
FIGURE 4.3 – Diagramme de séquence Ajouter Prospection
60

73. La figure 4.3 répresente l’interface ajouter prospection. ce dernier fonctione sous forme d’un
formulaire à 3 parties, une partie pour l’information du prospect, la deuxième pour l’informa-
tion du prospections et la dernière pour plus de détails. Aussi, cet interface permet d’ajouter une
prospection express, c’est une prospection qui ne contient pas tous les information nécessaire
mais qui sert à garder l’information qui ont était acquise pour les future réunion.
61

74. n Diagramme de séquence «Ajouter Licence»
La figure 4.4 représente le diagramme de séquence ajouter Licence .
FIGURE 4.4 – Diagramme de séquence Ajouter Licence
62

75. 4.3 Diagramme de classes du release 2
Dans cette partie nous présentons le diagramme de classe de Notre release, composé des classes
utilisé suivantes.
ä Serveur Licence :
u La classe AdmLicence contient l’id et la description du licence et la date d’activation , la date
d’expiration du licence , le nombre des utilisateur et l’url de serveur de la licence aussi l’e-mail
du l’administrateur de l’entreprise.
u LaClasseAdmUserreprésentel’employéYES,ellecontientl’e-mail,l’Idetplusieursinformations
sur l’utilisateur(ne sont pas nécessaire pour nos procedure).
u La classe AdmAppSession Contient l’url du serveur et une reference de l’utilisateur .
u La classe SysBlackListToken cert a blocker une sesssion
ä Serveur Client :
u La Classe AdmUser représente les employées de l’entreprise, cet classe contient l’id, le role et le
type de l’employé elle continet aussi le champ MobileUser.
u La classe CfgTier représente les client de nos client, cet table est utiliser pour créer des nouveau
prospect ou visualiser/modifier les prospect existant.
u La Classe ComProspection Contient les prospections et l’information qu’ils conserne, qui à
créer la prospection, quand, qui est le client etc..
u La Classe ComProspectionCategory Contient les Category des prospections(S+1;S+2;garage..)
utilisé dans prospection express.
u La Classe ComProspectionOrigin Continet les option de marketing, pour déclare d’où le pros-
pect a pu contacter le commerçant.
u La Classe ComProspectionKind contient des options pour déclarer la volonté d’un client de
procéder à l’achat.
u La Classe StkItem Contient les domaines qui son référencer dans les prospections.
63

76. la Figure 4.5 représente le serveur côté client
FIGURE 4.5 – Diagramme des Classes du deuxieme Release Serveur Client
64

77. la Figure 4.6 représente le serveur côté administration SERVEUR CENTRALE
FIGURE 4.6 – Diagramme de classe du deuxieme Release serveur Licence
4.4 Réalisation
• Interface Detecter Appel Mobile
La figure 4.7 représente l’interface
Detecter Appel, ce dernier s’afficher
l’hors du fin d’un appel entrant ou
sortant. L’interface offre deux options
privé ou professionnel, l’option
privé ne fait rien, l’option
professionnel déclanche le scénario
ajout prospection.
FIGURE 4.7 – interface Detecter Appel
65

78. • Page Liste Licence :
La figure 4.8 Liste les Licence actif et non actif leurs date d’activation et d’expiration aussi que l’émail
de leur admin et son ID aussi que l’URI vers le serveur de client.
depuis cet interface l’administrateur YES peut ajout/supprimer et bloquer une licence.
FIGURE 4.8 – Interface Liste Licence
• Page Modifier Licence :
L’administrateur YES clique sur l’icone stylo pour accéder a
cet page, qui lui permet à Modifier l’information de la Li-
cence, cet page contient deux bouton save pour envoyer
l’information et fill pour réinitialiser le formulaire avec les
information d’origine.
FIGURE 4.9 – Interface Modifier Licence
66

79. • Interface Ajout Prospection - partie Prospect :
La figure 4.10 représente l’interface
d’ajout d’un prospect. Ce dernier fais
partie d’un formulaire qui est diviser en
3 interface.
FIGURE 4.10 – interface Ajout prospect
• Interface Ajout prospection - partie prospection
La figure 4.11(a), représente la
deuxième partie du formulaire ajout
prospection. la figure 4.11(b),
représenta la troisième et la partie finale
du formulaire ajout prospection.
(a) (b)
FIGURE 4.11 – interface vérifier Licence
67

80. Conclusion
L’étude et la réalisation du deuxième release (contenant les sprint 4-5-6) sont achevées, nous pas-
sons maintenant au troisième release; Objet du cinquième chapitre.
68

81. CHAPITRE 5
ETUDE ET RÉALISATION DU RELEASE 3
69

82. Introduction
Aprèsavoiranalyseretspécifierlesbesoinsdenotreprojetnouspasseronsmaintenantautroisième
release de notre rapport, Ce chapitre s’étale sur trois parties, la première est dédiée à détailler le back-
log et le diagramme de cas d’utilisation. La deuxième partie décrit la conception en se basant sur la
description textuelle des Cas d’utilisation et les diagrammes de séquence. Et pour finir, la troisième
partie est consacrée à l’exposition du travail réalisé par le biais de captures d’écrans.
5.1 BackLog du Release 3
Le tableau présente le Backlog de release 3 avec la priorité
ID User Story Description Priorité
1 Disponibilité Comme Utilisateur je peut consulter la disponibi-
lité des immobiliers
Elevée
2 Actions En tant qu’utilisateur je peut :
-ajouter des Actions
-Modifier les Actions
-consulter les Actions
Elevée
Elevée
Elevée
3 Recherche En tant qu’utilisateur je peut chercher les prospec-
tions ou prospets
Elvée
TABLE 5.1 – organisation du release 3
70

83. 5.1.1 Diagramme de cas D’utilisation
La figure 5.1 présente le diagramme des cas d’utilisation du troisième release .
FIGURE 5.1 – Diagramme de Cas d’utilisation du Troisième release
5.1.2 Rafinement et description textuelle des cas d’utilisations
Dans cette partie ,on va décrire la chronologie des actions qui devront être réalisées par le système
et par les acteurs , clarifier le déroulement de la fonctionnalité et décrire la chronologie des actions qui
devront être réalisées.
71

84. n description textuelle de cas d’utilisation Recherche
Nom Recherche
Acteur Utilisateur(employé)
Objectif L’utilisateur veut chercher un prospet
Pré-Condition Une authentification préalable
Démarrage L’utilisateur accède a l’interface Recherche
Scénario nominale 1. L’utilisateur sasie la critère
2. Le système Affiche les prospets qui correspondent à cet critère
Scénario alternatif 2.a[Aucun prospet qui correspond au critère] le système affiche une
page vide avec le message approprié
TABLE 5.2 – Description textuelle de Recherche
72

85. n Description textuelle de cas d’utilisation Disponibilité
Nom Disponibilité
Acteur Utilisateur(employé)
Objectif L’utilisateur veut consulter la disponibilité des immobilier
Pré-Condition Une Authentification préalable
Démarrage L’utilisateur accède a l’interface Disponibilité
Scénario nominale 1. L’utilisateur visualise la résultat et clique sur un projet
2. Le système affiche les immobilier associé a ce projet et leur état de
disponibilité
Scénario alternatif Aucun scénario alternatif
TABLE 5.3 – Description textuelle de Disponibilité
n Description textuelle de cas d’utilisation «Consulter Rendez-vous»
Nom Consulter Rendez-vous
Acteur Utilisateur(employé)
Objectif L’utilisateur veut visualiser les ces rendez-vous
Pré-Condition Une authentification préalable
Démarrage L’utilisateur accède a l’interface action
Scénario nominale 1. l’utilisateur visualise l’interface
2. Le système affiche une calendrier remplis de ces rendez-vous
3. L’utilisateur appuie sur les jours des réunions
4. le système affiche les réunions en plus de détails
Scénario alternatif 2.a[pas d’accès a l’internet] : Le système affiche que la calendrier
TABLE 5.4 – Description textuelle de Consulter Rendez-vous
73

86. n Déscription textuelle de cas d’utilisation Modifier Rendez-vous
l’utilisateur peut appuyé prolongement sur les réunion pour les modifer.
Nom Modifer Rendez-vous
Acteur Utilisateur(employé)
Objectif L’utilisateur veut Modifier une prospection
Pré-Condition Authentification préalable et réunion visualisé
Démarrage L’utilisateur appuie prolongement sur le réunion
Scénario nominale 1. L’utilisateur remplie le formulaire de Modification
2. Le système vérifie l’information saisies par l’utilisateur, puis il ren-
voie l’utilisateur vers sa page approprié
Scénario alternatif 2.a[paramètre(s) ou champs incorrect(s)] : Le système signale l’er-
reur et redemande les paramètres retour au point 1. du Scénario no-
minale
TABLE 5.5 – Description textuelle de Modifier Rendez-vous
5.2 Conception
Dans cette partie, nous allons élaborer les diagrammes d’interaction ainsi que les diagrammes
desclassesparticipantesetclôturerparl’établissementdudiagrammedeclassesglobaldesprint.
Pour chaque cas d’utilisation, nous réaliserons un diagramme de séquence ou plusieurs repré-
sentant notre choix d’allocation de responsabilités dynamiques.
74

87. n Diagramme de séquence «Recherche»
FIGURE 5.2 – Diagramme de séquence Recherche
Après saisir et appuyer sur le bouton le système envoie la requête de recherche et affiche la ré-
sultat sous forme des ticket dans le même interface.
75

88. n Diagramme de séquence «Consulter Disponibilité»
FIGURE 5.3 – Diagramme de séquence Consulter Disponibilité
l’utilisateur accède a l’interface Consulter Disponibilité de n’importe oû dans l’application.
cette interface affiche les tranches et projets associer au utilisateur et leurs état.
76

89. n Diagramme de séquence «Consulter Rendez-vous»
FIGURE 5.4 – Diagramme de séquence Consulter Rendez-vous
L’utilisateur accède à l’interface Action qui contient la calendrier.
le système charge la calendrier dynamiquement en temps réel et affiche les réunion du commer-
ciale dans leurs jours respective.
en appuyant sur les jours le système affiche les détails des réunions dans le même interface.
77

90. n Diagramme de séquence «Modifier Rendez-vous»
FIGURE 5.5 – Diagramme de séquence Modifier Rendez-vous
Après que l’utilisateur visualise les réunion comme expliquer dans le diagramme de séquence
5.4 l’utilisateur peut appuyer prolongement sur les réunion pour les visualiser en détails. le sys-
tème affiche un interface de modification contenant l’information de la réunion sous forme d’un
formulaire que l’utilisateur peut modifier. ce dernier ensuite appuie sur Modifier pour confir-
mer et le système traite la procédure.
78

91. 5.3 Diagramme de classe du release 3
Dans cette partie nous présentons le diagramme de classe de notre release, composé des classes
utilisé suivantes.
ä Serveur Licence :
u La classe AdmLicence contient l’id et la description du licence et la date d’activation , la date
d’expiration du licence , le nombre des utilisateur et l’url de serveur de la licence aussi l’e-mail
du l’administrateur de l’entreprise.
u LaClasseAdmUserreprésentel’employéYES,ellecontientl’e-mail,l’Idetplusieursinformations
sur l’utilisateur(ne sont pas nécessaire pour nos procedure).
u La classe AdmAppSession Contient l’url du serveur et une reference de l’utilisateur .
u La classe SysBlackListToken cert a blocker une sesssion
ä Serveur Client :
u la Classe ComActionMessage Contient les réunion et les message associé aussi que d’autre in-
formation et clé étranger pour déterminer le type de l’action
u la Classe ComActionMessageType Contient les tpyes des actions qui soient reférencer comme
des clé étranger dans la classe ComActionMessage
u la Classe ComActionMessageCategory Contient les Catégories des actions qui soient référencer
comme des clé étranger dans la classe ComActionMessage
79

92. Le serveur côté client est représenter à la Figure 5.6.
FIGURE 5.6 – Diagramme des Classes du troisième release Serveur Client
80

93. Le serveur côté administration SERVEUR CENTRALE est représenter à la figure Figure 5.7.
FIGURE 5.7 – Diagramme de classe du troisième release serveur Client
81

94. 5.4 Réalisation
• Interface Disponibilité :
La figure 5.8 représente l’interface dispo-
nibilité.
FIGURE 5.8 – Interface Disponibilité
• Interface Recherche
La figure 5.9 représente l’interface de
recherche de prospect/prospection. le
recherche se fait pour chaque entrée,
soit ajout d’une lettre ou supression.
FIGURE 5.9 – Interface recherche
82

95. • Interface Gérer Rendez-vous
La figure 5.10(a) représente l’interface
Consulter Rendez-vous. L’utilisateur
peut appuyer sur un jour pour lister les
rendez-vous, chaque couleur spécifie le
type de rendez-vous.
La figure 5.10 (b) représente l’interface
ajout rendez-vous.
(a) (b)
FIGURE 5.10 – Interface Gérer Rendez-vous
Conclusion
L’étude et la réalisation du troisième release (contenant les trois dèrnier sprint) sont achevées. ceci
conclut les chapitres à couvrir dans notre rapport.
83

96. CONCLUSION GÉNÉRALE
P
Our conclure, nous avons effectué un stage au sein de la société Yesmine Engineering systems.
Lors de ce stage, nous avons pu mettre en pratique nos connaissances théoriques et pratique
acquises durant notre formation à la Faculté des sciences économique et Gestions de Nabeul, tout en
étantconfrontéaudifficultéréellesdumondedutravailetdelacohérenceentrelesmembred’équipes.
Ce stage a été très enrichissant pour nous en termes d’expérience techniques , car il nous a permis de
se familiariser avec l’environnement de travail professionnel et les technologie appliqué dans notre
domaine de développement informatique.
Le but de ce travail est consisté à concevoir et développer une application hybride et deux dashboard
admin qui permet au futurs clients ou les clients existant de OMRANEstate© d’effectuer leur tâches
plus rapidement avec notre projet.
La réalisation de ce travail a nécissité au début de faire une étude approfondi sur le logiciel existant
et son architecture aussi que la base de données pour pouvoir la manipuler et intigré notre projet,
qui nous a permis de faire une étude théorique au cours de laquelle nous avons étudié et critiqué
l’existant.
La solution retenue était étudiée profondément pour déterminer les besoins fonctionnels et non
fonctionnels de l’application, et présenter les interfaces approximatifs de l’application.
en suite nous avons décrit l’architecture phyisque de notre système.
de plus nous avons lister les technologies et logiciels utilisé au cours de notre stage.
la phase de la conception a couvert tous les aspects conceptuels : en vue statique (diagramme de cas
d’utilisation, diagramme de classe) et en vue dynamique les diagramme de séquence.
84

97. à l’étape de realisation nous avons enchâiné avec une série des captures d’écran illustrant le fonc-
tionnement de l’application.
ce travail a représenté pour nous une véritable occasion pour approfondir nos connaissances tout en
rassemblant nos acuis théoriques à l’environnement pratique en utilisant l’UML comme langage de
modélisation, SSMS pour la gestion de la base de données, et Flutter/Dart pour développer la partie
front-end Mobile et Blazor/Asp.net pour développer la partie front-end Web.
85

98. Rapport de Stage FSEG, Nabeul 2021 Conception et développmenet
d’une application
web pour la gestion des projets immobiliers
Résume
Ce travail s’inscrit dans le cadre de l’accomplissement d’un stage de fin d’étude à la faculté des
Sciences Economique et de Gestion de Nabeul (FSEGN) .
Ce projet a été effectué au sein de la société YASMINEES ENGINEERING SYSTEMS. Il a pour objectif
la conception et la réalisation d’une application mobile et sites web pour la gestion des projets immo-
biliers .
Nous avons décrit la méthode de travail et le language de conception adoptée :
.Net comme environement de travail Génerale et SSMS 1 pour la gestion de la base de données.
pour la partie front-end nous avons utilisé Flutter et Dart pour le développement mobile ainsi que
Blazor et Asp.net pour le développement web.
Pour la partie back-end nous avons utilisé Asp.net pour implimenté les serveurs API 2.
Summary
This work is part of the completion of an end-of-study internship at the Faculty of Economics and
Management of Nabeul (FSEGN) .
This project was carried out within the company YASMINEES ENGINEERING SYSTEMS. Its objec-
tive is the design and production of a mobile application and websites for the management of real
estate projects.
We have described the working method and the design language adopted :
.Net as General working environment and SSMS for database management.
for the front-end part we used Flutter and Dart for mobile development as well as Blazor and Asp.net
for web development.
For the back-end part we used Asp.net to implement the API servers .
1. Sql Server Management Studio
2. Application Programming Interface
i

99. NETOGRAPHIE BIBLIOGRAPHIE
[1] Modèle méthode scrum. https://dtecnologia.cl/consultora-informatica/servicio/
desarrollo-de-software/. [En ligne; accès le 10-may-2021].
[2] YES. Descriptionyes.http : //www.yasminees.com.[EnLigne;accsle08−mars−2021].
[3] Amaury. Le cycle en v, 4 février 2009. [En ligne; accès le 15-may-2021].
[4] Florent Lothin. Rôles de scrum, 10 février 2016. [En ligne; accès le 15-may-2021].
[5] Kahina Kabri. Scrum vs cycle en v. https://blog.dcube.fr/index.php/2014/04/28/
scrum-vs-cycle-en-v-2-2/, 2014. [En ligne; accès le 15-may-2021].
[6] Pascal Roques. UML2 modéliser une application Web. EYROLLES, 2007. [Accès le 20-may-2021].
[7] Equipe microsoft. What is sql server management studio (ssms)? https://docs.microsoft.com/
en-us/sql/ssms/sql-server-management-studio-ssms?view=sql-server-ver15, 09/11/2019.
[En ligne; accès le 30-may-2021].
[8] DART. Dart overview. https://dart.dev/overview. [En ligne; accès le 30-may-2021].
[9] DART. Visite guidée du langage c. https://docs.microsoft.com/fr-fr/dotnet/csharp/
tour-of-csharp/, 28/01/2021. [En ligne; accès le 30-may-2021].
[10] him0000. Htmlintroduction. https://www.geeksforgeeks.org/html-introduction/,05Apr,2021.
[En ligne; accès le 30-may-2021].
[11] Martin Heller. What is kotlin? the java alternative explained. https://www.infoworld.com/article/
3224868/what-is-kotlin-the-java-alternative-explained.html, 2020. [En ligne; accès le 30-
may-2021].
ii

100. [12] Visual Studio. Bienvenue dans l’ide visual studio. https://docs.microsoft.com/fr-fr/
visualstudio/get-started/visual-studio-ide?view=vs-2019, 19/03/2019. [En ligne; accès le
30-may-2021].
[13] Android Studio. Meet android studio. shorturl.at/dwGSX, 2021-05-18. [En ligne; accès le 30-may-
2021].
[14] Microsoft. Blazor-blazor. https://fr.xcv.wiki/wiki/Blazor, 2018. [En ligne; accès le 30-may-
2021].
[15] Radosław Szeja. What is flutter? https://www.netguru.com/blog/
is-flutter-a-programming-language, Mar 26, 2021. [En ligne; accès le 30-may-2021].
[16] IIS.com. Iis overview. https://www.iis.net/overview. [En ligne; accès le 30-may-2021].
[17] Postman.com. What is postman? https://www.postman.com. [En ligne; accès le 30-may-2021].
[18] tice Education. Draw.io : un outil pour dessiner des diagrammes en ligne. https:
//www.tice-education.fr/tous-les-articles-er-ressources/articles-internet/
819-draw-io-un-outil-pour-dessiner-des-diagrammes-en-ligne, 24 janvier 2014. [En
ligne; accès le 30-may-2021].
iii