REPUBLIQUE DU SENEGAL

Un peuple-un but-une foi

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

l’Innovation
Direction de l’Enseignement Supérieur Privé
Institut Supérieur d’Informatique

Mémoire de fin de cycle pour l’obtention de la licence

professionnelle en informatique appliquée à la gestion des
entreprises

Etude et mise en place d’une plateforme web de

location et de vente de bien immobilier

Présenté et soutenu par : Sous la direction de

M. El Hadji Mody NDIAYE M. Malle NDIAYE
Spécialité : INGENIEUR
INFORMATICIEN

Année Académique : 2021 - 2022

 REPUBLIQUE DU SENEGAL

Un peuple-un but-une foi

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

l’Innovation
Direction de l’Enseignement Supérieur Privé
Institut Supérieur d’Informatique

Mémoire de fin de cycle pour l’obtention de la licence

professionnelle en informatique appliquée à la gestion des
entreprises

Etude et mise en place d’une plateforme web de

location et de vente de bien immobilier

Présenté et soutenu par : Sous la direction de

M. El Hadji Mody NDIAYE M. Malle NDIAYE
Spécialité : INGENIEUR
INFORMATICIEN

Année Académique : 2021 - 2022

 DEDICACE
A mes chers parents en guise de reconnaissance et de gratitude pour leur
amour, leur patience, leurs soutiens et leurs encouragements. Aucun mot, aucune
dédicace ne pourrait exprimer notre respect, notre considération ainsi que
l’expression de notre profond amour.
Puisse Dieu vous accorder santé, bonheur et longue vie afin que nous pussions un
jour combler de joie vos vieux jours.

~I~
 REMERCIEMENTS
Après avoir rendu grâce à Dieu (SWT) et prié au nom du prophète (PSL),
nous tenons à remercier tous ceux qui de loin ou de près ont participé à
l’élaboration de ce mémoire :

✓ Mon encadreur Monsieur Mallé Ndiaye pour avoir bien voulu accepter la
direction de ce mémoire. Je lui témoigne de ma sincère gratitude tout en
saluant la compétence, la diligence et la patience dont il a toujours fait
preuve pendant ce long processus

✓ Mes parents et mes frères pour leur soutien moral et financier, ils n’ont
ménagé aucun effort pour la réussite de mes études et je leur en suis
reconnaissant

✓ Tout le corps professoral d’ISI, pour avoir contribué à ma formation.

~ II ~
 AVANT-PROPOS
L’Institut Supérieur d’Informatique (ISI) est un établissement
d’enseignement supérieur dont le projet pédagogique permet de transmettre la
pluralité des savoirs et des clés de lecture d’un monde fluide pour les futurs cadres.
Le groupe ISI possède neufs campus au Sénégal et deux (02) en Mauritanie. Avec
plus de 26 ans d’expériences, ISI dispose des départements comme le génie
informatique, les réseaux et systèmes, la gestion, ..., et délivre les diplômes suivants
: DTS1, LICENCE, MASTER, DITI2 et le DOCTORAT.

Pour l’obtention de la licence en IAGE (Informatique Appliquée à la

Gestion des Entreprises), ISI exige aux étudiants la rédaction d’un mémoire de fin
de cycle. C’est dans ce cadre que nous avons élaboré ce document qui a pour sujet :
étude et mise en place d’une plateforme web de location et de vente de biens
immobiliers.

Cette plateforme permettra de réaliser la plupart des tâches qui incombent à

un agent immobilier c’est-à-dire de gérer les locations et les ventes par le biais des
outils digitaux, mais aussi d’aider les personnes souhaitant faire des opérations
(location, vente) immobilières à trouver facilement leur bonheur, en limitant au
maximum les déplacements.

Ce document constitue notre premier travail de recherche académique, c’est

pourquoi nous sollicitons de la part du jury, beaucoup d’indulgence en ce qui
concerne son évaluation.

1
DTS : Diplôme de Technicien Supérieur
2
DITI : Diplôme d’Ingénieur en Techniques Informatiques

~ III ~
 SOMMAIRE

INTRODUCTION GENERALE ..................................................................................... 1

I. Les cadres théorique et méthodologique ................................................................. 3
1.1. Cadre théorique................................................................................................. 3
1.2. Cadre méthodologique ...................................................................................... 6
II. Analyse et Conception......................................................................................... 25
2.3. Analyse du système ......................................................................................... 25
2.4. Conception ....................................................................................................... 27
III. Mise en œuvre ...................................................................................................... 33
3.5. Réalisation........................................................................................................ 33
3.6. Architectures ................................................................................................... 44
3.7. Implémentation ............................................................................................... 46
CONCLUSION GENERALE ........................................................................................ 48

~ IV ~
 GLOSSAIRE
UML : Unified Modeling Language
ISI : Institut Supérieur d’Informatique
SGBD : Système de Gestion de Base de Donnée
POO: Programmation Orientée Objet
PHP: HyperText Preprocessor
HTML: Hyper- Text Markup Language
CSS: Cascading Style Sheet
CRUD : Create Read Update Delete
MERISE : Méthode d'Etude et de Réalisation Informatique pour les Systèmes
d'Entreprise
SI : Système d’Information
SIO : Système d’Information Organisationnel
SII : Système d’Information Informatisé
MCD : Modèle Conceptuel des Données
MLD : Modèle Logique des Données
MOD : Modèle Organisationnel des Données
MCT : Modèle Conceptuel des Traitements
MOT : Modèle Organisationnel des Traitements
MLT : Modèle Logique des Traitements
MPD : Modèle Physique des Données
MPT : Modèle Physique des Traitements
SGF : Système de Gestion de Fichiers
HTTP: Hypertext Transfer Protocol
ORM: Object Relationnal Mapping
IHM : Interface Homme Machine

~V~
 Liste des figures
Figure 1.1.1 Interface expat-dakar ........................................................................... 5
Figure 1.1.2 Interface 2simmo ................................................................................. 5
Figure 1.2.1 Cycle MERISE .................................................................................... 7
Figure 1.2.2 cycle de vie .......................................................................................... 8
Figure 1.2.3 Cycle de vie ......................................................................................... 9
Figure 1.2.4 Schémas détaillé SIO & SII............................................................... 11
Figure 1.2.5 Cycle de décision............................................................................... 12
Figure 1.2.6 Les deux (02) groupes de diagrammes UML .................................... 13
Figure 1.2.7 Les diagrammes structurels ............................................................... 13
Figure 1.2.8 Les diagrammes comportementaux ................................................... 14
Figure 1.2.9 Représentation des acteurs UML ...................................................... 15
Figure 1.2.10 exemple de diagramme de cas d’utilisation .................................... 15
Figure 1.2.11 Représentation des cas d'utilisation ................................................. 15
Figure 1.2.12 ligne de vie acteur diagramme de sequence .................................... 16
Figure 1.2.13 Représentation ligne de vie ............................................................. 16
Figure 1.2.14 Représentation des messages synchrone et asynchrones et de retour
............................................................................................................................... 17
Figure 1.2.15 Exemple de diagramme de séquence............................................... 17
Figure 1.2.16 Formalisme d'une classe .................................................................. 18
Figure 1.2.17 Relation unidirectionnelle ............................................................... 18
Figure 1.2.18 Relation bidirectionnelle ................................................................. 18
Figure 1.2.19 Représentation des cardinalités en UML......................................... 18
Figure 1.2.20 Relation de composition et d'agrégation ......................................... 19
Figure 1.2.21 Relation de généralisation ............................................................... 19
Figure 1.2.22 Exemple diagramme de classe ........................................................ 19
Figure 1.2.23 Représentation d'un nœud ............................................................... 20
Figure 1.2.24 Représentation d'un composant et relation avec un nœud ............... 20
Figure 1.2.25 Représenation d'un artifact dans un noeud ...................................... 20
Figure 1.2.26 Relation entre une instance artifact et un noeud.............................. 21
Figure 1.2.27 Représentation d'un artifact et relation avec un noeud .................... 21
Figure 1.2.28 Exemple diagramme de déploiement .............................................. 21
Figure 1.2.29 Instanciation .................................................................................... 23

~ VI ~
Figure 1.2.30 Objet ................................................................................................ 24
Figure 1.2.31 Exemple d'héritage .......................................................................... 24
Figure 2.4.1 Diagramme de cas d'utilisation gestion des biens et des annonces ... 27
Figure 2.4.2 Diagramme de cas d'utilisation gestion des contrats ......................... 28
Figure 2.4.3 Diagramme de cas d'utilisation gestion des règlements .................... 28
Figure 2.4.4 Diagramme de cas d'utilisation gestion des clients et des utilisateurs
............................................................................................................................... 29
Figure 2.4.5 Diagramme de séquence du cas d'utilisation se connecter ................ 29
Figure 2.4.6 Diagramme de séquence du cas d'utilisation ajouter bien ................. 30
Figure 2.4.7 Diagramme de séquence du cas d'utilisation supprimer client .......... 31
Figure 2.4.8 Diagramme de séquence du cas d'utilisation louer bien .................... 31
Figure 2.4.9 Diagramme de classe de conception ................................................. 32
Figure 2.4.10 Diagramme de déploiement............................................................. 33
Figure 3.5.1 HTML - CSS ..................................................................................... 35
Figure 3.5.2 JavaScript .......................................................................................... 35
Figure 3.5.3 PHP .................................................................................................... 36
Figure 3.5.4 JAVA ................................................................................................. 37
Figure 3.5.5 C SHARP .......................................................................................... 37
Figure 3.5.6 Python ................................................................................................ 38
Figure 3.5.7 Laravel ............................................................................................... 39
Figure 3.5.8 Symfony ............................................................................................ 39
Figure 3.5.9 SamaneMVC ..................................................................................... 40
Figure 3.5.10 MySQL ............................................................................................ 41
Figure 3.5.11 MariaDB .......................................................................................... 42
Figure 3.5.12 ORACLE DATABASE ................................................................... 43
Figure 3.5.13 SQL SERVER ................................................................................. 43
Figure 3.6.1 Architecture deux-tier........................................................................ 44
Figure 3.6.2 Architecture trois-tier ........................................................................ 45
Figure 3.7.1 Interface de connexion ...................................................................... 46
Figure 3.7.2 Interface Accueil ............................................................................... 47

