RAPPORT DE STAGE DE PROJET DE FIN D’ETUDES

LICENCE EN INFORMATIQUE ET MULTIMEDIAS

Option : Informatique et multimédia

Intitulé du stage
Développement d’une application de design d’intérieur

Réalisé par
Rabah Feriel

Entreprise d’accueil

Bridges Engineering

Encadrant Entreprise
Mr Wassim Medini
Encadrant SESAME
Mme Sameh Bennour

Année Universitaire
2021-2022
 Dédicaces

A celle qui a attendu avec patience les fruits de sa

bonne éducation et de ses dévouements

A ma chère mère

A celui qui s’est changé la nuit en jour pour

M’assurer les bonnes conditions

A mon cher père

A mon cher frère et ma chère sœur qui m’ont beaucoup

encouragés et soutenues

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

ce travail et auxquels je dois être reconnaissante

Je dédie ce modeste travail

 Remercîments

Je tiens à exprimer ma gratitude et mes remerciements à tous ceux qui m’ont guidé, aidé et
supervisé durant l'élaboration de ce projet dont notamment :

Mme. Bennour Sameh, mon encadrant pédagogique pour son soutien, sa disponibilité et ses
conseils tout au long de la réalisation de ce travail, et aussi pour sa démarche pédagogique qui m’a
aidé à cerner ma problématique.

Mr. Medini Wassim, mon encadrant technique pour son encouragement, ses conseils, et son soutien
qu’il m’a apporté pour la réalisation de ce projet. Je suis également reconnaissante pour toutes les
informations qu’il m’a transmises

Aux membres du jury, qui me font un grand honneur en acceptant d’évaluer ce modeste travail
 Table des matières

INTRODUCTION GENERALE ______________________________________________________________ 10

Chapitre 1 : Cadre du projet __________________________________________________________ 11

Introduction __________________________________________________________________________ 12
1. Présentation d’accueil _____________________________________________________________ 12
1.1. Présentation de l’organisme _____________________________________________________ 12
1.2. Présentation de service _________________________________________________________ 12
2. Problématique ___________________________________________________________________ 13
3. Etude de l’existant ________________________________________________________________ 13
3.1. Description de l’existant ________________________________________________________ 13
3.1.1. Etude de l’application Buildshop ______________________________________________ 13
3.1.2. Etude de l’application Houzz _________________________________________________ 14
3.1.3. Etude de l’application Havenly _______________________________________________ 15
3.1.4. Etude de l’application Block renovation ________________________________________ 15
3.2. Critique de l’existant ___________________________________________________________ 16
3.3. Solution envisagée ____________________________________________________________ 16
4. Choix de méthodologie ____________________________________________________________ 17
4.1. Présentation de la méthode SCRUM ______________________________________________ 17
4.2. La répartition des rôles dans Scrum _______________________________________________ 17
Conclusion ___________________________________________________________________________ 18

Chapitre 2 : Analyse et spécification des besoins __________________________________________ 19

Introduction __________________________________________________________________________ 20
1. Identification des acteurs ___________________________________________________________ 20
2. Besoins fonctionnels ______________________________________________________________ 20
3. Besoins non fonctionnels ___________________________________________________________ 20
4. Diagramme de cas d’utilisation ______________________________________________________ 21
4.1. Définition ___________________________________________________________________ 21
4.2. Diagramme de cas d’utilisation global _____________________________________________ 21
4.1. Diagrammes de classe __________________________________________________________ 22
4.1.1. Définition ________________________________________________________________ 22
4.1.2. Diagramme de classe global __________________________________________________ 22
Conclusion ___________________________________________________________________________ 23

Chapitre 3 : Architecture et environnement de travail _____________________________________ 24

Introduction __________________________________________________________________________ 25
1. MEAN STACK __________________________________________________________________ 25
1.1. NodeJS _____________________________________________________________________ 25
1.2. AngularJS ___________________________________________________________________ 25
1.3. ExpressJS ___________________________________________________________________ 26
1.4. MongoDB ___________________________________________________________________ 26
2. Langages de développement ________________________________________________________ 26
2.1. HTML (Hypertext Markup Language) _____________________________________________ 26
2.2. CSS (Cascading Style Sheet) ____________________________________________________ 26
2.3. JavaScript ___________________________________________________________________ 27
2.4. TypeScript ___________________________________________________________________ 27
3. Environnement logiciel ____________________________________________________________ 27
 3.1. VS code _____________________________________________________________________ 27
3.2. Postman _____________________________________________________________________ 28
3.3. StarUML ____________________________________________________________________ 28
4. Framework d’interface ____________________________________________________________ 28
5. Architecture de l’application ________________________________________________________ 29
Conclusion ___________________________________________________________________________ 29

Chapitre 4 : Réalisation ______________________________________________________________ 30

Introduction __________________________________________________________________________ 31
1. Backlog produit __________________________________________________________________ 31
2. Déroulement des sprints ___________________________________________________________ 32
2.1. Sprint 0 : « Inscription » ________________________________________________________ 32
2.1.1. Conception détaillée de sprint 0 _______________________________________________ 32
2.1.2. Développement de sprint 0___________________________________________________ 33
2.1.3. Tests relatifs au sprint 0 _____________________________________________________ 36
2.2. Sprint 1 : « Authentification » ___________________________________________________ 36
2.2.1. Conception détaillée de sprint 1 _______________________________________________ 36
2.2.2. Développement de sprint 1___________________________________________________ 38
2.2.3. Test de sprint 1 ____________________________________________________________ 40
2.3. Sprint 2 : « Gestion de profil / Consulter listes des profils des architectes » ________________ 40
2.3.1. Conception détaillée de sprint 2 _______________________________________________ 40
2.3.2. Développement de sprint 2___________________________________________________ 44
2.3.3. Test de sprint 2 ____________________________________________________________ 48
2.1. Sprint 3 : « Configurer dashboard » _______________________________________________ 48
2.1.1. Développement du sprint 3 __________________________________________________ 48
2.1.2. Test de sprint _____________________________________________________________ 48
2.2. Sprint 4 : « Prise de rendez-vous » ________________________________________________ 49
2.2.1. Conception détaillée de sprint 4 _______________________________________________ 49
2.2.2. Développement de sprint 4___________________________________________________ 49
2.2.3. Test de sprint 4 ____________________________________________________________ 50
Conclusion ___________________________________________________________________________ 50
CONCLUSION GENERALE _____________________________________________________________ 52