~ VII ~
 Liste des tableaux
Tableau 1.2.1 Tableau comparatif entre MERISE ET UML ................................................ 22

~ VIII ~
 Résumé
En vue de l’obtention du diplôme de licence en Informatique Appliquée à la
Gestion des Entreprises à ISI, nous avons réalisé un projet de fin d’études afin de
parachever notre formation du premier cycle universitaire. C'est ainsi que nous
avons amusé l’idée de concevoir et de mettre en œuvre une plateforme web de
location et de vente de biens immobiliers qui, à terme, contribuera à permettre au
secteur de l’immobilier du Sénégal de s’adapter face à l’émergence du numérique.
Par la même occasion, nous avons eu l’opportunité d'approfondir et d’enrichir nos
connaissances théoriques et notre expérience pratique à travers la conception et la
réalisation de cette application. La réalisation de cette application sera bénéfique
aux acheteurs car ils pourront facilement rechercher et trouver le bien qui leur
convient. Aussi l’application sera capable de faire la gestion des clients, des biens,
des locations et des ventes.

Pour ce faire, nous avons créé une application web, modélisée à partir du
langage UML (langage de modélisation unifié). Le langage de programmation
choisi est le langage PHP (HyperText Preprocessor) avec le framework Symfony et
le système de gestion de base de données (SGBD) est MariaDB. Il faut noter que
l'outil StarUML nous a été très utile dans la modélisation graphique du système
avec les différents diagrammes UML.

~ IX ~
 Abstract
In order to obtain the degree of Bachelor of Science in Computer Science
Applied to Business Management at ISI, we carried out an end-of-studies project to
complete our undergraduate training. Thus, we had fun with the idea of designing
and implementing a web platform for renting and selling real estate which, in the
long run, will help the real estate sector in Senegal to adapt to the emergence of
digital technology. At the same time, we had the opportunity to deepen and enrich
our theoretical knowledge and practical experience through the design and
implementation of this application. The realization of this application will be
beneficial to buyers because they will be able to easily search and find the property
that suits them. The application will also be able to manage clients, properties,
rentals and sales.

To do this, we have created a web application, modeled from the UML

(Unified Modeling Language). The chosen programming language is PHP
(HyperText Preprocessor) with the Symfony framework and the database
management system (DBMS) is MariaDB. It should be noted that the StarUML tool
was very useful in the graphical modeling of the system with the various UML
diagrams.

~X~
 INTRODUCTION GENERALE
Le secteur de l’immobilier est longtemps resté un secteur à l’abri
d’innovations majeures. Malgré l'avènement de la publicité immobilière en ligne,
le processus d'achat, de location ou de vente d'un bien immobilier n'a pas changé.
Les visites et l’ensemble de la procédure pour acheter ou louer une propriété
immobilière n’ont en effet que peu évolué. Basé sur des méthodes traditionnelles,
le marché immobilier n'a connu un véritable bouleversement que depuis quelques
années. C'est dans cette optique que l'on assiste à la mise en place de technologies
qui facilitent la location et la vente de biens.

De plus, avec la crise sanitaire de la COVID 19 qui a impacté la mobilité, le

manque de temps dû à une surcharge de travail, l’émergence du numérique semble
être une solution pour permettre à ce secteur de s’adapter. Dès lors, une question se
pose à savoir : la technologie peut-elle être utilisée pour faciliter la communication
entre les sociétés immobilières et les clients ?

Pour résoudre ce problème, notre objectif global est de faciliter les

opérations à tout individu qui voudrait acheter ou louer des biens immobiliers. Et
nos objectifs spécifiques consistent à mettre en place une plateforme pour la
numérisation des activités tournant autour de l’immobilier : location, vente et
recherche de biens à louer.

Nous avons choisi ce sujet pour apporter des solutions afin d’aider les
acteurs qui souhaiteraient louer ou acheter des biens immobiliers.

Pour concrétiser notre projet, nous pouvons émettre les hypothèses

suivantes : tout d'abord, construire une plateforme capable de digitaliser le marché
immobilier ; ensuite, trouver des méthodes qui faciliteraient l’échange entre les
clients et les entreprises immobilières ; et enfin, mettre en place un système qui
gérerait les transactions.

~1~
 Ainsi, pour implémenter cette plateforme, plusieurs techniques ont été
employées, notamment celles s’appuyant sur la recherche documentaire à l’aide
des outils comme des sites Internet.

Notre travail s'articulera autour de trois parties. Dans un premier temps,

nous fournirons une présentation générale définissant les cadres théorique et
méthodologique. Dans un second temps, nous allons faire l’analyse conceptuelle,
et enfin, nous effectuerons la mise en œuvre de la plateforme.

~2~
I. Les cadres théorique et méthodologique
Les cadres théorique et méthodologique constitueront la première partie de
notre travail qui aidera à structurer l'étude, mais aussi à introduire et décrire le
concept ou le thème de l'étude.

1.1. Cadre théorique

Le cadre théorique de notre travail tournera autour du contexte et de la
problématique, de l’objet de l’étude et de l’analyse de l’existant.

1.1.1. Contexte et Problématique

➢ Contexte

Aujourd’hui, trouver un bien immobilier à louer ou en vente requiert un vrai

parcours de combattant. En effet, les déplacements pour les visites et les sommes
versées au courtier constituent de lourds fardeaux pour le prospect. En ajoutant à
cela, l’émergence du digital et le manque de visibilité des agences immobilières, le
secteur immobilier actuel du Sénégal est trop rudimentaire. Pour permettre à ce
secteur de se mettre au diapason, de raccourcir l’effort du client potentiel et de faire
la publicité des propriétés immobilières en location ou en vente pour les entreprises
immobilières, il est nécessaire de trouver une solution informatique.

➢ Problématique

Les problèmes rencontrés sont d’une part la difficulté à trouver un système

fiable qui permettra de gérer efficacement les biens et patrimoines immobiliers de
l’agence et d’autre part faciliter l’accès à l’information sur les biens disponibles
pour les clients désireux. En général certaines agences ont une clientèle étrangère ;
il y a donc une nécessité d’avoir un système d’informations valide et sécuritaire afin
d’étendre les services à ces clients. Ainsi, compte tenu de la situation citée ci-haut,
nous sommes parvenus à nous poser les questions suivantes :
• L’agence se rend-elle comptes des avantages de l’implantation d’un site web à
son sein pour améliorer le mode de diffusion des informations à la population ?
• Comment l’agence pourrait-elle mettre à la portée du public toutes les
informations concernant les biens disponibles soit pour la location, soit pour la
vente sans contrainte de distance et du temps ?

~3~
• La conception d’une application web pour l’agence permettra-t-elle une
diminution des coûts de publicité ?
• Comment faire pour gérer efficacement de manière automatique le
recouvrement des arriérés de paiement, les propriétaires ainsi que les clients ?
• Quels sont les coûts de location et de vente d’un bien immobilier ?
• Quelles informations sont pertinentes pour la situation du client ?
• Quels sont les types de biens immobiliers ?
• Comment améliorer le processus d’achat et de vente d’une propriété
immobilière ?
• Quelles sont les solutions qu’il faudrait mettre en place ?
Le contexte et la problématique ainsi abordées, nous passerons à l’objectif de
l’étude.

1.1.2. Objet de l’étude

L’objectif de cette étude est d’alléger la souffrance physique et financière
des individus souhaitant faire des opérations (achat, location) immobilières en
mettant en place une application web. Cette dernière permettra de gérer les étapes
effectuées dans le processus de location et de vente d’un bien immobilier. Ainsi,
notre travail consiste à mettre en place une plateforme qui regroupe les
fonctionnalités suivantes à savoir :
• Gestion des annonces (CRUD) • Gestion des clients
• Gestion des biens (CRUD) • Gestion des contrats
• Gestion des locations • Gestion des utilisateurs
• Gestion des ventes
• Gestions des règlements
L’objet de l’étude étant défini, faisons l’analyse de l’existant.

1.1.3. Analyse de l’existant

L’analyse de l’existant consistera à faire la présentation et la critique de deux
(02) solutions à savoir : expat-dakar.com et 2simmobilier.com.

~4~
• Expat-dakar.com : Lancé en 2008, Expat-Dakar.com est un portail qui offre une
façon simple, efficace et pratique d’acheter et de vendre des biens ou des
services. On peut y trouver un appartement, un terrain, un emploi, une voiture,
un smartphone, une nounou et bien d’autres choses. Leur rôle est de connecter
les vendeurs et les acheteurs, et leur permettre d’échanger librement.

Figure 1.1.1 Interface expat-dakar

• 2simmobilier.com: 2Simmo est une agence immobilière qui propose

globalement tous les services de l’immobilier(location, vente, …). L’agence
propose une sélection complète biens de qualité dans tout le Sénégal
principalement dans la capitale dakaroise.

Figure 1.1.2 Interface 2simmo