WEBOGRAPGIE____________________________________________________________________ 53
 Table des figures
Figure 1 : Site BuildShop ________________________________________________________________ 13
Figure 2 : Site Houzz ___________________________________________________________________ 14
Figure 3 : Site Havenly __________________________________________________________________ 15
Figure 4 : Site Block Renovation __________________________________________________________ 16
Figure 5 : Schéma d’un cycle de SCRUM ___________________________________________________ 17
Figure 6 : Diagramme de cas d'utilisations global ____________________________________________ 21
Figure 7 : Diagramme de classe global _____________________________________________________ 23
Figure 8 : La pile "MEAN STACK" ________________________________________________________ 25
Figure 9 : Architecture du système _________________________________________________________ 29
Figure 10 : Diagramme de cas d'utilisation d'inscription _______________________________________ 32
Figure 11 : Diagramme de séquence du scénario d'inscription ___________________________________ 33
Figure 12 : Page d'accueil _______________________________________________________________ 34
Figure 13 : Pop-up d'inscription __________________________________________________________ 35
Figure 14 : Champs non remplis __________________________________________________________ 35
Figure 15 : Adresse mail déjà existante _____________________________________________________ 36
Figure 16 : Diagramme de cas d'utilisation d'authentification ___________________________________ 36
Figure 17 : Diagramme de séquence du scénario d'authentification _______________________________ 38
Figure 18 : Pop-up d'authentification ______________________________________________________ 39
Figure 19 : Champs non valides ___________________________________________________________ 39
Figure 20 : Diagramme de cas d'utilisation de gestion du profil __________________________________ 40
Figure 21 : Diagramme de séquence du scénario de gestion de profil _____________________________ 43
Figure 22 : Diagramme de séquence de "consulter listes des profils des architectes __________________ 44
Figure 23 : Formulaire du profil __________________________________________________________ 44
Figure 24 : Formulaire de profil éditable ___________________________________________________ 45
Figure 25 : Pop-up après création de profil __________________________________________________ 45
Figure 26 : Profil crée __________________________________________________________________ 46
Figure 27 : Pop-up après modification de profil ______________________________________________ 46
Figure 28 : Liste des profils des architectes __________________________________________________ 47
Figure 29 : Dashboard de l'architecte ______________________________________________________ 48
Figure 30 : Diagramme de séquence de prise de rendez-vous ____________________________________ 49
Figure 31 : Prise de rendez-vous __________________________________________________________ 50
 Liste des tableaux
Tableau 1 : Critiques techniques de BuildShop _______________________________________________ 14
Tableau 2 : Critiques techniques de Houzz __________________________________________________ 14
Tableau 3 : Critiques techniques de Havenly _________________________________________________ 15
Tableau 4 : Critiques techniques de Block Renovation _________________________________________ 16
Tableau 5 : Description du diagramme de cas d'utilisation globale _______________________________ 22
Tableau 6 : Description du diagramme de classes _____________________________________________ 23
Tableau 7 : Backlog produit ______________________________________________________________ 31
Tableau 8 : Scénario d'inscription _________________________________________________________ 32
Tableau 9 : Scénario d'authentification _____________________________________________________ 37
Tableau 10 : Scénario de création de profil __________________________________________________ 41
Tableau 11 : Scénario de modification de profil ______________________________________________ 41
Tableau 12 : Scénario du cas d'utilisation "consulter listes des profils des architectes" _______________ 42
 Table des logos
Logo 1 : Hypertexte Markup Language _____________________________________________________ 26
Logo 2 : Cascading Style Sheet ___________________________________________________________ 26
Logo 3 : JavaScript _____________________________________________________________________ 27
Logo 4 : TypeScript _____________________________________________________________________ 27
Logo 5 : Visual Studio Code ______________________________________________________________ 27
Logo 6 : Postman ______________________________________________________________________ 28
Logo 7 : StarUML ______________________________________________________________________ 28
Logo 8 : Bootstrap _____________________________________________________________________ 28
 INTRODUCTION GENERALE

Depuis la découverte de l’informatique, des nombreuses activités de la vie courante ont été simplifiées.
Actuellement les individus peuvent facilement traiter des informations en se servant des logiciels et des
réseaux informatiques. Grâce à l’évolution technologique, le monde a constaté qu’il faut informatiser tous
les domaines pour assurer la continuité surtout après l’apparition du virus Covid19.L’informatique se sert
de nombreux outils pour pouvoir transmettre les informations, c’est en effet un moyen de recherche à la
fois simple et rapide permettant à tout le monde d’obtenir des informations sur divers sujets.

Dans cette perspective, et dans le cadre du stage de fin d’études, réalisé au sein du startup Bridges
Engineering, on va s’intéressait au développement d’une application web « Xvive » pour mettre en relation
les architectes tunisiens et les clients américains avec des outils qui sont considéré performant et solide «
NodeJS, Angular, ExpressJS » en se basant sur l’architecture trois tiers pour garantir la bonne gestion,
performance et rapidité de notre application.