Pour les critiques, nous pouvons dire que Expat-Dakar n’est pas spécialisé dans la
location et la vente de biens immobiliers alors que 2simmo l’est. Tous les
utilisateurs d’Expat-Dakar qui ont ouvert un compte peuvent faire des annonces, ce
qui ne garantit pas la sécurité des clients. Quant à 2simmo, il ne permet pas à ses

~5~
utilisateurs d’en faire. Pour toutes les deux solutions, il n’y a que les annonces ; la
gestion des locations et des ventes ne se fait pas dans les deux sites web.
Ainsi, nous avons fait l’étude de l’existant.
Ce chapitre a constitué la présentation de notre sujet. Venons-en maintenant à
l’étude méthodologique, objet du chapitre deux.

1.2. Cadre méthodologique

Pour passer de l’étude d’un projet à sa traduction en langage machine, la
phase d’analyse et de modélisation semble être inévitable. Le cadre méthodologique
de notre projet sera composé de trois sections qui sont les méthodes d’analyse et de
conception, la comparaison entre ces méthodes et le choix de la méthode.

1.2.1. Méthodes d’analyse et de conception

La méthode d'analyse et de conception vise à formaliser les étapes
préliminaires de développement du système afin de rendre ce développement plus
fidèle aux besoins du client. Pour ce faire, nous commençons par recenser les
besoins du client, ensuite nous procédons à une analyse de ce qui peut exister. La
phase d'analyse peut lister les résultats attendus en termes de fonctionnalité, de
performance, de robustesse, de maintenance, de sécurité, d'évolutivité, etc. La phase
de conception peut décrire le fonctionnement futur du système souvent à l'aide d'un
langage de modélisation pour faciliter sa mise en œuvre. Nous allons présenter
principalement deux langages de modélisation qui sont MERISE et UML.

1.2.1.1. MERISE
La méthode MERISE (Méthode d'étude et de réalisation informatique pour
les systèmes d'entreprise) date de 1978-1979, et fait suite à une consultation
nationale lancée en 1977 par le Ministère de l'Industrie dans le but de choisir des
sociétés de conseil en informatique afin de définir une méthode de conception de
systèmes d'information. Les deux principales sociétés ayant mis au point cette
méthode sont le CTI (Centre Technique d'Informatique) chargé de gérer le projet,
et le CETE (Centre d'Etudes Techniques de l'Equipement) implanté à Aix-en-
Provence. C’est une méthode d'analyse, de conception et de gestion de projet
complètement intégrée, ce qui en constitue le principal atout. MERISE est donc une
méthode de conception des systèmes d'information (SI). Ceux-ci sont un ensemble
de ressources et de dispositifs permettant de collecter, stocker, traiter et diffuser les

~6~
informations nécessaires au fonctionnement d’une organisation (administration,
entreprise…).
La démarche MERISE se fait selon trois axes appelés cycles.
➢ Le cycle de vie : comment enchaîner les étapes
➢ Le cycle d’abstraction : quels outils permettent de les mener
➢ Le cycle de décision : quelles décisions sont à prendre au fil de celles-ci.

Figure 1.2.1 Cycle

MERISE

Les trois cycles se déroulent simultanément.

a) Le cycle de vie

Il comporte trois grandes périodes qui sont définies ci-dessous.

• La conception : période d'étude de l'existant puis du système à mettre en place,
elle se découpe en trois étapes qui sont le schéma directeur, l'étude préalable et
l'étude détaillée.
• La réalisation : recouvre la mise en œuvre et l'exploitation, elle se décompose,
elle aussi, en trois étapes : l'étude technique, la réalisation logicielle et la mise
en service.

~7~
• La maintenance : devra permettre au système d'évoluer et de s'adapter aux
modifications de l'environnement et aux nouveaux objectifs pendant une
certaine durée de vie et ensuite il devra laisser la place à un nouveau système.

Figure 1.2.2 cycle de vie

~8~
b) Le cycle d'abstraction

Il s'agit donc de valider, une à une, les différentes étapes en prenant en

compte les résultats de la phase précédente. D'autre part, les données étant séparées
des traitements, il faut vérifier la concordance entre données et traitement afin de
vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il
n'y a pas de données superflues. Cette nécessité d'aborder successivement les
différents types de préoccupations a conduit à proposer différents niveaux
d'abstraction ou de hiérarchisation des préoccupations. Nous retiendrons pour
MERISE quatre niveaux d'abstraction :
• niveau conceptuel ;
• niveau organisationnel ;
• niveau logique ;
• niveau physique.
La méthode MERISE étant utilisée pour la mise en place ou la modification des
systèmes informatiques, il convient donc d'analyser et de critiquer le système
existant afin de créer un nouveau système adapté à l'organisation. Pour cela, la
démarche consiste à suivre la « courbe du soleil » qui est présentée ci-dessous :

Figure 1.2.3 Cycle de vie

~9~
Les deux premiers niveaux sont adaptés à la conception du système d'information
organisationnel (SIO), les deux derniers à la conception du système d'information
informatisé (SII).
Au niveau conceptuel, le modèle conceptuel des données (MCD) formalise la
signification des informations sur lesquelles repose le système d'information, sans
contrainte technique ni économique. Le modèle conceptuel de traitements (MCT)
formalise l'activité du domaine abordé, sans préciser les ressources ni leur
organisation.
Au niveau organisationnel, le modèle organisationnel de traitements (MOT) décrit
le fonctionnement du domaine en précisant les ressources humaines et matérielles
mobilisées, ainsi que l'organisation de ces ressources dans le temps et dans l'espace.
Le modèle organisationnel des données (MOD) précise quelles sont parmi les
données définies au niveau conceptuel (MCD) celles qui sont prises en compte par
le futur système informatisé, où ces données sont localisées (répartition par site
organisationnel), leur confidentialité pour chaque intervenant de l'entreprise.
Au niveau logique, le modèle logique de données (MLD) fournit une description
des données tenant compte des moyens informatiques de mémorisation et de leurs
conditions d'utilisation par les traitements. Le modèle logique de traitements (MLT)
décrit comment les tâches informatisées définies dans les MOT précédents sont
conçues en termes de logiciel.
Au niveau physique, le modèle physique de données (MPD) est une description de
la ou des bases de données ou de l'ensemble des fichiers, exprimée dans la syntaxe
du système de gestion de bases de données (SGBD) ou système de gestion de
fichiers (SGF) adoptés. Enfin, le modèle physique de traitements (MPT) précise,
pour la réalisation, les spécifications techniques des différents modules définis au
niveau du MLT. Ces modules pourront être réalisés soit en langages de quatrième
génération, soit de façon plus traditionnelle en langage de troisième génération
(Cobol, C…).

~ 10 ~
 Figure 1.2.4 Schémas détaillé SIO & SII

c) Le cycle de décision

Tout au long de l'étude et de la maintenance, des décisions sont à prendre,

très générales d'abord, puis de plus en plus détaillées. La mise en œuvre de la
méthode MERISE se traduit, en plus, par une succession de choix permettant, d'une
part, de contrôler la durée globale de la conception-réalisation, d'autre part, de
définir un système en harmonie avec les objectifs généraux de l'entreprise. Notons
que la maîtrise comprend également l'ensemble des décisions d'arbitrage relatives
aux coûts, délais et niveaux de gamme associés au projet. La responsabilité de ces
différents choix incombe à un troisième partenaire. Après l'utilisateur - gestionnaire et
l'informaticien intervient le décideur (ou direction). La répartition des rôles entre ces
différents partenaires, les diverses décisions à prendre au fur et à mesure de l'avancement
du projet, la hiérarchisation des choix et les résultats à produire constituent les principaux
éléments de cette maîtrise du projet. Dans la pratique, le cycle de décision est intégré
dans le cycle de vie. Cela se traduit par des résultats types à l'issue de chaque étape et par
des décisions attendues, comme le montre la figure suivante :

~ 11 ~
 Figure 1.2.5 Cycle de décision

Enfin, dans cette dimension, il importe de laisser une grande latitude de

personnalisation par l'entreprise. Des petits projets ne mobilisent pas
nécessairement les mêmes moyens de contrôle que ceux présentant un rôle
stratégique pour l'entreprise.
MERISE apparaît donc comme une approche déterminante des systèmes
d’information. Que vaut UML ?

1.2.1.2. UML
UML (Unified Modeling Language) est un langage de modélisation
maintenu en tant que standard par l'OMG (Object Management Group) depuis
1997. UML est né de l'unification des travaux des "3 amigos", Grady Booch, Ivar
Jacobson, et James Rumbaugh, auteurs de techniques et de langage de modélisation
objets : Booch, OOSE (Object Oriented Software Engineering), et OMT (Object
Modeling Technique). La dernière version officielle selon l'OMG est UML
2.5.1 (2017). Le langage UML permet de produire une représentation visuelle et
uniformisée des aspects d'un système ou projet logiciel à réaliser. UML peut ainsi
être utilisé pour rendre compréhensible et gérable des concepts ou architectures
~ 12 ~
complexes. UML est à la fois adapté pour de simples projets avec quelques
modèles, ou pour des projets complexes et de grande envergure par un large
référentiel de modèles. Il est conçu pour représenter, construire, et documenter des
systèmes logiciels utilisant des techniques orientées objet. UML propose quatorze
(14) types de diagrammes répartis en deux (02) groupes.
➢ Les diagrammes structurels
➢ Les diagrammes comportementaux

Diagrammes UML

diagrammes diagrammes
structurels comportementaux

Figure 1.2.6 Les deux (02) groupes de diagrammes UML