Le présent rapport, qui expose ce travail, est composé de quatre chapitres structurés comme suite :

Dans le premier chapitre, on va présenter l'organisme d'accueil et on déduira l'étude de l’existant de notre
application web.

Dans le deuxième chapitre, on va identifier les besoins fonctionnels et non fonctionnels ainsi que les
acteurs de notre application avec la méthodologie adoptée.

Dans le troisième chapitre, on va présenter les différentes outils et technologies qui ont servis à
l’élaboration de ce travail.

Dans le quatrième chapitre, on va élaborer une conception détaillée de notre projet ainsi qu’on va
présenter les différentes interfaces réalisées.

Finalement, le rapport s'achève par une conclusion générale rappelant les réalisations essentielles de notre
travail.

10
Chapitre 1 : Cadre du
projet

11
Introduction
Ce chapitre sera consacré d’abord à présenter l’environnement dans lequel le projet a été mené. Ensuite, on
va présenter l’étude préalable qui est une démarche nécessaire pour avoir une vision globale sur notre
projet. Cette étude nous mène à élaborer la problématique et les objectifs du projet, puis on finira par la
solution proposée.

1. Présentation d’accueil

1.1. Présentation de l’organisme

Bridges Engineering International est une société de services informatiques spécialisée dans l’étude, le
conseil et le développement informatique. Créé en 2021 et intervenant aussi bien aux États-Unis
d’Amérique qu’en Tunisie, Bridges a acquis un savoir-faire, des compétences et de l’expérience lui
permettant de mener à bien tout projet informatique avec tous ses aspects (spécification, conception,
développement, test, validation, déploiement, assistance et maintenance).

Ses atouts et ses valeurs lui permettent de fidéliser ses clients et d’attirer d’autres.

Ses atouts sont :

• Une qualité irréprochable : dans les produits et les prestations ce qui garantit une croissance
meilleure.

• Des délais respectés : car un projet n’a de valeur que s’il est livré au bon moment.

• Un coût bien étudié : optimisation de la gestion des ressources afin de réduire les coûts et en
faire profiter ses clients

Ses valeurs fondamentales sont :

• Le sens du client.

• Le respect des engagements.

• La performance.

• L’innovation.

• La solidarité et le respect humain.

1.2. Présentation de service

• Développement logiciel

• Développement Web

• Développement mobile (Android, IOS)

12
 • Maintenance et Support

• Testing et Validation

2. Problématique

Bien que nous ayons de grands talents en Tunisie, nos architectes ont du mal à se connecter à la demande
internationale à cause de l’accès limité aux opportunités à l’étranger.

D’autre part, les propriétaires de maisons aux état unis ont du mal à renouveler leurs maisons à cause de la
pénurie d'architectes et de décorateurs d'intérieur pour les petits projets après l'explosion du marché du
logement ce qui rend ces derniers mis à côté et les propriétaires peuvent attendre des mois pour obtenir de
l'aide en matière d'architecture.

3. Etude de l’existant

3.1. Description de l’existant

L’étude de l’existant est une phase primordiale pour la réalisation d’un projet. En effet elle consiste à
observer et à analyser les solutions existantes puis à déterminer leurs points faibles et leurs points forts afin
de les prendre en considération lors de la réalisation de l’application en question. Elle comporte trois
parties : description de l’existant, critique de l’existant et proposition d’une solution.

3.1.1. Etude de l’application Buildshop

Buildshop est un logiciel de gestion de construction. Il fournit aux constructeurs la possibilité de

développer leurs activités en les offrant des différents outils à utiliser.

Figure 1 : Site BuildShop

Avantages Inconvénients

13
 o Comprend une version mobile. o Comprend une version payante.
o Comprend un système de messagerie. o Comprend une version gratuite mais
avec des fonctionnalités limitées.
o Les fonctionnalités destinées aux
architectes sont comprises que dans la
version payante.
o Mauvais design.

Tableau 1 : Critiques techniques de BuildShop

3.1.2. Etude de l’application Houzz

Houzz est un site web qui offre des services pour améliorer l’architecture, le design intérieur et la
décoration des maisons.

Figure 2 : Site Houzz

Avantages Inconvénients

o Facile à utiliser. o Quelques services sont payants.

o Comprend une version mobile. o La communication entre l’architecte et
o Comprend un système de messagerie. ses clients n’est valable que dans la
version payante.

Tableau 2 : Critiques techniques de Houzz

14
 3.1.3. Etude de l’application Havenly

Havenly est un moyen pratique pour la décoration des maisons pièces par pièces en associant les clients
avec un architecte dédié.

Figure 3 : Site Havenly

Avantages Inconvénients

o Facile à utiliser. o Pas de prise de rendez-vous entre

o Comprend un système de messagerie. l’architecte et son client.
o Contient les fonctionnalités nécessaires
pour la rénovation.
o Comprend un quiz pour connaître le
style du client.

Tableau 3 : Critiques techniques de Havenly

3.1.4. Etude de l’application Block renovation

Block renovation est une plateforme dédiée à aider les propriétaires et les architectes à mieux construire
ensemble.

15
 Figure 4 : Site Block Renovation

Avantages Inconvénients

o Facile à utiliser. o Le contact ne se fait qu’entre des

o Contient les fonctionnalités nécessaires architectes et des clients du même
pour la rénovation. pays.
o Comprend un système de prise de
rendez-vous.

Tableau 4 : Critiques techniques de Block Renovation

3.2. Critique de l’existant

D’après ce qui a été auparavant et malgré leurs fonctionnalités, on constate que la plupart de ces
applications web offrent des fonctionnalités assez similaires. D’une autre part, on remarque que ces
applications ne sont pas totalement gratuites ce qui présente parfois un obstacle pour quelques clients. Mais
on a trouvé que l'application "Block renovation" était la solution la plus proche de l'application qu’on va
développer et avec des fonctionnalités presque similaires.

3.3. Solution envisagée

Pour donner suite aux constatations faites à l'issue de l'étude de la situation existante, on propose de créer
une application simple et efficiente avec trois tiers et développée par des technologies solides, rapides et
performantes (Angular, nodeJS, expressJS) qui vont assurer la bonne manipulation des différentes
opérations. La solution est de concevoir et développer une application web permettant de satisfaire au
maximum possible les différents besoins des architectes et leurs clients et assure la connexion entre eux à
travers une prise de rendez-vous. Aussi elle doit contenir une interface conviviale, graphiquement attirante
et moderne.

16
4. Choix de méthodologie

Au cours du développement des projets informatiques, il est indispensable de respecter une démarche bien
déterminée pour assurer un bon rendement de développement en termes de qualité et de productivité. C’est
pour cela que le choix de la méthodologie en informatique est primordial. Les méthodologies de
développement suivent une séquence d’étapes ordonnées qui permet d’obtenir un système informatique
performant qui répond aux différents besoins des utilisateurs dans des intervalles de temps.

4.1. Présentation de la méthode SCRUM

SCRUM est l’une des méthodes les plus utilisées pour la gestion des projets informatiques. Son objectif est
d’offrir plus de souplesse à l’équipe. Un projet qui suit « SCRUM » comporte un « Product backlog » qui
représente une liste ordonnée des fonctionnalités à développer pour atteindre un objectif bien déterminé.
De son tour le « Product backlog » est divisé en un « sprint backlog » qui est basé sur la division des flux
de travail en « Sprint » qui est un intervalle de temps généralement entre deux et quatre semaines. À la fin
de chaque sprint il y aura un livrable qui présente de son tour les fonctionnalités accomplies.

4.2. La répartition des rôles dans Scrum

Scrum à trois rôles ;

Scrum master : C’est le chef d’équipe qui assure la compréhension et l’exécution de Scrum. Il contrôle
l’équipe et organise le travail.

Product Owner : C’est l’expert produit qui représente les parties prenantes et peut être aussi le client, le
propriétaire du projet, ou le chef d’entreprise.

Scrum Team : Est un groupe de membres qui travaille sur l’exécution du produit (développeurs,
programmeurs, designers...).

Figure 5 : Schéma d’un cycle de SCRUM

17
Conclusion
Dans ce premier chapitre, on a défini le champ de notre étude suivi d’une étude de l’existant afin de
préciser notre objectif à atteindre vers la fin accompagnée d’une solution proposée et le choix de la
méthodologie appliquée. Dans le chapitre qui suit, on présente la spécification des besoins.

18
Chapitre 2 : Analyse
et spécification des
besoins

19
Introduction
Ce chapitre vise à capter les besoins et les rôles des utilisateurs qui utilisent l’application. Dans un premier
lieu, on commence par définir les acteurs, par la suite on spécifie les besoins fonctionnels et non
fonctionnels. Au niveau de la deuxième partie on va analyser ces besoins par l’insertion de diagramme des
cas d’utilisations global et diagramme de classes.

1. Identification des acteurs

Un acteur définit un rôle joué par une personne externe qui interagit avec le système. Il peut être parmi les
utilisateurs du système et parmi les responsables de sa configuration.

Cette application est composée de 2 acteurs :

• Architecte : il peut s’authentifier et créer son propre compte.

• Client : c’est le propriétaire de maison. Il peut s’authentifier et consulter les profils des architectes
pour prendre un rendez-vous.

2. Besoins fonctionnels

Les besoins fonctionnels sont les fonctionnalités et les options que l’application fournira à l’utilisateur.

Notre application fournira les fonctionnalités suivantes :

• Inscription (Architect, propriétaire de maison) : s’inscrire sur la plateforme en tant qu’architecte ou

propriétaire de maison.
• Authentification (Architect, propriétaire de maison)
• Prise de rendez-vous (Propriétaire de maison) : l’utilisateur peut prendre un rendez-vous avec un
architecte.
• Consulter les comptes des architectes (Propriétaire de maison).
• Soumission des images (Propriétaire de maison) : le client peut soumettre des images pour éclaircir
les idées dont il veut appliquer dans sa maison.
• Gestions de profil (Architecte).

3. Besoins non fonctionnels

Les besoins non fonctionnels définissent les options internes essentielles pour améliorer le fonctionnement
du système. Pour cela, notre future application doit répondre aux critères suivants :

• Sécurité : l’application doit garantir la sécurité des données des utilisateurs ce qui nécessite :
o Un mot de passe enregistré dans la base de données crypté.

20
 o Un jeton après chaque authentification doit être généré (le jeton c’est un jeton généré en
fonction des mots de passe et du nom de l’utilisateur pendant une période bien définie).
L’utilisateur peut profiter du jeton qui offre un accès à une ressource spécifique pour une
période précise sur notre plateforme.
• Performance : Afin d’offrir un service de qualité, l’application doit être performante au niveau de
temps de réponse.
• Fiabilité : L’application doit toujours répondre à l’exigence afin de fonctionner sans aucune erreur
ou défaillance.
• La disponibilité : L’application doit être disponible à tout instant pour être utilisée par n’importe
quel utilisateur, elle doit être accessible facilement via n’importe quel navigateur.

4. Diagramme de cas d’utilisation

4.1. Définition
Un diagramme de cas d’utilisation définit le comportement d’un système informatique. Il exprime les
besoins des utilisateurs du système, identifie les fonctions les plus importantes et représente les
interactions, les acteurs et leurs attentes vis-à-vis du système.