a) Les diagrammes structurels

Les diagrammes structurels sont composés de sept (07) diagrammes illustrés

ci-dessous.

Figure 1.2.7 Les diagrammes structurels

b) Les diagrammes comportementaux

~ 13 ~
 Les diagrammes comportementaux sont aussi aux nombres de sept (07)
diagrammes exposés ci-dessous.

Figure 1.2.8 Les diagrammes comportementaux

c) Présentation de quelques diagrammes

Nous allons voir principalement quatre (04) diagrammes qui sont le diagramme
de cas d’utilisation, le diagramme de séquence, le diagramme de classe et le
diagramme de déploiement.
• Diagramme de cas d’utilisation : il permet d'identifier les possibilités
d'interaction entre le système et les acteurs (intervenants extérieurs au système),
c'est-à-dire toutes les fonctionnalités que doit fournir le système. Il permet aussi
de délimiter le système. Un acteur représente un élément externe qui interagit
avec le système. Cet élément peut être un utilisateur ou un système tiers (autre
ordinateur, autre programme, base de données). Tous les éléments extérieurs
qui stimulent le système et tous les éléments extérieurs qui sont utilisés par le
système sont représentés par des acteurs. Dans le cas d'acteurs non-humains, il
est possible de définir une « Interface » qui représente les opérations offertes
par cet acteur. Il est possible de représenter un acteur sous forme d'un

~ 14 ~
 bonhomme comme ci-dessous à gauche ou sous forme d'un classeur comme ci-
dessous à droite.

Figure 1.2.9 Représentation des acteurs UML

Un cas d'utilisation représente une fonctionnalité du système. Cette

fonctionnalité est définie par une action déclenchante, un ou plusieurs
déroulements possibles et éventuellement une fin. Le nom du use case doit se
composer d'un verbe à l'infinitif qui décrit une action. Pour que l'ensemble du
modèle soit cohérent, il faut choisir tous les verbes soit du point de vue du
système, soit du point de vue de l'utilisateur (ce qui est généralement
préférable). Le cas d'utilisation se représente par une ellipse contenant un nom
décrivant la fonctionnalité et éventuellement un stéréotype.

Figure 1.2.11 Représentation des cas d'utilisation

Le diagramme des cas d'utilisation se présente comme ci-dessous.

Figure 1.2.10 exemple de diagramme de cas d’utilisation

~ 15 ~
• Diagramme de séquence : c’est un type de diagramme d'interaction, car il
décrit comment et dans quel ordre plusieurs objets fonctionnent ensemble. Ces
diagrammes sont utilisés à la fois par les développeurs logiciels et les managers
d'entreprises pour analyser les besoins d'un nouveau système ou documenter un
processus existant. Les diagrammes de séquence sont parfois appelés
diagrammes d'événements ou scénarios d'événements. Ils permettent de montrer
les interactions dans le cadre d’un scénario d’un diagramme de cas d’utilisation.
Le but est de décrire comment se déroulent les interactions entre les acteurs ou
objets. Chaque instance d'une interaction est représentée par une ligne de vie.

X : classe1

Instance ou objet Type de l’objet

Tige de la ligne de vie

Figure 1.2.13 Représentation ligne de vie

Parfois, un diagramme de séquence aura une Ligne de Vie avec un symbole de

l’élément de l’acteur à sa tête. Ce sera généralement le cas si le diagramme de
séquence appartient à un cas d’utilisation.

Figure 1.2.12 ligne de vie acteur diagramme de sequence

La communication entre les instances se fait grâce à des messages. Un message

fait circuler des informations d'une instance, représentée par une ligne de vie, à
une autre instance au cours d'une interaction. Les messages sont affichés sous
forme de flèches. Elles peuvent être complet, perdus ou trouvés; synchrone ou
asynchrone; appeler ou signaler. Dans le diagramme suivant, le premier
message est un message synchrone (désigné par la flèche solide) avec un
message de retour implicite. Le deuxième message est asynchrone (dénoté par
une pointe de flèche de la ligne), et le troisième est le message de retour
asynchrone (dénoté par la ligne pointillée).

~ 16 ~
 Bande
d’activation

Figure 1.2.14 Représentation des messages synchrone et asynchrones et de retour

Le diagramme de séquence se présente comme ci-dessous.

Figure 1.2.15 Exemple de diagramme de séquence

• Diagramme de classes : il est considéré comme le plus important de la

modélisation orientée objet, il est le seul obligatoire lors d'une telle
modélisation. Alors que le diagramme de cas d'utilisation montre un système du
point de vue des acteurs, le diagramme de classes en montre la structure interne.
Il s'agit d'une vue statique, car on ne tient pas compte du facteur temporel dans
le comportement du système. Le diagramme de classes modélise les concepts
du domaine d'application ainsi que les concepts internes créés de toutes pièces
dans le cadre de l'implémentation d'une application. Les principaux éléments de
cette vue statique sont les classes et leurs relations. Une classe est la description
formelle d'un ensemble d'objets ayant une sémantique et des caractéristiques
communes. Un objet est une instance d'une classe. C'est une entité discrète dotée
d'une identité, d'un état et d'un comportement que l'on peut invoquer. Les objets
sont des éléments individuels d'un système en cours d'exécution. Une classe est
un classeur. Elle est représentée par un rectangle divisé en trois à cinq

~ 17 ~
compartiments. Le premier indique le nom de la classe, le deuxième ses attributs
et le troisième ses opérations. Un compartiment des responsabilités peut être
ajouté pour énumérer l'ensemble de tâches devant être assurées par la classe,
mais pour lesquelles on ne dispose pas encore assez d'informations. Un
compartiment des exceptions peut également être ajouté pour énumérer les
situations exceptionnelles devant être gérées par la classe.

Figure 1.2.16 Formalisme d'une classe

Une association est une relation entre deux classes (association binaire) ou plus
(association n-aire), qui décrit les connexions structurelles entre leurs instances.
Une association indique donc qu'il peut y avoir des liens entre des instances des
classes associées. Elle peut aussi comporter un nom.
La flèche indique ici (voir figure 1.2.17) que la relation est unidirectionnelle :
les objets de classe Article connaissent ceux de la classe Commentaire auxquels
ils sont liés, mais pas l’inverse.

Figure 1.2.17 Relation unidirectionnelle

L’absence de flèche (voir figure 1.2.18) indique ici que l’on peut accéder aux
catégories à partir des articles qui leur sont liés, et inversement.

Figure 1.2.18 Relation bidirectionnelle

.
Les multiplicités permettent de contraindre le nombre d’objets intervenant dans
les instanciations des associations. On en place de chaque côté des associations.

Figure 1.2.19 Représentation des cardinalités en UML

~ 18 ~
 Une relation d'agrégation affiche un discriminant comme un composant ou un
subordonné d'un autre discriminant. Une relation d'association de composition
représente une relation Tout-Partie et est une forme d'agrégation. Une relation
d'association de composition spécifie que la durée de vie du discriminant de
partie dépend de la durée de vie du discriminant global. Leurs formalismes sont
illustrés ci-dessous.

Figure 1.2.20 Relation de composition et d'agrégation

Une relation de généralisation est une relation dans laquelle un élément de