4.2. Diagramme de cas d’utilisation global

Dans la figure qui suit, on va présenter une vue globale du système :

Figure 6 : Diagramme de cas d'utilisations global

21
 Cas d’utilisation Description

S’inscrire Le système permet à l’utilisateur de créer un

compte.

S’authentifier Le système permet à l’utilisateur de

s’authentifier à son compte pour accéder aux
interfaces dédiées.

Consulter dashboard Le système permet à l’architecte d’avoir

accès à un dashboard dédié.

Gérer profil Le système permet à l’architecte de gérer son

profil.

Consulter listes des profils des architectes Le système permet au propriétaire de maison
d’accéder à la liste des profils des
architectes.

Prendre rendez-vous Le système permet au propriétaire de maison

de prendre un rendez-vous avec un
architecte.

Soumettre des idées Le système permet au propriétaire de maison

d’ajouter des images qui lui inspire.

Tableau 5 : Description du diagramme de cas d'utilisation globale

4.1. Diagrammes de classe

4.1.1. Définition

Un diagramme de classes est un diagramme UML dont le but est de décrire précisément la structure
statique d’un système informatique à travers la modélisation des classes du système, y compris les
propriétés et les méthodes de chaque classe, et les diverses relations qui peuvent exister entre les eux.

4.1.2. Diagramme de classe global

Cette figure représente le diagramme de classe global de notre système :

22
 Figure 7 : Diagramme de classe global

Classe Description

Utilisateur La classe abstraite Utilisateur qui se

représente en 2 rôles : architecte et
propriétaire de maison.

Architecte L’un des utilisateurs de l’application qui va

être identifié selon son rôle.

Propriétaire de maison L’un des utilisateurs de l’application qui va

être identifié selon son rôle.

Profil La classe profil représente les informations

des profils.

Rendez-vous La classe Rendez-vous représente les

informations des rendez-vous.

Tableau 6 : Description du diagramme de classes

Conclusion
Dans ce chapitre, on a spécifié les principaux besoins dont notre application doit fournir à l’utilisateur
accompagnés d’un diagramme de cas d’utilisation global et diagramme de classes. Le prochain chapitre
sera consacré à la conception.

23
 Chapitre 3 :
Architecture et
environnement
de travail

24
Introduction
Dans cette partie on va présenter les différents langages et technologies utilisés. Ensuite, on va décrire
l’architecture générale de l’application et le flux des données.

1. MEAN STACK

L’application qu’on va développer est une application MEAN qui est une pile logicielle JavaScript gratuite
et à code source libre. « MEAN » signifie MongoDB, Express.js, AngularJS, et Node.js.

L’un des principaux avantages de la pile MEAN est l’utilisation d’un langage unique, java script, qui
s’exécutent à tous les niveaux de l’application qui est une approche efficace et moderne de développement
web.

Cette figure ci-dessous représente l’interaction entre les différentes technologies de « MEAN STACK » :

Figure 8 : La pile "MEAN STACK"

1.1. NodeJS
NodeJS est un environnement d’exécution Javascript qui nous permet d’exécuter JavaScript coté serveur
pour construire notre application. Il est utilisé notamment comme plateforme de serveur Web qui utilise la
machine virtuelle V8.

1.2. AngularJS
Angular [1] est un Framework open source qui permet de créer des applications web de type « Single page
application ». Il est basé sur le langage JavaScript et permet de séparer les données, les vues et les
différentes actions que l'on peut effectuer.

25
 1.3. ExpressJS
ExpressJs est un Framework Node.js gratuit et open source. Il a des fonctionnalités, des outils, des plugins
et des packages qui aident à développer les applications web et mobile basées sur NodeJS plus facilement.
Ainsi qu’il est le Framework standard pour le développement du serveur en Node.js.

1.4. MongoDB
Dans le cadre de ce projet on a eu besoin du MongoDB qui est un système de gestion de base de données
(SGBD) NOSQL. Il repose sur des collections de documents au format JSON.C’est la première base de
données, permettant aux sociétés d'être plus rapides et évolutives. La plupart des entreprises de toutes les
tailles utilisent MongoDB pour créer de nouveaux types d'applications, améliorer la façon de travailler
avec ses clients. MongoDB est conçue pour l'évolution, les performances et la haute disponibilité, passant
de l'installation sur de simples serveurs, à des architectures complexes déployées sur plusieurs sites ainsi
qu’elle permet de lire et d'écrire très rapidement.

2. Langages de développement

2.1. HTML (Hypertext Markup Language)

Logo 1 : Hypertexte Markup Language

HTML (Hypertext Markup Language) qui est un type de langage informatique descriptif. [2] Il est utilisé
pour la mise en forme des pages Web et il permet aussi d'écrire de l'hypertexte et d'introduire des
ressources multimédias dans un contenu.

2.2. CSS (Cascading Style Sheet)

Logo 2 : Cascading Style Sheet

26
CSS (Cascading Style Sheet) [3] est un langage de style qui s’intéresse à la mise en forme du contenu
intégré avec du HTML. Il permet de contrôler exactement l'affichage de chaque élément HTML dans le
navigateur et ainsi de présenter les documents avec la mise en forme de votre choix.

2.3. JavaScript

Logo 3 : JavaScript

JavaScript est un langage de script orienté objet permettant d’ajouter des fonctionnalités interactives et
d’autres contenus web dynamiques aux pages web.

2.4. TypeScript

Logo 4 : TypeScript

TypeScript [4] est un langage open source qui qui peut aider à construire et à gérer des projets JavaScript à
grande échelle. Il peut être considéré comme JavaScript avec des fonctionnalités supplémentaires comme
le typage statique, la compilation et la programmation orientée objet.