modèle (l'enfant) est basé sur un autre élément de modèle (le parent). Les
relations de généralisation sont utilisées dans les diagrammes de classes, de
composants, de déploiement et de cas d'utilisation pour indiquer que l'enfant
reçoit tous les attributs, opérations et relations qui sont définis dans le parent.
Elle est formalisée comme suit :

Classe Parent Classe Enfant

Figure 1.2.21 Relation de généralisation

Exemple de diagramme de classe :

Figure 1.2.22 Exemple diagramme de classe

• Diagramme de déploiement : Un diagramme de déploiement décrit la

disposition physique des ressources matérielles qui composent le système et
montre la répartition des composants sur ces matériels. Chaque ressource étant
matérialisée par un nœud, le diagramme de déploiement précise comment les

~ 19 ~
composants sont répartis sur les nœuds et quelles sont les connexions entre les
composants ou les nœuds. Les diagrammes de déploiement existent sous deux
formes : spécification et instance. Chaque ressource est matérialisée par un
nœud représenté par un cube comportant un nom. Un nœud est un classeur et
peut posséder des attributs (quantité de mémoire, vitesse du processeur…).

Figure 1.2.23 Représentation d'un nœud

Pour montrer qu'un composant est affecté à un nœud, il faut soit placer le
composant dans le nœud, soit les relier par une relation de dépendance
stéréotypée « support » orientée du composant vers le nœud.

Figure 1.2.24 Représentation d'un composant et relation avec un nœud

Un artefact correspond à un élément concret existant dans le monde réel

(document, exécutable, fichier, tables de bases de données, script…). Il se
représente comme un classeur par un rectangle contenant le mot-clef « artifact »
suivi du nom de l'artefact. L'artefact peut aussi être inclus directement dans le
cube représentant le nœud (voir figure ci-aprés).

Figure 1.2.25 Représenation d'un artifact dans un noeud

~ 20 ~
Une instance d'un artefact se déploie sur une instance de nœud. Graphiquement,
on utilise une relation de dépendance (flèche en trait pointillé) stéréotypée
« deploy » pointant vers le nœud en question. En toute rigueur, seuls des
artefacts doivent être déployés sur des nœuds. Un composant doit donc être
manifesté par un artefact qui, lui-même, peut être déployé sur un nœud.

Figure 1.2.26 Relation entre une instance artifact et un noeud

L'implémentation des modèles (classes…) se fait sous la forme de jeu

d'artefacts. On dit qu'un artefact peut manifester, c'est-à-dire résulter et
implémenter, un ensemble d'éléments de modèle. On appelle manifestation la
relation entre un élément de modèle et l'artefact qui l'implémente.
Graphiquement, une manifestation se représente par une relation de dépendance
stéréotypée « manifest ».

Figure 1.2.27 Représentation d'un artifact et relation avec un noeud

Exemple de diagramme de déploiement :

Figure 1.2.28 Exemple diagramme de déploiement

~ 21 ~
 Dans un diagramme de déploiement, les associations entre nœuds sont des
chemins de communication qui permettent l'échange d'informations.
Nous avons vu les méthodes d’analyse et de conception MERISE et UML, passons
à présent à la comparaison entre ces deux (02).

1.2.2. Comparaison entre MERISE ET UML

Nous allons dresser un tableau comparatif entre MERISE et UML.

MERISE UML

Méthode d'analyse et de conception de Langage de représentation d'un

système d’information système d'information.
Méthode de modélisation de données et Système de notation orienté objet.
traitements orienté bases de données
relationnelles.
Relationnel Objet
Schéma directeur, étude préalable, Langage de modélisation des systèmes
étude détaillée et la réalisation. standard, qui utilise des diagrammes
pour représenter chaque aspect d'un
systèmes i.e.: statique,
dynamique,....en s'appuyant sur la
notion d'orienté objet
Plus adapté à une approche théorique Plus orientée vers la conception
Du "bottom up" de la base de donnée Du "top down" du modèle vers la base
vers le code de données.
Tableau 1.2.1 Tableau comparatif entre MERISE ET UML

Nous pouvons donc dire que MERISE va décrire le schéma de données, la

persistance. Il s’agit des données sauvegardées en base de données lorsque le
système n’est plus en marche. De son côté, UML est plus un “langage” de
diagramme Objet. On représente les objets métiers et les traitements (méthodes)
associés.
Ce tableau comparatif ainsi commenté devra nous conduire à opérer notre choix
entre MERISE ET UML.

~ 22 ~
 1.2.3. Choix de la méthode conception
Notre choix se porte sur l’UML qui adopte l’approche orientée objet car
UML est un langage formel et normalisé (clair et précis). Il est un support de
communication performant du fait qu’il facilite l’analyse et la compréhension des
représentations abstraites complexes. L’orientation utilisateur de certains
formalismes est un autre avantage non négligeable. En plus de définir les services
accessibles (offerts) aux utilisateurs, celui-ci constitue un support du dialogue
concepteurs / utilisateurs non négligeable offrant ainsi une plus rapide et plus
efficace collaboration et validation par les utilisateurs. De s’urcroît, UML apporte
une compréhension rapide du programme à d’autres développeurs externes en cas
de reprise du logiciel et facilite sa maintenance. Présentons à présent quelques
concepts clés de l’orientée objet.

• Classe : c’est le premier concept fondamental de l’orientée objet. Une classe

est une structure abstraite qui décrit des objets du monde réel sous deux angles
: ses propriétés (ses caractéristiques) et ses méthodes (les actions qu’elle peut
effectuer ou son comportement). La classe est finalement une sorte de moule,
de modèle. Toutes les instances de classe s’appellent des objets. Les objets sont
construits à partir de la classe, par un processus appelé instanciation. De ce fait,
tout objet est une instance de classe.

Figure 1.2.29 Instanciation

~ 23 ~
• Objet : il est le second concept le plus important en programmation objet.
Comme nous vous l’avons dit tout à l’heure, un objet est une instance de classe.
Pour faire le parallèle avec le monde réel, l’objet est un peu comme une maison
bâtie sur la base d’un plan particulier. Tant que les architectes se réfèrent à ce
plan, ils produiront toujours les mêmes maisons. Il est caractérisé par une
identité (qui doit l’identifier sans ambiguïté), des états (chaque objet a une
valeur par défaut lorsqu’elle est indiquée à l’instanciation pour chacune de ses
propriétés) et des méthodes (chaque objet est capable d’exécuter les actions ou
le comportement défini dans la classe).

Figure 1.2.30 Objet

• Encapsulation : étant troisième concept de la programmation orientée objet,

l’encapsulation permet de restreindre l’accès direct aux états et empêche la
modification de l’objet hors de ses méthodes. Ainsi, elle est un mécanisme qui
empêche donc de modifier ou d’accéder aux objets par un autre moyen que les
méthodes proposées, et de ce fait, permet de garantir l’intégrité des objets.
• Héritage : c’est le quatrième concept clé de la programmation objet. C’est un
concept en POO qui désigne le fait qu’une classe peut hériter des
caractéristiques (attributs et méthodes) d’une autre classe. Les objets de classes
peuvent hériter des propriétés d’une classe parent.

Figure 1.2.31 Exemple d'héritage

~ 24 ~
• Polymorphisme : Le nom de polymorphisme vient du grec et signifie qui peut
prendre plusieurs formes. Cette caractéristique est un des concepts essentiels de
la programmation orientée objet. Alors que l'héritage concerne les classes (et
leur hiérarchie), le polymorphisme est relatif aux méthodes des objets. Un
langage orientée objet est dit polymorphique, s’il offre la possibilité de
percevoir un objet en tant qu’instance de différentes classes selon la situation.
Le choix de la méthode de conception a constitué la dernière section de ce chapitre.
Celui-ci nous a permis de voir les méthodes d’analyse et de conception.
Il ressort de cette première partie une meilleure maîtrise du sujet en dégageant les
cadres théorique et méthodologique. Nous allons donc poursuivre avec la deuxième
partie où nous attaquerons l’analyse et la conception du système.

II. Analyse et Conception

Dans cette partie nous allons nous concentrer sur deux chapitres essentiels
lors de la mise en place d’une application pour gérer la partie logique des données.
Nous allons donc voir en premier l’analyse puis la conception en deuxième.

2.3. Analyse du système

Pour bien analyser le système, il est nécessaire de déterminer les besoins
fonctionnels et non-fonctionnels du système mais aussi il faudra procéder à la
rédaction du cahier de charges.

2.3.1. Besoins fonctionnels

Les besoins (exigences) fonctionnels ou métiers représente ce que le
système doit faire. Dans notre application, les principales fonctionnalités sont les
suivantes :
✓ S’authentifier ✓ Lister annonce ✓ Ajouter utilisateur

✓ Ajouter bien ✓ Etablir contrat ✓ Modifier utilisateur

✓ Modifier bien ✓ Supprimer client ✓ Supprimer utilisateur

✓ Supprimer bien ✓ Modifier client ✓ Lister utilisateur

✓ Lister bien ✓ Effectuer règlement bien ✓ Bloquer utilisateur

✓ Rechercher bien ✓ Ajouter client

✓ Voir annonce ✓ Lister client
✓

~ 25 ~
Nous avons donc déterminé les besoins fonctionnels, à présent, passons aux besoins
non-fonctionnels.

2.3.2. Besoins non-fonctionnels

Il s'agit des besoins qui caractérisent le système c’est-à-dire que ce sont des
exigences qui ne concernent pas spécifiquement le comportement du système mais
plutôt identifient des contraintes internes et externes du système. Ce sont des
besoins en matière de performance, de type de matériel ou le type de conception.
Ces besoins peuvent concerner les contraintes d'implémentation (langage de
programmation, type SGBD, de système d'Exploitation...). Dans le cadre de ce
travail, les principaux besoins non-fonctionnels de notre application sont :
✓ Sécurité des mots de passe
✓ Facilité d’utilisation
✓ Ergonomie
✓ Garantie
✓ Extensibilité
C’est ainsi que se termine cette section où on a parlé des besoins non-fonctionnels.
Nous allons aborder la dernière section de ce chapitre qui consiste à la rédaction du
cahier de charges.

2.3.3. Rédaction du cahier de charges

Sen-Immo est une entreprise (fictive) évoluant dans le secteur immobilier.
Il offre les services de location et de vente des biens immobiliers.
Gestion des biens et des annonces
Dans le cadre de cette application, les biens immobiliers sont les terrains, les
immeubles, les maisons et les appartements. Les biens sont situés dans des localités.
Les terrains peuvent être subdivisé en parcelles, les immeubles sont composés
d’appartements.
Une annonce est faite pour un bien précis en fonction de sa disponibilité et de son
type d’offre.
Gestion des contrats
Pour la location, elle diffère en fonction des biens. Une maison ne peut être louer
ou vendu que dans sa totalité tandis qu’un immeuble ou un terrain peut être donner
en location ou céder dans son ensemble mais aussi en fonction de ses compositions
respectives (appartements pour immeuble, parcelles pour terrains). Le contrat est
~ 26 ~
établi avec le client pour une propriété immobilière bien déterminée. Un client peut
avoir plusieurs contrats à son actif.
Gestion des règlements
Les règlements s’effectuent de façon mensuelle pour les locations au plus tard le 5
de chaque mois. Un client peut décider de payer à l’avance ou de régler plusieurs
mois de location en même temps. Pour les ventes, elles se font par un versement
unique qui couvrent la totalité de la somme.
Gestion des clients et des utilisateurs
Un client est une personne (physique ou morale) ayant eu au moins un contrat.
L’administrateur enregistre les utilisateurs et leurs rôles.
Ce chapitre qui parlait sur l’analyse étant terminé, nous allons procéder à la
conception du système

2.4. Conception
Dans ce chapitre nous modéliserons le système en représentant quatre (04)
diagrammes UML que nous avons jugé incontournable lors de la conception.

2.4.1. Diagramme de cas d’utilisation

2.4.1.1. Gestion des biens et des annonces

Figure 2.4.1 Diagramme de cas d'utilisation gestion des biens et des annonces

~ 27 ~
 2.4.1.2. Gestion des contrats

Figure 2.4.2 Diagramme de cas d'utilisation gestion des contrats

2.4.1.3. Gestion des règlements

Figure 2.4.3 Diagramme de cas d'utilisation gestion des règlements

~ 28 ~
 2.4.1.4. Gestion des utilisateurs

Figure 2.4.4 Diagramme de cas d'utilisation gestion des clients et des utilisateurs

2.4.2. Diagramme de séquence

Nous allons faire les digrammes de séquences des cas d’utilisation se
connecter, ajouter un bien, supprimer client

2.4.2.1. Cas d’utilisation se connecter

Figure 2.4.5 Diagramme de séquence du cas d'utilisation se connecter

~ 29 ~
 2.4.2.2. Cas d’utilisation ajouter bien

Figure 2.4.6 Diagramme de séquence du cas d'utilisation ajouter bien

~ 30 ~
 2.4.2.3. Cas d’utilisation supprimer bien

Figure 2.4.7 Diagramme de séquence du cas d'utilisation supprimer client

2.4.2.4. Cas d’utilisation louer bien

Figure 2.4.8 Diagramme de séquence du cas d'utilisation louer bien

~ 31 ~
 2.4.3. Diagramme de classe

Figure 2.4.9 Diagramme de classe de conception

~ 32 ~
 2.4.4. Diagramme déploiement

Figure 2.4.10 Diagramme de déploiement

Nous avons ainsi terminé la conception du système en présentant le diagramme de

classe, les diagrammes de cas d’utilisations, les diagrammes de séquences et le
diagramme de déploiement.
Cette deuxième partie nous a permis de faire l’analyse et la conception du système.
Nous allons à présent procéder à la dernière partie qui s’intitule la mise en œuvre.

III. Mise en œuvre

Etant la dernière partie de cette étude, la mise en œuvre contiendra trois
chapitres à savoir la réalisation, l’architecture et l’implémentation.

3.5. Réalisation
Dans ce chapitre nous allons voir deux sections qui sont les outils de
développement et la présentation des SGBD (Système de Gestion de Base de
Données).

~ 33 ~
 3.5.1. Outils de développement
Les outils de développement sont l’ensemble des langages de programmation, des
framework3, des SGBD, …, qui vont nous aider à réaliser notre application. Cette
section nous aidera à faire notre choix sur les langages de programmation à utiliser,
le framework à adopter et le SGBD à exploiter.

3.5.1.1. Quelques langages de programmation

Un langage de programmation est une notation conventionnelle destinée à
formuler des algorithmes et produire des programmes informatiques qui les
appliquent. Les langages de programmation permettent de décrire d’une part, les
structures des données qui seront manipulées par l’appareil informatique, d’autre
part, d’indiquer comment sont effectuées les manipulations, selon quels
algorithmes. Ils servent de moyens de communication par lesquels le programmeur
communique avec l’ordinateur, mais aussi avec d’autres programmeurs ; les
programmes étant d’ordinaires écrits, lus, compris et modifiés par une équipe de
programmeurs. Par ailleurs, il existe plusieurs langages de programmation.

a) HTML – CSS
HyperText Markup Language (HTML) est le code utilisé pour structurer
une page web et son contenu. Par exemple, le contenu de votre page pourra être
structuré en un ensemble de paragraphes, une liste à puces ou avec des images et
des tableaux de données. Cependant HTML n'est pas un langage de programmation.
C'est un langage de balises qui définit la structure de votre contenu. HTML se
compose d'une série d'éléments, utilisés pour entourer, ou envelopper, les diverses
parties du contenu pour les faire apparaître ou agir d'une certaine façon. Les fichier
html ont pour extension *.htm ou *.html. CSS est l’acronyme de « Cascading Style
Sheets » ce qui signifie « feuille de style en cascade ». Le CSS correspond à un
langage informatique permettant de mettre en forme des pages web. Ce langage est
donc composé des fameuses « feuilles de style en cascade » également appelées
fichiers CSS (.css) et contient des éléments de codage. En faisant appel à ce fichier

3
Framework : cadre de travail

~ 34 ~
dans la page HTML, on peut désigner un style lourd et complexe avec une simple
petite balise.
De plus, si la CSS est employée dans un site entier (comme c'est toujours le cas), il
suffit de mettre à jour le CSS pour refaire le design du site en entier.

Figure 3.5.1 HTML - CSS

b) JavaScript
JavaScript (souvent abrégé en « JS ») est un langage de script léger, orienté
objet, principalement connu comme le langage de script des pages web. Mais il est
aussi utilisé dans de nombreux environnements extérieurs aux navigateurs web. Le
code JavaScript est interprété ou compilé à la volée (JIT4). C'est un langage à objets
utilisant le concept de prototype, disposant d'un typage faible et dynamique qui
permet de programmer suivant plusieurs paradigmes de programmation :
fonctionnelle, impérative et orientée objet. Avec les technologies HTML et CSS,
JavaScript est parfois considéré comme l'une des technologies cœur du World Wide
Web5. Le langage JavaScript permet des pages web interactives, et à ce titre, c’est
une partie essentielle des applications web.
Une grande majorité des sites web l’utilisent.

Figure 3.5.2 JavaScript

4
JIT: « just in time »
5
Word Wide Web : la Toile mondiale ou la Toile, est un système hypertexte public fonctionnant
sur Internet

~ 35 ~
c) PHP (Hypertext Preprocessor)
Plus connu sous son sigle PHP (sigle auto-référentiel), est un langage de
programmation libre, principalement utilisé pour produire des pages Web
dynamiques via un serveur HTTP6 (Hypertext Transfer Protocol), mais pouvant
également fonctionner comme n'importe quel langage interprété de façon locale.
PHP est un langage impératif orienté objet. PHP a permis de créer un grand nombre
de sites web célèbres, comme Facebook. Il est considéré comme une des bases de
la création de sites web dits dynamiques mais également des applications web.
C'est un langage peu typé et souple et donc facile à apprendre par un débutant. Il
est multi-plateforme : autant sur Linux qu'avec Windows il permet aisément de
reconduire le même code sur un environnement à peu près semblable.

Figure 3.5.3 PHP

d) Java
Java est un langage de programmation largement utilisé pour coder des
applications web. Il a été fréquemment choisi parmi les développeurs depuis plus
de deux décennies, des millions d'applications Java étant utilisées aujourd'hui. Java
est un langage multiplateforme, orienté objet et centré sur le réseau, qui peut être
utilisé comme une plateforme à part entière. Il s'agit d'un langage de programmation
rapide, sécurisé et fiable qui permet de tout coder, des applications mobiles aux
logiciels d'entreprise en passant par les applications de big data et les technologies
côté serveur.

6
HTTP : c’est un protocole de communication client-serveur développé pour le World Wide Web

~ 36 ~
 Figure 3.5.4 JAVA

e) C Sharp (C#)
C’est un langage de programmation orienté objet à typage fort, créé par la
société Microsoft, et notamment un de ses employés, Anders Hejlsberg, le créateur
du langage Delphi. Il a été créé afin que la plate-forme Microsoft .NET soit dotée
d'un langage permettant d'utiliser toutes ses capacités. Il est très proche du Java dont
il reprend la syntaxe générale ainsi que les concepts (la syntaxe reste cependant
relativement semblable à celles de langages tels que le C++ et le C). Un ajout
notable à Java est la possibilité de surcharge des opérateurs, inspirée du C++.
Toutefois, l'implémentation de la redéfinition est plus proche de celle du Pascal
Objet.

Figure 3.5.5 C
SHARP

f) Python
Le langage Python est un langage de programmation open source multi-
plateformes et orienté objet. Grâce à des bibliothèques spécialisées, Python s'utilise
pour de nombreuses situations comme le développement logiciel, l'analyse de
données, ou la gestion d'infrastructures. Il n'est donc pas, comme le
langage HTML par exemple, uniquement dédié à la programmation web. Langage
de programmation interprété, Python permet l'exécution du code sur n'importe quel
ordinateur. Utilisable aussi bien par des programmeurs débutants qu'experts,
Python permet de créer des programmes de manière simple et rapide. Python est
principalement utilisé pour le scripting et l'automatisation de tâches simples mais

~ 37 ~
fastidieuses, c'est-à-dire l'interaction avec les navigateurs web. Mais Python est
aussi utilisé pour : programmer des applications ; générer du code ; créer des
services web ; faire de la métaprogrammation.

Figure 3.5.6 Python

3.5.1.2. Choix des langages de programmation

Notre choix des langages de programmation se porte sur le HTML-CSS, le
JS et le PHP qui sont incontournables dans la programmation web. Le HTML-CSS
et le JS nous permettront de gérer l’affichage côté utilisateur et le PHP se chargera
de la partie traitement des informations en interagissant avec la base de données
pour apporter plus de dynamisme dans l’application.
Etant donné que nous avons fait notre choix sur les langages de programmation,
faisons la présentation de quelques framework PHP.

3.5.1.3. Quelques framework PHP

Un Framework est une sorte de cadre applicatif structurant qui permet de
réduire le temps de développement des applications, tout en répondant de façon
efficace aux problèmes rencontrés le plus souvent par les développeurs. Il existe
plusieurs framework notamment Laravel, Symfony, CodeIgniter, SamaneMVC, …
a) Laravel

Laravel est un framework PHP multi-plateforme permettant de créer des