3. Environnement logiciel

3.1. VS code

Logo 5 : Visual Studio Code

27
Visual studio code est un éditeur de code open source supportant des différents langages.

3.2. Postman

Logo 6 : Postman

Postman est un client HTTP pour le test des API REST, livré sous format d’une extension chrome.

3.3. StarUML

Logo 7 : StarUML

C’est un logiciel de modélisation UML (Unified Modeling Language) open source

qui peut remplacer dans bien des situations des logiciels commerciaux et coûteux. Il est simple à utiliser
ainsi qu’il nécessite peu de ressource système.

4. Framework d’interface

Logo 8 : Bootstrap

Bootstrap [5] est un cadre de travail pour le développement frontale, gratuit et open source pour la création
de sites et d'applications Web. Il repose sur HTML, CSS et JavaScript (JS) pour faciliter le développement
de sites et d'applications réactives.

28
5. Architecture de l’application

L’architecture de notre application MEAN STACK se repose sur l’architecture en trois tiers. Comme
illustrée dans la figure ci-après, la solution qu’on a choisie obéit à la même structure laissant apparaitre les
tiers suivants :

• Un client qui n’est autre qu’un navigateur web permettant à son utilisateur d’accéder à l’application
via internet.

• Un serveur d’application.

• Un tiers de données qui n’est autre que le serveur de base de données.

Figure 9 : Architecture du système

Conclusion
Tout au long de ce chapitre on a présenté les différents langages de développement ainsi que les logiciels et
les framework utilisés. Et pour finir on a décrit l’architecture générale de l’application.

29
Chapitre 4 :
Réalisation

30
Introduction
Après avoir présenté l’environnement qui a servi à élaborer notre application, on entame la partie de la
réalisation. Dans ce chapitre, on va présenter nos sprints en décrivant la phase conceptuelle. Pour finir, on
illustrera quelques captures d’écran afin de décrire l’application sans oublier de présenter les résultats et les
problèmes rencontrés.

1. Backlog produit

Le backlog produit représente une liste des diverses fonctionnalités à développer d’une application. Les
éléments du backlog sont classés par priorité ce qui permet de définir l’ordre de réalisation.

On décrit dans cette partie le backlog produit de notre projet, illustré par le tableau ci- dessous.

Sprint Titre En tant que Je souhaite Estimation

(Jour)
0 S’inscrire • Architecte Créer un compte 5
• Propriétaire de
maison

1 S’authentifier • Architecte Avoir la 5

possibilité de se
• Propriétaire de connecter à
maison l’application grâce
à une adresse mail
et mot de passe
2 Gérer profil • Architecte Avoir accès au 15
profil afin de créer
et d’effectuer des
modifications sur
mon profil
Consulter liste des • Propriétaire de Consulter les
profils des maison profils des
architectes architectes
3 Configurer • Architecte Avoir accès à un 30
dashboard dashboard
4 Gestion, Prise de • Propriétaire de Prendre un 20
rendez-vous maison rendez-vous avec
un architecte.
5 Soumettre idée • Propriétaire de Soumettre les 10
maison idées qui me
plaisent
Tableau 7 : Backlog produit

31
2. Déroulement des sprints

2.1. Sprint 0 : « Inscription »

2.1.1. Conception détaillée de sprint 0

La figure ci-dessous représente le diagramme de cas d’utilisation d’inscription :

Figure 10 : Diagramme de cas d'utilisation d'inscription

Description textuelle de cas d’utilisation d’inscription :

Cas d’utilisation S’inscrire

Acteur Architecte, Propriétaire de maison

Précondition L’utilisateur se trouve sur la page d’accueil

Postcondition L’utilisateur se trouve sur la page d’authentification

Scénario 1. Sur la page d’accueil l’utilisateur clique sur le

bouton « Sign up »

2. L’utilisateur doit remplir le formulaire

3. Le système vérifier la validité des
informations de saisie.
4. L’utilisateur se trouve sur le dashboard
Scénario d’exception Un message d’erreur s’affiche si les champs ne sont
pas validés.

Tableau 8 : Scénario d'inscription

32
 Diagramme de séquence d’inscription :

Figure 11 : Diagramme de séquence du scénario d'inscription

Cette figure montre le séquencement des interactions entre l’utilisateur, le « frontend », le « backend » et la
base de données. En effet l’inscription est une étape nécessaire que chaque utilisateur doit l’établir pour
avoir un compte. L’utilisateur est obligé de remplir un formulaire dont il va surtout mentionner son rôle. Si
les champs du formulaire sont validés, un nouvel utilisateur va être enregistré dans la base de données.

2.1.2. Développement de sprint 0

Après avoir préparé la conception du sprint 0, on va illustrer maintenant les différentes interfaces. On
commence par présenter la page d’accueil qui va être affichée en premier lieu. Cette page renseigne
l’utilisateur sur le contenu de notre application. Elle se compose de différentes sections comme « Our
services » qui est une section descriptive de nos services, « Explore some ideas» qui représente une petite
galerie d’images, «Our spaces» qui est une section descriptive des deux intervenants (Architecte et
propriétaire de maison).

33
Figure 12 : Page d'accueil

34
L’utilisateur doit créer un compte afin d’avoir accès à l’application en remplissant les champs nécessaires
et en spécifiant son rôle « Architecte » ou « Propriétaire de maison ».

L’interface d’inscription s’affiche sous forme d’un pop en cliquant sur le bouton « Sign up » de la page
d’accueil.

Figure 13 : Pop-up d'inscription

Si les champs ne sont pas tous remplis, un pop-up contenant le message « Please fill all required fields »
s’affiche comme le montre la figure ci-dessous :

Figure 14 : Champs non remplis