applications web. Mais pour bien comprendre les avantages de Laravel et ses
utilisations, il faut plonger plus profondément. Laravel permet à un développeur de
tirer parti d’une vaste bibliothèque de fonctionnalités préprogrammées (telles que
l’authentification, le routage et la création de modèles HTML). L’accès à cette
bibliothèque simplifie la création rapide d’applications web robustes tout en
minimisant la quantité de codes nécessaires. Laravel offre un environnement de
développement très fonctionnel, ainsi que des interfaces de ligne de commande
~ 38 ~
intuitives et expressives. En outre, Laravel utilise la cartographie objet-
relationnel (ORM) pour simplifier l’accès et la manipulation des données. Les
applications Laravel sont hautement évolutives et leur base de code est facile à
maintenir. Les développeurs peuvent également ajouter des fonctionnalités à leurs
applications de manière transparente, grâce au système de packaging modulaire de
Laravel et à la gestion robuste des dépendances.

Figure 3.5.7 Laravel

b) Symfony

Symfony est un framework qui représente un ensemble de composants

(aussi appelés librairies) PHP autonomes qui peuvent être utilisés dans des projets
web privé ou open source. Mais c’est également un puissant framework
PHP développé par une société française : SensioLabs. Il permet de réaliser des
sites internet dynamiques de manière rapide, structurée, et avec un développement
clair. Les développeurs peuvent travailler sur ce Framework très facilement, seuls
ou en équipe, grâce à la facilité de prise en main. Symfony est “open source” avec
architecture MVC (Modèle-vue-contrôleur) qui vise à accélérer la création et la
maintenance des applications web et à remplacer les tâches de codage récurrentes.

Figure 3.5.8 Symfony

~ 39 ~
c) SamaneMVC

SamaneMVC est un framework PHP qui permet également de produire un

code de qualité puisque celui-ci est structuré grâce au modèle de conception MVC
et sécurisé car les composants ont été développés, testés et approuvés par des
personnes compétentes. SamaneMVC permet aux développeurs de gagner en
rapidité puisque toute la partie technique (architecture, structure et bibliothèque) est
déjà gérée. Cela permet au développeur de se concentrer uniquement sur le
développement des composants métiers. Il accélère la création et la maintenance de
vos applications web. Il permet aussi d’optimiser les tâches de codage répétitives et
de profiter de la puissance de contrôle de votre code. Il adopte et promeut le
professionnalisme, les meilleures pratiques, la normalisation et l'interopérabilité.

Figure 3.5.9 SamaneMVC

3.5.1.4. Choix du framework

Le framework que nous avons choisi est Symfony. Ce dernier offre un
environnement de développement stable. Les principaux avantages de l’outil sont
sa flexibilité, ses performances, sa facilité d’utilisation mais aussi et surtout
sa communauté. Il est l’un des framework PHP les plus riches en fonctionnalités.
Comme nous l’avons souligné précédemment, le framework offre une grande
flexibilité aux développeurs. De plus, le framework intègre les meilleures pratiques
pour aider les débutants à apprendre rapidement. Il existe une documentation
complète et détaillée qui est extrêmement utile pour les débutants et les
développeurs expérimentés. Elle est considérée comme l’une des meilleures
documentations parmi les autres framework PHP. Chaque composant est bien
expliqué et simplifié par des exemples. De plus, il bénéficie également d’un grand
soutien de la communauté. Il offre une configuration facile et un mécanisme de
mise en cache pour améliorer les performances des applications.

~ 40 ~
Ainsi, nous avons choisi un framework PHP pour nous faciliter le développement
de l’application. Nous allons donc entamer la dernière section de ce chapitre qui est
la présentation des SGBD.

3.5.2. Présentation des SGBD

Un système de gestion de base de données (SGBD) est le logiciel qui permet
à un ordinateur de stocker, récupérer, ajouter, supprimer et modifier des données.
Un SGBD gère tous les aspects primaires d'une base de données, y compris la
gestion de la manipulation des données, comme l'authentification des utilisateurs,
ainsi que l'insertion ou l'extraction des données. Un SGBD définit ce qu'on appelle
le schéma de données ou la structure dans laquelle les données sont stockées.
Mettons en avant quelques-uns de ces SGBD car ils sont très nombreux.

3.5.2.1. Quelques SGBD

Nous allons faire la présentation de quatre (04) SGBD les plus populaires qui sont
MySQL, MariaDB, Oracle Database, SQL Server
a) MySQL
MySQL a été lancé à l’origine en 1995. Depuis, il a connu quelques
changements de propriétaire et de gestion, avant de se retrouver chez Oracle
Corporation en 2010. Alors qu’Oracle est en charge maintenant, MySQL est
toujours un logiciel open source, ce qui signifie que vous pouvez l’utiliser et le
modifier librement. MySQL est un serveur de bases de données
relationnelles SQL développé dans un souci de performances élevées en lecture, ce
qui signifie qu'il est davantage orienté vers le service de données déjà en place que
vers celui de mises à jour fréquentes et fortement sécurisées. Il est multi-thread7 et
multi-utilisateur. MySQL fonctionne sur de nombreux systèmes
d'exploitation différents comme Linux, Unix (Solaris, HP-UX, …), Apple (Mac
OS), Windows, etc.

Figure 3.5.10
MySQL

7
Multi-thread : capable d’executer plusieurs tâches à la fois

~ 41 ~
b) MariaDB
MariaDB est un fork8 développé par la communauté et pris en charge
commercialement du système de gestion de base de données relationnelle MySQL
(RDBMS), destiné à rester un logiciel libre et open source sous la licence publique
générale GNU. Le développement est dirigé par certains des développeurs
originaux de MySQL, qui l'ont dérivé en raison de préoccupations concernant
son acquisition par Oracle Corporation en 2009. MariaDB est destinée à maintenir
une compatibilité élevée avec MySQL, avec une parité binaire de la bibliothèque et
une correspondance exacte avec les API et les commandes MySQL, lui permettant
dans de nombreux cas de fonctionner comme un remplacement direct de
MySQL. Cependant, les nouvelles fonctionnalités divergent.

Figure 3.5.11 MariaDB

c) Oracle Database
Oracle est un système de gestion de base de données relationnel (SGBDR)
qui depuis l'introduction du support du modèle objet dans sa version 8 peut être
aussi qualifié de système de gestion de base de données relationnel-objet
(SGBDRO). Fourni par Oracle Corporation, il a été développé par Larry Ellison,
accompagné d'autres personnes telles que Bob Miner et Ed Oates. Oracle n’est pas
un SGBD optimisé pour de petites entreprises ayant de petits volumes de données
et un peu d’utilisateurs (une vingtaine). Si la gestion des données devient importante
63 et le nombre d’utilisateurs devient également grandissant alors la nécessité quant
au choix d’un SGBD performant s’impose, et Oracle est une solution.

8
Fork : un nouveau logiciel créé à partir du code source d’un logiciel existant

~ 42 ~
 Figure 3.5.12 ORACLE DATABASE

d) SQL Server
Microsoft SQL Server est un système de gestion de base de données
relationnelle développé par Microsoft. En tant que serveur de base de données, il
est un produit de logiciel avec la fonction principale de stockage et de récupération
de données tel que demandé par d'autres applications logicielles pouvant circuler
sur le même ordinateur ou sur un autre ordinateur dans un réseau (y compris
l'Internet). Microsoft SQL Server fait désormais partie de la stratégie technique de
Microsoft, en matière de base de données. Le moteur MSDE qui est à la base de
SQL Server doit à terme remplacer le moteur Jet (qui gère les bases Access), dans
les applications telles qu’Exchange et Active Directory.

Figure 3.5.13 SQL SERVER

3.5.2.2. Choix du SGBD

A l’issue de la présentation des différents systèmes de gestion de base de
données (SGBD), notre choix s’est porté sur MariaDB. Il est un connu par sa
simplicité et adapté pour une structure de moyenne taille. En plus d’avoir une
interface conviviale mais aussi il assure l’intégrité des données donc sécurisé.
MariaDB propose non seulement un large choix de moteurs de base de données
alternatifs, mais offre également un optimiseur de requêtes SQL efficace.
Cette section nous a permis de voir les SGBD disponibles sur le marché.

~ 43 ~
En somme, ce chapitre a servi de support de présentation des outils de
développement et des SGBD. Nous attaquerons dans le prochain les architectures.

3.6. Architectures
Nous allons présenter dans ce chapitre deux sections, les architectures et le
choix qui s’en suit.

3.6.1. Présentation
Les architectures se déclinent sur deux types à savoir les architectures deux-
tier et trois-tier.

3.6.1.1. Architecture deux-tier

L’architecture à deux niveaux caractérise les systèmes clients/serveurs. On
peut séparer ce type d'application en deux types :
➢ orienté clients
➢ orienté serveur.
Dans les applications orienté clients, la plupart des traitements sont effectués sur le
poste du client qui possède une Interface Homme Machine (IHM) dite "lourde".
Dans celles orienté serveurs, c'est le serveur qui effectue tous les traitements. Le
client lui possède une IHM légère. Qu'elle soit légère ou lourde l'IHM est
propriétaire et nécessite donc une installation sur le poste client. Cela rend
l'installation d'une telle application très lourde si le nombre de clients est important.
De plus, on peut très difficilement réutiliser ce type d'application car l'IHM est
dédiée et composée d'un seul bloc. Enfin les performances réseaux ne sont pas très
élevés car de nombreuses requêtes doivent transiter par le réseau. On peut
représenter cette architecture par le schéma ci-dessous.

Figure 3.6.1 Architecture deux-tier

~ 44 ~
 3.6.1.2. Architecture trois-tier
Dans une telle architecture, on a séparé la partie applicative ou traitement
de l'IHM et des données. On obtient donc les trois couches suivantes :
➢ la couche présentation.
➢ la couche application
➢ la couche donnée ou métier.
Chacune de ces trois couches a un rôle spécifique.
La couche présentation est chargée du traitement de l'interaction avec l'utilisateur.
C'est un rôle d'affichage et d'interaction.
La couche application effectue les traitements applicatifs. Elle effectue de plus le
tampon entre la présentation et les données. Elle effectue aussi les règles de gestion
de l'application.
La partie donnée stocke les données pérennes de l'entreprise ou de l'application.
Cette séparation en trois couches simplifie les procédures d'installations de logiciel,
le partage d'information entre applications et enfin la réutilisation de composants.
On parle d'architecture trois-tier mais aussi d'architecture n-tier. En effet, dans la
plupart des applications, le niveau intermédiaire est une collection de composants
qui sont utilisés dans de nombreux traitements transactionnels. Ces composants
peuvent être situés sur un ou plusieurs serveurs physiques. De plus chacun de ces
composants effectue une petite tâche et c'est pourquoi on peut séparer cette partie
intermédiaire en n partie d'où le terme architecture n-tier.
La représentation d'une architecture trois-tier est la suivante.

Figure 3.6.2 Architecture trois-tier

~ 45 ~
 3.6.2. Choix de l’architecture
Notre choix se porte sur l’architecture 3-tiers car elle est une architecture
client/serveur dans laquelle les applications au niveau serveur sont délocalisées,
c'est-à-dire que chaque serveur est spécialisé dans une tâche (serveur web/serveur
de base de données par exemple). L’architecture à trois niveaux permet une grande
flexibilité, une sécurité accrue car la sécurité peut être définie indépendamment
pour chaque service et à chaque niveau, de meilleures performances, grâce au
partage des tâches entre les différents serveurs. De plus, dans la même approche,
on peut dire au vu de l'explosion d’Internet que le navigateur Web est le client
universel, puisque de plus en plus utilisé pour tout type de développement, ou
d'interface.
Ce chapitre a fait l’objet de la présentation et du choix de l’architecture à adopter.
Nous allons voir le chapitre suivant sur l’implémentation.