35
Dans le cas où l’adresse mail est déjà existante, un pop-up contenant le message « Email already exist »
s’affiche.

Figure 15 : Adresse mail déjà existante

2.1.3. Tests relatifs au sprint 0

Après la réalisation de ce sprint, on a effectué les tests pour savoir si on a pu atteindre les objectifs définis.

• Ce qui s’est bien passé :

- Les taches de ce sprint se sont bien déroulées. Il n’y a pas eu des problèmes au niveau de ce sprint.

2.2. Sprint 1 : « Authentification »

2.2.1. Conception détaillée de sprint 1

La figure ci-dessous représente le diagramme de cas d’utilisation d’authentification :

Figure 16 : Diagramme de cas d'utilisation d'authentification

36
 Description textuelle de cas d’utilisation d’authentification :

Cas d’utilisation S’authentifier

Acteur Architecte, Propriétaire de maison

Précondition L’utilisateur se trouve sur la page d’accueil

Postcondition Chaque utilisateur se trouve sur un dashboard

associé à lui.

Scénario 1. Sur la page d’accueil l’utilisateur clique sur

le bouton « Sign in »

2. L’utilisateur doit entrer une adresse mail et

un mot de passe
3. Le système vérifier la validité des
informations de saisie.

Scénario d’exception Un message d’erreur s’affiche si les champs ne sont

pas validés.

Tableau 9 : Scénario d'authentification

37
 Diagramme de séquence d’authentification :

Figure 17 : Diagramme de séquence du scénario d'authentification

L’authentification est une étape nécessaire que chaque utilisateur doit l’établir pour accéder à notre
application, cette phase mène la sécurité de l’application. En demandant l’accès à l’application, l’utilisateur
est obligé de s’identifier via son email et son mot de passe. L’application vérifie l’existence de ce compte
dans sa base de données.

2.2.2. Développement de sprint 1

Après avoir préparé la conception du sprint 1, on va illustrer maintenant les différentes interfaces de la
partie d’authentification. On commence par présenter les premières interfaces relatives à ce sprint.

Le formulaire d’authentification s’affiche sous forme de pop-up. Il s’agit de saisir l’E-mail et le mot de
passe, et puis le système vérifie la validité de l’entrée.

38
 Figure 18 : Pop-up d'authentification

Dans le cas où l’un des champs est incorrecte, une alerte s’affiche.

Figure 19 : Champs non valides

39
 2.2.3. Test de sprint 1

Après la réalisation de ce sprint, on a effectué les tests pour savoir si on a pu atteindre les objectifs définis.

• Ce qui s’est bien passé :

-Les taches de ce sprint se sont bien déroulées. Il n’y a pas eu des problèmes au niveau de ce sprint.

2.3. Sprint 2 : « Gestion de profil / Consulter listes des profils des architectes »
2.3.1. Conception détaillée de sprint 2

La figure ci-dessous représente le diagramme de cas d’utilisation de gestion de profil :

Figure 20 : Diagramme de cas d'utilisation de gestion du profil

Description textuelle de cas d’utilisation de gestion de profil (Créer profil) :

Cas d’utilisation Créer profil

Acteur Architecte

Précondition L’architecte doit s’authentifier

Postcondition Profil crée

Scénario 1. L’architecte choisit la rebrique « Profile »

qui se trouve dans la sidebar.

2. Le formulaire de profil s’affiche.

3. L’architecte clique sur l’icône qui se trouve
en haut du formulaire.
4. L’architecte remplit le formulaire

5. L’architecte clique sur le bouton « save ».

40
 6. Un pop-up s’affiche avec le message
« Profile added successfuly »

7. Le système renvoie le profil créé.

Scénario d’exception Si l’un des champs remplie n’est pas valide, retour à
l’étape 2.

Tableau 10 : Scénario de création de profil

Description textuelle de cas d’utilisation de gestion de profil (Modifier profil) :

Cas d’utilisation Modifier profil

Acteur Architecte

Précondition Profil déjà crée

Postcondition Profil modifié

Scénario 1. L’architecte choisit la rebrique

« Profile » qui se trouve dans la sidebar.

2. Le formulaire de profil s’affiche en

récupérant les valeurs des champs
remplit lors de la création.
3. L’architecte clique sur l’icône qui se
trouve en haut du formulaire.
4. L’architecte modifie les champs
souhaités.

5. Il clique sur le bouton « save ».

6. Un pop-up s’affiche avec le message
« Profile edited successfuly »
7. Le système renvoie le profil après
modification.
Scénario d’exception En cas de défaut de saisie ou absence de
modification le système n’affiche pas la
modification.

Tableau 11 : Scénario de modification de profil

41
 Description textuelle de cas d’utilisation « Consulter listes des profils des architectes » :

Cas d’utilisation Consulter listes des architectes

Acteur Propriétaire de maison

Précondition Le propriétaire de maison association

Postcondition Le propriétaire de maison consulte listes des

architectes.

Scénario 1. Le propriétaire de maison clique sur la

rebrique « Our designers » de la Nav Bar.
2. Le système renvoi la listes des profils.

Tableau 12 : Scénario du cas d'utilisation "consulter listes des profils des architectes"

42
 Diagramme de séquence de gestion de profil (créer et modifier) :

Figure 21 : Diagramme de séquence du scénario de gestion de profil

Pour créer ou modifier un profil, l’architecte doit effectuer l’enchaînement présenté ci-dessus « Figure21 ».
Après la demande de l’interface, un formulaire s’affiche et le système vérifiera si le formulaire est vide.
Dans ce cas on se trouve devant deux scénarios :

• Si le formulaire est vide, l’architecte va créer son profil à travers la saisie de tous les champs.
43
 • Dans le cas où le formulaire est déjà rempli, l’architecte saisit les données à modifier.