3.7. Implémentation
Nous allons faire la capture de l’interface de notre plateforme en montrant
la page de connexion et la page d’accueil.

3.7.1. Interface de connexion

Figure 3.7.1 Interface de connexion

~ 46 ~
 3.7.2. Interface Accueil

Figure 3.7.2 Interface Accueil

Ce chapitre clôt cette troisième et dernière partie de notre étude constituée de la

réalisation, de l’architecture et de l’implémentation.

~ 47 ~
 CONCLUSION GENERALE
Au terme de notre réflexion, nous avons pu porter une étude sur la mise en
place d’une plateforme web de location et de vente de biens immobiliers en faisant
la présentation des cadres théorique et méthodologique, des différentes étapes de
l’analyse et de la conception ainsi que de la mise en œuvre. Notre sujet avait pour
ambition de savoir si l’informatisation de l’immobilier serait un atout majeur pour
un éventuel développement.

Cette étude nous a permis de mettre en place une application web sur la
location et la vente de biens immobiliers. Elle permettra de réduire le déplacement
pour rechercher des biens immobiliers, d’abaisser les coûts en sautant les
intermédiaires (courtiers) et surtout de participer au développement du secteur
immobilier dans un contexte entièrement soumis au numérique.

La recherche apportée à ce sujet de mémoire a fait l’objet d’une expérience

intéressante, qui nous a permis d’en savoir un peu plus sur le domaine de
l’immobilier, d’acquérir et de consolider nos connaissances dans la gestion de nos
projets et dans la programmation, et surtout de savoir comment organiser nos
recherches. Néanmoins, nous avons eu du mal à rencontrer et échanger avec des
personnes compétentes dans le secteur de l’immobilier. S’y ajoutent les bugs lors
de la réalisation de l’application.

Pour une bonne sûreté de notre application, il est recommandé de procéder

à une phase de test. Les bugs seront fortement suivis et nous sommes à l’écoute
pour d’éventuels requêtes pour l’obtention d’une application plus performante. En
guise de perspective, nous pouvons enrichir les fonctionnalités disponibles dans
l’application en donnant la possibilité d’effectuer des paiements en ligne.

~ 48 ~
 Bibliographie

I- Mémoires

SEYE Sokhna Aminata, Réalisation d’une application pour la gestion d’une

école moderne d’enseignement mixte coranique et conventionnel : cas de
l’Ecole Al Hidaaya, ISI, 2021-2022, 76 pages.

DIALLO Saifoulaye, Mise en place d’une plateforme de gestion de biens

immobiliers (vente & location) pour l’entreprise MARLY-IMMO, ISI, 2020-
2021, 74 pages.

II- Cours
M. Mallé NDIAYE : cours d’UML

~ 49 ~
 Wébographie
https://www.techno-science.net/definition/739.html: 17/10/2022, 13:52
https://web.maths.unsw.edu.au/~lafaye/CCM/merise/concintro.htm: 17/10/2022,
14:24
https://www.universalis.fr/encyclopedie/systemes-informatiques-conception-
architecture-et-urbanisation-des-systemes-d-information/: 17/10/2022, 15:00
https://bbf.enssib.fr/consulter/bbf-1994-03-0068-002: 17/10/2022, 15:45
https://payfit.com/fr/fiches-pratiques/systeme-information/: 17/10/2022, 19:00
https://www.ibm.com/docs/fr/rsm/7.5.0?topic=diagrams-lifelines-in-uml:
19/10/2022, 14:42
https://laurent-audibert.developpez.com/Cours-UML/?page=diagrammes-
interaction: 19/10/2022, 18:39
https://laurent-audibert.developpez.com/Cours-UML/?page=diagramme-classes:
19/10/2022, 19:04
https://lipn.univ-paris13.fr/~gerard/uml-s2/uml-cours01.html: 19/10/2022, 20:04
https://www.ibm.com/docs/fr/rsar/9.5?topic=diagrams-relationships-in-class:
19/10/2022, 21:00

~ 50 ~
 Table des matières

DEDICACE ............................................................................................................ I

REMERCIEMENTS ............................................................................................ II

AVANT-PROPOS ................................................................................................ III

SOMMAIRE........................................................................................................ IV

GLOSSAIRE ......................................................................................................... V

Liste des figures ................................................................................................... VI

Liste des tableaux .............................................................................................. VIII

Résumé ................................................................................................................. IX

Abstract.................................................................................................................. X

INTRODUCTION GENERALE .......................................................................... 1

I. Les cadres théorique et méthodologique ...................................................... 3

1.1. Cadre théorique ....................................................................................... 3

1.1.1. Contexte et Problématique .............................................................. 3

1.1.2. Objet de l’étude ................................................................................ 4

1.1.3. Analyse de l’existant ........................................................................ 4

1.2. Cadre méthodologique ............................................................................ 6

1.2.1. Méthodes d’analyse et de conception ............................................. 6

1.2.1.1. MERISE ........................................................................................ 6

1.2.1.2. UML ............................................................................................ 12

1.2.2. Comparaison entre MERISE ET UML ....................................... 22

1.2.3. Choix de la méthode conception ................................................... 23

II. Analyse et Conception .............................................................................. 25

2.3. Analyse du système ............................................................................... 25

2.3.1. Besoins fonctionnels ....................................................................... 25

2.3.2. Besoins non-fonctionnels ............................................................... 26

~ 51 ~
 2.3.3. Rédaction du cahier de charges .................................................... 26

2.4. Conception ............................................................................................. 27

2.4.1. Diagramme de cas d’utilisation .................................................... 27

2.4.1.1. Gestion des biens et des annonces ............................................. 27

2.4.1.2. Gestion des contrats ................................................................... 28

2.4.1.3. Gestion des règlements .............................................................. 28

2.4.1.4. Gestion des utilisateurs .............................................................. 29

2.4.2. Diagramme de séquence ................................................................ 29

2.4.2.1. Cas d’utilisation se connecter .................................................... 29

2.4.2.2. Cas d’utilisation ajouter bien .................................................... 30

2.4.2.3. Cas d’utilisation supprimer bien .............................................. 31

2.4.4. Diagramme déploiement ............................................................... 33

III. Mise en œuvre............................................................................................ 33

3.5. Réalisation .............................................................................................. 33

3.5.1. Outils de développement ............................................................... 34

3.5.1.1. Quelques langages de programmation ..................................... 34

3.5.1.2. Choix des langages de programmation .................................... 38

3.5.1.3. Quelques framework PHP ......................................................... 38

3.5.1.4. Choix du framework .................................................................. 40

3.5.2. Présentation des SGBD ................................................................. 41

3.5.2.1. Quelques SGBD .......................................................................... 41

3.5.2.2. Choix du SGBD .......................................................................... 43

3.6. Architectures ......................................................................................... 44

3.6.1. Présentation .................................................................................... 44

3.6.1.1. Architecture deux-tier ............................................................... 44

3.6.1.2. Architecture trois-tier ................................................................ 45

3.6.2. Choix de l’architecture .................................................................. 46

~ 52 ~
 3.7. Implémentation ..................................................................................... 46

3.7.1. Interface de connexion................................................................... 46

3.7.2. Interface Accueil ............................................................................ 47

CONCLUSION GENERALE ............................................................................. 48

Bibliographie ........................................................................................................ 49

Wébographie ........................................................................................................ 50

Table des matières ............................................................................................... 51

~ 53 ~