Diagramme de séquence du cas d’utilisation consulter listes des profils des architectes :

Figure 22 : Diagramme de séquence de "consulter listes des profils des architectes

2.3.2. Développement de sprint 2

L’image ci-dessous représente l’interface de la rebrique « Profile »

Figure 23 : Formulaire du profil

Dans le cas où l’architecte clique sur l’icône « edit » qui se trouve en haut du formulaire, le système lui
donne l’accès pour remplir les champs et affiche le bouton « save ».

44
 Figure 24 : Formulaire de profil éditable

Lors du remplissage du formulaire pour la première fois, le système va donner accès à l’architecte pour
créer son profil.

Le pop-up suivant va être affiché après la création du profil :

Figure 25 : Pop-up après création de profil

Une fois le remplissage est fait, les images téléchargées par l’architecte seront affichées.

45
 Figure 26 : Profil crée

Dans le cas de modification de profile, l’architecte va modifier que les champs souhaités et le système va
récupérer la valeur des champs non modifiés.

La figure ci-dessous représente le pop-up qui s’affiche après la modification :

Figure 27 : Pop-up après modification de profil

46
La figure suivante illustre la partie concernant la consultation des profils des architectes. Cette interface est
accessible que pour le propriétaire de maison et lui permet la prise de rendez-vous avec un architecte en
cliquant sur le bouton « Pick an appointment ».

Figure 28 : Liste des profils des architectes

47
 2.3.3. Test de sprint 2

Après la réalisation de ce sprint, on a effectué les tests pour savoir si on a pu atteindre les objectifs définis.

• Ce qui s’est bien passé :

-Les taches de ce sprint se sont bien déroulées malgré qu’on ait rencontré quelques difficultés.

2.1. Sprint 3 : « Configurer dashboard »

2.1.1. Développement du sprint 3

Lors de l’authentification, l’architecte sera dirigé directement à son dashboard comme le montre la figure
ci-dessous.

Figure 29 : Dashboard de l'architecte

2.1.2. Test de sprint

Etant donné qu’on a rencontré des problèmes à cause des contraintes de temps, on a pu qu’implémenter
l’interface graphique pour ce sprint.

48
 2.2. Sprint 4 : « Prise de rendez-vous »
2.2.1. Conception détaillée de sprint 4

Diagramme de séquence de prise de rendez-vous :

Figure 30 : Diagramme de séquence de prise de rendez-vous

Après la consultation des profils des architectes, le propriétaire de maison peut choisir le profil de
l’architecte dont il veut. Ensuite, un formulaire s’affiche qui lui permet de sélectionner la date/heure. Le
système vérifiera si la date et l’heure sont déjà pris. Si c’est le cas, le système redirige le propriétaire de
maison vers la liste. Si non, un message de succès s’affiche.

2.2.2. Développement de sprint 4

La figure suivante représente le pop-up qui s’affiche pour fixer la date du rendez-vous :

49
 Figure 31 : Prise de rendez-vous

2.2.3. Test de sprint 4

Après la réalisation de ce sprint, on a effectué les tests pour savoir si on a pu atteindre les objectifs définis.

• Ce qui peut être mieux fait :

-La présentation de l’interface peut être mieux améliorée en intégrant un calendrier.

• Amélioration

-La partie fonctionnelle de ce sprint n’est pas encore accomplie à cause des contraintes de temps.

Conclusion
Dans ce chapitre, on a détaillé les différents sprints réalisés ainsi que les différentes interfaces qui
implémentent notre projet.

On évoquera dans la conclusion générale un résumé du travail effectué ainsi que nos acquis sur le plan
personnel et professionnel.

50
 CONCLUSION GENERALE
Au terme de ce rapport, on a pu conclure que ce stage de fin d’études nous a donné une occasion opportune
nous permettant de confronter l’acquis théorique à l’environnement pratique.

Ce travail de conception et de développement d’une application web « XVIVE » pour mettre en relation les
architectes tunisiens et les propriétaires de maison tout au long du stage nous a été bénéfique sur plusieurs
plans.

Sur le plan personnel, ce stage nous a permis de prendre certaines responsabilités et d’approfondir nos
connaissances théoriques et pratiques.

Sur le plan technique, nous avons appris à manipuler les Framework Angular et nodeJS et pleins d’autres
outils. On a également eu l’opportunité de maîtriser la conception en utilisant UML.

La communication était un facteur très important au niveau de la phase de réalisation pour concevoir
l’application souhaitée. On a aussi rencontré quelques difficultés au niveau de cette phase au niveau
temporelle mais on a pu surpasser ces problèmes grâce au bon encadrement.

Au début de notre stage, on a consacré du temps pour l’étude des besoins et cela pour recenser les
fonctionnalités qu’englobera notre application et mieux cerné les différentes exigences du projet. On a fait
de notre mieux pour faire le maximum et présenter un travail digne de notre formation, mais vu la durée
limitée de notre stage certains volets n’ont pas pu être achevés.

Finalement, plusieurs perspectives peuvent être entrevues :

• La prise rendez-vous.

• Configuration des différentes interfaces nécessaires.

51
 WEBOGRAPHIE
[1] https://monpetitdev.fr/cest-quoi-angular-definition/

[2] https://www.journaldunet.fr/web-tech/dictionnaire-du-webmastering/1203255-html-hypertext-markup-
langage-definition-traduction/

[3]https://developer.mozilla.org/fr/docs/Learn/CSS/First_steps/What_is_CSS

[4]https://www.codemotion.com/magazine/backend-dev/why-you-should-use-typescript-for-your-next-
project/

[5]https://www.lemagit.fr/definition/Bootstrap

52