SOMMAIRE

Sommaire …………………………………………………………………………......

Dédicaces 1 …………………………………………………………………………...

Remerciements ……………………………………………………………………….

Liste des tableaux …………………………………………………………………....

Liste des figures ……………………………………………………………………...

Liste des sigles et abréviations ………………………………………………………

Résumé ………………………………………………………………………………..

Abstract ………………………………………………………………………………

INTRODUCTION GENERALE...............................................................................

CHAPITRE 1 : PRESENTATION DU PROJET ...................................................

I. Problématique .....................................................................................................
II. Etude de l’existant ..............................................................................................
III. Présentation du projet .........................................................................................
IV Description du processus métier .........................................................................

CHAPITRE 2 : ANALYSE ET CONCEPTION DE L’APPLICATION .............

I. Présentation du langage de modélisation UML .....................................................

II. Modélisation fonctionnelle ....................................................................................
III. Modélisation dynamique........................................................................................
IV. Modélisation dynamique .......................................................................................

CHAPITRE 3 : DEVELOPPEMENT DE L’APPLICATION...............................

I. Architecture logicielle et outils développement .....................................................

II. Implémentation de la base de données ..................................................................
III. Développement des interfaces homme-machine ...................................................
IV. Mesure de sécurité .................................................................................................

Conclusion …………………………………………………………………………..

ANNEX ……………………………………………………………………………..
Dédicaces 1

Je dédie ce travail à toutes les personnes qui, de près ou de loin, ont contribué à mon
parcours et à ma réussite.

À mes très chers parents,

HESSOU Pierre et AKOUEHOU Juliette,
pour leur amour inconditionnel, leurs sacrifices inestimables, leurs prières et leurs
précieux conseils. Vous avez toujours été mon pilier et ma source de motivation. Que
ce travail soit le témoignage de ma profonde reconnaissance et de mon éternelle
gratitude.

À mes frères et sœurs,

pour leur soutien moral, leur présence constante et leurs encouragements. Vous avez
été une véritable force dans les moments difficiles.

À mon oncle,
HESSOU Christophe,
pour sa bienveillance, son accompagnement et son soutien indéfectible. Votre
confiance en moi a été une source permanente d’inspiration.

À tous mes proches, amis et connaissances,

qui m’ont soutenu, encouragé et accompagné tout au long de ce parcours.

Que chacun trouve ici l’expression de ma sincère gratitude.

HESSOU Euloge Grâcien

Dédicaces 2

À l'issue de ce long et enrichissant parcours académique, je tiens à dédier ce mémoire

intitulé « Création d'une application web et mobile de gestion immobilière » aux
personnes qui ont toujours été à mes côtés avec amour, soutien et encouragements.

À mes très chers parents,

AHOSSAN Pascal, mon père, et KPOTON Virginie, ma mère. Vous avez été mes
premiers enseignants, mes guides et mes piliers. Votre amour inconditionnel, vos
sacrifices et votre foi en moi ont été le moteur de chacun de mes pas. Ce travail est
avant tout le vôtre. Que Dieu vous accorde longue vie et santé.

À mes grands frères,

AHOSSAN Melquior et AHOSSAN Carmel. Votre présence fraternelle, vos conseils

avisés et votre soutien constant m'ont aidé à relever les défis avec courage et
persévérance. Vous avez toujours été pour moi des exemples à suivre. Puisse ce
travail vous rendre fiers.

À mon oncle,

KPOTON Marc. Votre bienveillance et votre soutien tout au long de mon parcours ont
été une source précieuse de motivation. Merci pour tout ce que vous avez fait pour
moi. Je vous témoigne ici ma profonde gratitude et mon affection sincère.

AHOSSAN Sergio Boris

Remerciements
Nous tenons à exprimer notre profonde gratitude envers les personnes qui
contribué à la réalisation de ce travail. Leur soutien, leurs conseils et leur présence
ont été essentiels tout au long de ce parcours académique.
• Monsieur Théophane AYI, le Directeur Général de L’UATM Gasa formation, pour sa
vision et son engagement en faveur de l’éducation ;
• Monsieur Lafitte NGUEMEGNE, le Directeur Technique du groupe AYI, pour sa
précieuse expertise et son accompagnement ;
• Monsieur Constant AGBOCOU, le Directeur des Études de Calavi, pour ses
encouragements et son suivi attentif ;
• Monsieur OGUNDE Zhoulikoufouli, notre Directeur de mémoire, pour ses conseils
éclairés et sa patience ;
• Tout le personnel administratif et enseignant, dont l’implication a contribué à
notre formation ;
• Nos camarades de promotion de la filière Système Informatique et Logiciel, avec qui
nous avons partagé des moments d’apprentissage, de doute et de célébration ;
• Nos parents et amis, qui de près ou de loin, ont soutenu nos efforts et ont été nos
sources d’inspiration.
Liste des figures
Figure 1 : Diagramme de contexte statique.......................................................................
Figure 2 : Diagramme de cas d’utilisation..........................................................................
Figure 3 : Diagramme de séquence S’inscrire....................................................................
Figure 4 : Diagramme de séquence S’authentifier.............................................................
Figure 5 : Diagramme de séquence Rechercher un bien....................................................
Figure 6 : Diagramme de séquence Réserver ou paiement total d’un bien.......................
Figure 7 : Diagramme d’activité S’inscrire..........................................................................
Figure 8 : Diagramme d’activité S’authentifier..................................................................
Figure 9 : Diagramme d’activité Rechercher un bien.........................................................
Figure 10 : Diagramme d’activité Réserver un bien...........................................................
Figure 11 : Diagramme de classes......................................................................................
Figure 12 : Diagramme d’objets.........................................................................................
Figure 13 : Illustration de l’architecture MVC (Model View Controller).............................
Figure 14 : Interface d’accueil............................................................................................
Figure 15 : Interface d’inscription......................................................................................
Figure 16 : Interface de connexion....................................................................................
Figure 17 : Interface de liste et recherche des biens.........................................................
Figure 18 : Interface de détail d’un bien............................................................................
Figure 19 : Interface de réservation d’un bien...................................................................
Figure 20 : Interface de paiement via Kkiapay...................................................................
Figure 21 : Interface de l’historique des réservations........................................................
Figure 22 : Interface des favoris du client..........................................................................
Figure 23 : Interface du tableau de bord administrateur d’agence...................................
Figure 24 : Interface de gestion des biens.........................................................................
Figure 25 : Interface d’ajout d’un bien...............................................................................
Figure 26 : Interface des notifications d’un client..............................................................
Figure 27 : Interface de gestion des administrateurs.........................................................
Figure 28 : Interface du tableau de bord super administrateur.........................................
Figure 29 : Interface de création d’une agence.................................................................
Figure 30 : Interface d’accueil de l’application mobile......................................................
Figure 31 : Interface d’inscription et de connexion mobile...............................................
Figure 32 : Interface de détail d’un bien et de réservation mobile....................................
Figure 33 : Interface de paiement mobile via Kkiapay.......................................................
Figure 34 : Interface des historiques du client mobile.......................................................
Figure 35 : Interface des favoris mobile.............................................................................

Liste des tableaux

Tableau 1 : Identification des acteurs et cas d’utilisation..................................................
Tableau 2 : Scénario nominal – S’inscrire..........................................................................
Tableau 3 : Scénario alternatif – S’inscrire.........................................................................
Tableau 4 : Scénario nominal – S’authentifier...................................................................
Tableau 5 : Scénario alternatif – S’authentifier..................................................................
Tableau 6 : Scénario nominal – Rechercher un bien..........................................................
Tableau 7 : Scénario alternatif – Rechercher un bien........................................................
Tableau 8 : Scénario nominal – Réserver un bien..............................................................
Tableau 9 : Scénario alternatif – Réserver un bien............................................................
Tableau 10 : Classes et attributs principaux.......................................................................

Liste des sigles et abréviations

API : Application Programming Interface
Bootstrap : Framework CSS front-end
CSRF : Cross-Site Request Forgery
CSS : Cascading Style Sheets
Flutter : Framework de développement mobile multiplateforme
GIT : Gestionnaire de versions distribué
HTML : HyperText Markup Language
HTTPS : HyperText Transfer Protocol Secure
IDE : Integrated Development Environment
JavaScript : Langage de programmation côté client
JWT : JSON Web Token
Kkiapay : Solution de paiement en ligne pour l’Afrique de l’Ouest
Laravel : Framework PHP pour le développement web
MVC : Model View Controller
MySQL : My Structured Query Language
OMG : Object Management Group
ORM : Object-Relational Mapping
PHP : Hypertext Preprocessor
POO : Programmation Orientée Objet
REST : Representational State Transfer
RGPD : Règlement Général sur la Protection des Données
SGBD : Système de Gestion de Base de Données
SQL : Structured Query Language
UML : Unified Modeling Language
Résumé

Ce projet porte sur la conception et le développement d'une solution numérique

complète de gestion immobilière, baptisée ImmoGo. Il répond à un besoin réel de
modernisation du secteur immobilier au Bénin, où les pratiques de gestion restent
encore très peu numérisées : annonces dispersées sur les réseaux sociaux, absence de
suivi des transactions, et difficulté pour les clients à trouver des informations fiables
sur les biens disponibles.

La solution développée se compose de deux parties complémentaires : une application

web accessible depuis un navigateur, et une application mobile disponible sur Android
et iOS. Les deux interfaces partagent le même backend et offrent les mêmes
fonctionnalités, adaptées à chaque support.

L'application propose plusieurs fonctionnalités essentielles, notamment :

 La consultation libre des biens immobiliers disponibles sans création de

compte,
 La recherche et le filtrage des biens par localisation, type et budget,
 La réservation d'un bien avec paiement d'un acompte de 10 % du montant
total,
 Le paiement complet ou du solde restant directement depuis l'application,
 L'intégration d'un système de paiement en ligne sécurisé via Kkiapay,
 Un espace de gestion complet pour les administrateurs d'agence (publication
et gestion des biens, suivi des réservations, gestion des membres de l'équipe),
 Un espace dédié au super administrateur pour la création et la gestion des
agences,
 Un système d'authentification sécurisé avec gestion des rôles (super
administrateur, administrateur principal, administrateur assistant, client),
 Un système de notifications pour informer les clients des étapes de leurs
réservations,
 Un journal d'activité permettant de tracer toutes les actions effectuées sur la
plateforme.

Une attention particulière a été portée à l'expérience utilisateur, avec des interfaces
claires, une navigation fluide et un design responsive qui s'adapte aussi bien aux
grands écrans qu'aux smartphones.

Sur le plan de la sécurité, l'application intègre plusieurs bonnes pratiques : chiffrement

des mots de passe, protection contre les injections SQL et les attaques XSS, tokens
CSRF sur tous les formulaires, gestion des sessions et sécurisation des échanges via
HTTPS. Les paiements sont entièrement délégués à Kkiapay, garantissant la
confidentialité des données financières des utilisateurs.

La conception du système a été guidée par une démarche de modélisation rigoureuse

basée sur les diagrammes UML : diagrammes de cas d'utilisation, de séquence,
d'activité et de classes, assurant la cohérence et l'évolutivité de l'ensemble de la
solution.

ImmoGo constitue une réponse concrète aux limites des méthodes traditionnelles de
gestion immobilière, en facilitant le travail des agences tout en simplifiant la recherche
et la réservation de biens pour les clients. C'est une solution technologique solide,
évolutive et sécurisée, pensée pour accompagner la transformation numérique du
secteur immobilier au Bénin.

Abstract

This project focuses on the design and development of a complete digital real estate
management solution called ImmoGo. It addresses a genuine need for modernization
in the real estate sector in Benin, where management practices remain largely
undigitized: property listings scattered across social networks, no transaction tracking,
and difficulty for clients to find reliable information about available properties.

The developed solution consists of two complementary parts: a web application

accessible from a browser, and a mobile application available on Android and iOS.
Both interfaces share the same backend and offer the same features, adapted to each
platform.

The application provides several key features, including:

 Free browsing of available real estate properties without account creation,

 Searching and filtering properties by location, type and budget,
 Property reservation with payment of a 10% deposit on the total amount,
 Full payment or remaining balance payment directly from the application,
 Integration of a secure online payment system via Kkiapay,
 A complete management interface for agency administrators (property
publishing and management, reservation tracking, team member management),
 A dedicated space for the super administrator to create and manage agencies,
 A secure authentication system with role management (super administrator,
principal administrator, assistant administrator, client),
 A notification system to keep clients informed about their reservation progress,
 An activity log to track all actions performed on the platform.

Special attention was paid to user experience, with clear interfaces, smooth navigation,
and a responsive design that adapts to both large screens and smartphones.

In terms of security, the application incorporates several best practices: password

encryption, protection against SQL injection and XSS attacks, CSRF tokens on all
forms, session management, and secure communication via HTTPS. Payments are
fully delegated to Kkiapay, ensuring the confidentiality of users' financial data.
The system design was guided by a rigorous modeling approach based on UML
diagrams: use case, sequence, activity and class diagrams, ensuring the consistency
and scalability of the entire solution.

ImmoGo provides a concrete response to the limitations of traditional real estate

management methods, making agency operations easier while simplifying property
search and booking for clients. It is a solid, scalable and secure technological solution,
designed to support the digital transformation of the real estate sector in Benin.

INTRODUCTION
 Le secteur immobilier occupe une place importante dans l'économie des pays en
développement, particulièrement en Afrique où la demande en logements ne cesse
d'augmenter. Malgré cette réalité, les pratiques de gestion immobilière restent encore
très peu numérisées dans notre contexte local. Les agences gèrent leurs biens sur
papier ou via des outils non adaptés, les annonces se font par bouche-à-oreille ou sur
des groupes de réseaux sociaux, et les clients peinent à trouver des informations fiables
sur les biens disponibles.

Cette situation pose un problème réel des deux côtés. Les agences ont du mal à
toucher suffisamment de clients et à gérer efficacement leur portefeuille de biens. Les
clients, de leur côté, sont obligés de se déplacer d'agence en agence, de passer des
appels sans réponse, ou de faire confiance à des annonces douteuses sur des
plateformes non spécialisées.

Face à ce constat, nous avons décidé de consacrer notre projet de fin d'études à
la conception et au développement d'une solution complète de gestion immobilière.
Notre application, baptisée ImmoGo, est accessible à la fois depuis un navigateur web
et depuis un smartphone, ce qui lui permet de toucher le plus grand nombre
d'utilisateurs possible. Elle met en relation les agences immobilières et leurs clients de
manière simple, claire et sécurisée.

Ce document présente l'ensemble de notre démarche, depuis l'identification du

problème jusqu'à la réalisation concrète de la solution. Il est structuré en trois chapitres
: le premier présente le projet et son contexte, le deuxième traite de l'analyse et de la
conception, et le troisième est consacré au développement et à l'implémentation de
l'application.
 CHAPITRE 1 :
PRÉSENTATION DU PROJET
I. Problématique
La gestion immobilière telle qu'elle se pratique aujourd'hui dans notre
environnement souffre de plusieurs lacunes qui pénalisent aussi bien les agences que
leurs clients. Une agence qui gère plusieurs dizaines de biens sans outil numérique se
retrouve vite dépassée : les informations sont éparpillées, le suivi des paiements est
approximatif, et la communication avec les clients demande beaucoup de temps et
d'énergie. De l'autre côté, un client à la recherche d'un logement doit souvent se
déplacer dans plusieurs agences, appeler des numéros qui ne répondent pas, ou se fier
à des annonces publiées sur des groupes WhatsApp sans aucune garantie de fiabilité.

Trois problèmes principaux ressortent de cette situation :

La dispersion de l'information : il n'existe pas, dans notre contexte local, de

plateforme centralisée où un client peut consulter en un seul endroit les biens proposés
par plusieurs agences, comparer les prix et prendre une décision en connaissance de
cause.

L'absence de traçabilité financière : les transactions, qu'il s'agisse de loyers, d'achats

ou de réservations, se font souvent de manière informelle, sans reçu ni suivi. Cela
expose les deux parties à des malentendus ou des litiges difficiles à résoudre.

Le manque d'outils de gestion pour les agences : une agence qui dispose de
plusieurs collaborateurs a besoin d'un système qui lui permet de répartir les tâches, de
suivre l'état de chaque bien et de garder un historique clair de toutes les opérations.

La question qui guide notre travail est donc la suivante : comment concevoir
une application, accessible aussi bien depuis un ordinateur que depuis un téléphone,
qui centralise la gestion immobilière, facilite la mise en relation entre agences et
clients, et sécurise les transactions, tout en restant simple à utiliser pour tout le
monde ?

II. Étude de l'existant

Avant de nous lancer dans la conception de notre solution, nous avons pris le
temps d'observer ce qui existe déjà sur le marché, afin d'en comprendre les forces et les
limites.

Parmi les plateformes que nous avons analysées, on peut citer BENIN-IMMO,
une plateforme en ligne dédiée à l'immobilier au Bénin. Cependant, elle est développée
pour une seule agence et ne permet pas à d'autres structures de s'y inscrire et de publier
leurs propres annonces. Elle reste donc une solution fermée, sans vocation de
plateforme multi-agences.
 Ce que nous retenons de cette analyse, c'est que les solutions existantes
répondent soit à la visibilité, en permettant de publier des annonces, soit à la gestion
interne, mais très rarement aux deux à la fois. De plus, aucune d'entre elles ne propose
un parcours client complet, de la simple consultation d'un bien jusqu'au paiement de la
réservation, le tout depuis un seul et même outil adapté au contexte local.

C'est exactement ce vide que notre application ImmoGo cherche à combler.

III. Présentation du projet

ImmoGo est une application de gestion immobilière accessible depuis un
navigateur web et depuis un téléphone mobile. Elle a été conçue pour répondre aux
besoins de deux types d'utilisateurs principaux : les agences immobilières et les clients.

Du côté des agences, la plateforme leur offre un espace de gestion complet.

Chaque agence dispose d'un compte créé par l'équipe qui administre la plateforme,
avec un premier administrateur désigné dès le départ. Cet administrateur principal peut
ensuite ajouter d'autres membres pour l'aider dans la gestion du quotidien, tout en
gardant le contrôle sur les accès et les permissions. Il peut publier des biens avec
photos, descriptions, prix et localisation, et suivre en temps réel l'état de chaque bien
selon les actions des clients.

Du côté des clients, l'application adopte une approche ouverte : n'importe qui
peut parcourir les annonces sans avoir besoin de créer un compte. Ce n'est qu'au
moment de passer à l'action, c'est-à-dire réserver un bien, effectuer un paiement ou
mettre un bien en favoris, que le système invite l'utilisateur à se connecter ou à
s'inscrire. Cette approche permet de réduire les obstacles à l'entrée et d'attirer
davantage de visiteurs sur la plateforme.

La fonctionnalité de réservation est au cœur du projet. Lorsqu'un client souhaite

réserver un bien, il verse un acompte de 10 % du montant total. Il dispose ensuite d'un
délai de 15 jours pour régler le solde, soit directement depuis l'application, soit en se
rendant physiquement à l'agence. Pour les clients qui souhaitent payer en totalité dès le
départ, cette option est également disponible.

L'application mobile offre les mêmes fonctionnalités que la version web, dans
une interface adaptée aux smartphones. Elle permet aux clients de consulter les biens,
de faire des recherches par localisation, de réserver et de payer depuis leur téléphone,
où qu'ils se trouvent.
IV. Description du processus métier
Pour bien comprendre le fonctionnement d'ImmoGo dans la pratique, voici les
principaux processus qui structurent l'application.

Processus d'intégration d'une agence

Lorsqu'une agence souhaite rejoindre la plateforme, elle prend contact avec l'équipe
qui gère ImmoGo. Cette équipe crée le compte de l'agence et génère les identifiants du
premier administrateur, qui sont transmis à l'agence par les canaux convenus. Lors de
sa première connexion, cet administrateur peut configurer le profil de son agence,
télécharger son logo et commencer à publier des biens.

Processus de gestion des biens

Un administrateur d'agence peut ajouter un bien en renseignant ses informations : type

de bien, localisation précise, superficie, nombre de chambres, prix et photos. Une fois
publié, le bien devient visible par tous les visiteurs de la plateforme. Son statut évolue
automatiquement en fonction des actions des clients : disponible, réservé, loué ou
vendu.

Processus de réservation par un client

Un visiteur qui trouve un bien qui l'intéresse peut initier une réservation depuis la
version web ou depuis l'application mobile. Si ce n'est pas encore le cas, le système
l'invite à créer un compte. Une fois connecté, il procède au paiement de l'acompte de
10 %. L'agence est notifiée de la réservation et peut suivre son évolution depuis son
tableau de bord. Le client dispose d'un délai de 15 jous pour régler le solde restant. Si
ce délai est dépassé sans paiement, la réservation peut être annulée et le bien remis en
disponibilité.

Processus de paiement complet

Un client qui souhaite payer l'intégralité du montant sans passer par la réservation peut
le faire directement depuis la fiche du bien, que ce soit sur le web ou sur mobile. Le
paiement est traité en ligne, un reçu est généré et le statut du bien est automatiquement
mis à jour.

Processus de gestion des administrateurs d'agence

L'administrateur principal d'une agence peut créer des comptes pour d'autres membres
de son équipe, afin de les aider dans la gestion des biens et des réservations. Ces
administrateurs assistants ont des droits limités : ils peuvent consulter et gérer les
biens, mais ne peuvent ni créer ni supprimer d'autres comptes. Seul l'administrateur
principal a cette prérogative, et son propre compte ne peut pas être supprimé par un
autre membre.
 CHAPITRE 2 :
ANALYSE ET CONCEPTION DE
L'APPLICATION
I. Présentation du langage de modélisation UML
Le langage UML (Unified Modeling Language) est un standard utilisé en
ingénierie logicielle pour représenter graphiquement la conception et la structure d'un
système informatique. Il permet aux développeurs, aux analystes et aux chefs de projet
de mieux comprendre, concevoir et documenter les différents aspects d'un logiciel
avant même son développement.

Dans le cadre de ce projet, UML sera utilisé pour modéliser les fonctionnalités
du système de gestion immobilière en ligne. Il permettra de visualiser les processus
métier, d'identifier les interactions entre les différents acteurs (visiteurs, clients,
administrateurs d'agence, super administrateur) et de structurer l'architecture logicielle
de manière claire et cohérente.

La modélisation se fera suivant les trois axes à savoir :

 Modélisation fonctionnelle
 Modélisation dynamique
 Modélisation statique

II. Modélisation fonctionnelle

Dans cette section nous définirons les différents acteurs, les cas d'utilisation et
les scénarios qui décrivent comment notre système interagit avec ses utilisateurs et son
environnement. Cette modélisation nous permettra de clarifier les besoins fonctionnels
de notre solution et de définir les principales fonctionnalités qu'elle doit offrir.

2.1. Diagramme de contexte statique

Dans le cadre du développement d'une application de gestion immobilière, il est
essentiel de bien définir les interactions entre les différents acteurs et le système. Pour
cela, le diagramme de contexte statique permet d'avoir une vue d'ensemble du projet en
mettant en évidence les entités qui interagissent avec le système et la nature de ces
interactions.

Dans notre cas, le système de gestion immobilière interagit principalement avec

les visiteurs qui consultent les biens disponibles, les clients qui effectuent des
réservations et des paiements, les administrateurs d'agence qui gèrent les biens et les
réservations de leur agence, et le super administrateur qui supervise l'ensemble de la
plateforme en créant et gérant les comptes agences.

Ce diagramme constitue donc une première étape essentielle dans la

modélisation du projet. Il permet de clarifier les rôles de chaque acteur et de poser les
bases pour les futures représentations UML plus détaillées, telles que les diagrammes
de cas d'utilisation et les diagrammes de séquence.

Figure 1 : Diagramme de contexte statique

2.2. Diagramme de cas d'utilisations

2.2.1. Identification des acteurs et
cas d'utilisation
Un acteur est un utilisateur qui interagit avec un système. Il peut être une
personne, une organisation ou un système externe qui interagit avec le système. Dans
notre cas, nous retenons les acteurs suivants en nous basant sur la description du
processus métier :

Tableau 1 : Identification des acteurs et cas d'utilisation

Acteurs Cas d’utilisation

Consulter les biens disponibles
Visiteur
Rechercher un bien
Consulter le détail d'un bien
 S’inscrire
Se connecter
Réserver un bien (acompte 10%)
Payer la totalité
Payer le solde restant
Client
Gérer ses favoris
Consulter ses réservations
Gérer son profil
Consulter son historique
Se connecter
Publier un bien

Administrateur d'agence Modifier un bien

Supprimer un bien
Modifier le statut d'un bien
Consulter les réservations de l'agence
Gérer les administrateurs assistants (admin
principal)
Se connecter
Créer une agence
Créer une agence
Super Administrateur Modifier une agence
Supprimer une agence
Consulter les statistiques globales
 2.2.2. Diagramme des cas d'utilisation

Figure 2 : Diagramme de cas d'utilisation

2.2.3. Description textuelle des cas

d'utilisation
✓ Cas d'utilisation 1 : S'inscrire

Élément Description

Titre S'inscrire

Résumé Permet à un visiteur de créer un compte client sur la plateforme pour

Élément Description

accéder aux services de réservation et de paiement.

Acteurs Visiteur, Système

Le visiteur n'a pas encore de compte sur la plateforme. Il a accès à

Précondition
internet et à un navigateur web.

Tableau 2 : Scénario nominal

Visiteur Système
1. Accéder à la page et demander le
formulaire d'inscription
2. Envoyer le formulaire d'inscription
3. Renseigner les informations requises
(nom, prénom, email, téléphone, mot de
passe) et soumettre
4. Vérifier les informations saisies

5. Enregistrer le compte client

6. Connecter automatiquement le client

7. Afficher la page d'accueil avec

message de succès

Tableau 3 : Scénario alternatif

Visiteur Système
Au point 4 :
Si les champs sont mal remplis (email
incorrect, mot de passe trop court,
confirmation ne correspond pas)
A1. Afficher un message d'erreur
indiquant les champs à corriger
A2. Renvoyer le formulaire avec les
valeurs déjà saisies (sauf le mot de
passe)
 Au point 5 :
A3. Si l'email est déjà utilisé, afficher un
message précisant que l'adresse est déjà
associée à un compte

✓ Cas d'utilisation 2 : S'authentifier

Élément Description
Titre S'authentifier
L'utilisateur saisit ses identifiants pour accéder à son espace personnel
Résumé
(client, administrateur d'agence, super administrateur).
Acteurs Utilisateur (client, administrateur, super administrateur), Système
Précondition L'utilisateur doit être enregistré dans la base de données.

Tableau 4 : Scénario nominal

Utilisateur Système
1. Accéder à la page de connexion
correspondant à son rôle
2. Afficher le formulaire de connexion

3. Remplir et soumettre le formulaire

(email, mot de passe)

4. Vérifier les informations de connexion

5. Créer la session utilisateur

6. Rediriger vers le tableau de bord

correspondant au rôle

Tableau 5 : Scénario alternatif

Utilisateur Système
Au point 4 :
Si les informations sont invalides
 A1. Afficher un message d'erreur (email
ou mot de passe incorrect)
A2. Renvoyer le formulaire de connexion

✓ Cas d'utilisation 3 : Rechercher un bien

Élément Description
Titre Rechercher un bien
Le visiteur ou client utilise les filtres de recherche pour trouver un bien
Résumé
selon plusieurs critères.
Acteurs Visiteur, Client, Système
L'utilisateur a accès à la plateforme. Aucune connexion requise pour
Précondition
cette action.

Tableau 6 : Scénario nominal

Utilisateur Système
1. Accéder à la page de recherche ou à
l'accueil

2. Saisir les critères de recherche

(département, ville, quartier, type de
bien, prix maximum…) et soumettre 3. Filtrer les biens dans la base de
données selon les critères

4. Afficher la liste des biens

correspondant aux critères avec photos,
prix et localisation

Tableau 7 : Scénario alternatif

Utilisateur Système
Au point 3 :
Si aucun bien ne correspond aux critères

A1. Afficher un message indiquant

 qu'aucun bien n'a été trouvé

A2. Proposer de modifier les critères de

recherche

✓ Cas d'utilisation 4 : Réserver un bien ou paiement complet

Élément Description
Titre Réserver un bien ou paiement complet
Le client sélectionne un bien disponible et effectue la réservation de
Résumé
l'acompte de 10% ou le paiement complet via Kkiapay.
Acteurs Client, Système, API Kkiapay
Le client doit être connecté. Le bien sélectionné doit avoir le statut
Précondition
"disponible".

Tableau 8 : Scénario nominal

Client Système API FedaPay
1. Consulter le détail d'un
bien disponible

2. Cliquer sur "Réserver

(acompte 10%)" ou
"Paiement complet"
3. Afficher le formulaire

4. Calculer le montant de
l'acompte (10% du prix) si
c’est une réservation.

5. Créer une transaction

Kkiapay
6. Recevoir la demande de
transaction

7. Envoyer le lien de
paiement
8. Rediriger le client vers
la page de paiement
Kkiapay
 9. Effectuer le paiement
(Mobile Money, carte...)
10. Traiter le paiement

11. Confirmer la réussite

12. Créer le contrat et au système
enregistrer le paiement

13. Mettre à jour le statut

du bien

15. Rediriger le client vers

les biens.

Tableau 9 : Scénario alternatif

Client Système
Au point 11 : Si le paiement échoue ou
est annulé

A3. Afficher un message d'échec de

paiement

A4. Annuler la transaction et conserver

le statut du bien

III. Modélisation dynamique

Dans cette partie, nous allons nous intéresser à la représentation des interactions
entre les différents acteurs et le système à travers le temps. Cela inclura l'utilisation de
diagrammes de séquence et de diagrammes d'activité pour illustrer le flux des actions
et des événements qui se produisent lors de l'exécution des cas d'utilisation définis
précédemment.

Ces modèles dynamiques fourniront une visualisation claire et structurée des

processus impliqués dans le système de gestion immobilière, permettant ainsi une
meilleure compréhension de son fonctionnement et de sa logique de traitement.
 3.1. Diagrammes de séquence
Le diagramme de séquence est un outil fondamental du langage UML utilisé pour
modéliser les interactions entre les différents acteurs et le système à travers une
chronologie bien précise. Il permet de visualiser comment les objets communiquent
entre eux au fil du temps pour accomplir un cas d'utilisation donné.

Dans le cadre de notre projet de plateforme de gestion immobilière, le diagramme de

séquence joue un rôle crucial. Il nous aide à illustrer les échanges entre les visiteurs,
les clients, les administrateurs d'agence, le super administrateur, l'API de paiement
Kkiapay et le système lui-même.

Nous allons nous arrêter sur les diagrammes de séquence de quatre cas d'utilisation à
savoir :

 S'inscrire
 S'authentifier
 Rechercher un bien
 Réserver/Paiement total d’un bien

3.1.1. Cas d'utilisation : S'inscrire

Figure 3 : Diagramme de séquence S'inscrire

3.1.2. Cas d'utilisation : S'authentifier

Figure 4 : Diagramme de séquence S'authentifier

3.1.3. Cas d'utilisation : Rechercher un bien

Figure 5 : Diagramme de séquence Rechercher un bien

3.1.4. Cas d'utilisation : Réserver/Paiement total

Figure 6 : Diagramme de séquence Réserver ou paiement total d’un bien

3.2. Diagrammes d'activités

Le diagramme d'activités est un diagramme comportemental en UML qui décrit
les différentes étapes d'un processus métier ou d'un flux de travail dans un système. Il
est particulièrement utile pour représenter les enchaînements d'actions et les décisions
prises par les utilisateurs ou le système.
 Dans le cadre de notre projet de gestion immobilière , ce diagramme permet de
modéliser le parcours utilisateur ainsi que les interactions principales avec le système.
Cela inclut par exemple l'inscription d'un client, la recherche d'un bien, la réservation
avec paiement de l'acompte, ou encore la publication d'un bien par un administrateur
d'agence.

3.2.1. S'inscrire

Figure 7 : Diagramme d'activité S'inscrire

 3.2.2. S'authentifier

Figure 8 : Diagramme d'activité S'authentifier

3.2.3. Rechercher un bien

Figure 9 : Diagramme d'activité Rechercher un bien

3.2.4. Réserver un bien

Figure 10 : Diagramme d'activité Réserver un bien

IV. Modélisation statiques

La modélisation statique est une étape fondamentale dans la conception d'un
système d'information. Elle permet de représenter les structures permanentes du
système, c'est-à-dire tout ce qui concerne les entités (ou classes), leurs attributs, leurs
relations et leurs dépendances.
 Dans le cadre de notre projet de gestion immobilière en ligne, cette modélisation
statique nous permet de comprendre comment les différentes composantes du système
interagissent entre elles sur le plan structurel. Pour cela, nous allons utiliser deux outils
importants de modélisation statique à savoir :

 Le diagramme de classes UML, qui va formaliser toutes les entités du système

et leurs relations.
 Le diagramme d'objets, qui viendra compléter le diagramme de classes en
représentant une vue instantanée du système à un moment donné, avec des
objets concrets et des valeurs réelles.

4.1. Diagramme de classes

Dans cette section, le diagramme de classes nous permettra de modéliser les
entités principales du système à savoir : le super administrateur, les agences, les
administrateurs d'agence, les biens, les types de biens, les clients, les contrats, les
locations, les ventes, les paiements, les modes de paiement et les favoris, tout en
définissant les liens logiques qui les unissent.

4.1.1. Modélisation des entités et des

relations

Tableau 10 : Classes et attributs principaux

Classe Attributs principaux Méthodes principales

SuperAdmin id, whatsapp creerAdminAgence(),
creerAgence()
Agence id, nom_commercial, secteur, ville,
adresse_complete, email, telephone, logo, —
kkiapay_public_key, kkiapay_private_key,
kkiapay_secret, kkiapay_sandbox, statut
AdminAgence id, est_principal, whatsapp modifierMotDePasse(),
creerAdministrateur()
Bien id, titre, description, prix, superficie, localisation, publier(), modifierStatut(),
ville, chambres, salles_bain, transaction, statut
Client id, adresse, ville, avatar modifierProfil()
Contrat id, type_contrat, statut, date_limite calculerSolde()
Notification id, titre, message, lien, lu —
BienPhoto id, chemin, is_principale —
Paiement id, montant, date_paiement, type_paiement,
mode_paiement, reference, —
kkiapay_transaction_id, statut
users id, name, prenom, email, telephone, role, seConnecter(),
password seDeconnecter()
Favoris id ajouter(), supprimer()
 TypeBien id, libelle

Figure 11 : Diagramme de classes

 4.2. Diagramme d'objets
Dans le cadre de notre projet de gestion immobilière en ligne, le diagramme d'objets
nous permettra d'observer comment les entités modélisées interagissent concrètement dans un
scénario précis, ce qui facilite la compréhension des comportements et la validation du
modèle conceptuel.

À titre d'exemple, un client précis ayant effectué une réservation d'un bien immobilier
auprès d'une agence donnée, avec un paiement d'acompte validé via Kkiapay. Cela nous
aidera ainsi à mieux comprendre le comportement du système et à valider les relations entre
objets définies dans le diagramme de classes.

Figure 12 : Diagramme d'objets

[Insérer le diagramme ici]

CHAPITRE 3 :
DEVELOPPEMENT DE L’APPLICATION
I. Architecture logicielle et outils de
développement
1. Architecture logicielle

La phase de développement constitue l'étape charnière du projet, où les

concepts modélisés prennent forme dans une application fonctionnelle. Pour répondre
efficacement aux besoins identifiés et offrir une expérience utilisateur optimale, notre
application de gestion immobilière repose sur une architecture modulaire, évolutive et
sécurisée, bâtie selon les standards de développement modernes.

Notre projet est composé de deux parties complémentaires : une application

web développée avec Laravel et une application mobile développée avec Flutter. Ces
deux interfaces utilise la même API REST exposée par le backend Laravel,
garantissant ainsi une cohérence des données et une logique métier centralisée.

a) Architecture de l'application web MVC (Laravel)

L'application web adopte une architecture MVC (Modèle – Vue – Contrôleur)

grâce au framework Laravel 12, facilitant ainsi la séparation des responsabilités, la
maintenance du code et l'évolutivité du projet. Elle est organisée autour des couches
suivantes :

 Couche Présentation (Vue) : Développée en HTML, CSS avec Bootstrap 5 pour

la responsivité, et JavaScript, cette couche permet aux utilisateurs (visiteurs,
clients, administrateurs d'agence, super administrateur) d'interagir avec le
système à travers une interface claire, intuitive et responsive. Les vues sont
générées par le moteur de templates Blade de Laravel.
 Couche Métier (Contrôleur) : Elle centralise la logique applicative. Les
contrôleurs Laravel reçoivent les requêtes des utilisateurs, traitent les données
avec les services métier, puis renvoient la réponse adaptée via les vues Blade
ou sous forme de réponses JSON pour l'API.
 Couche Données (Modèle) : Composée des modèles Eloquent, cette couche
assure la persistance des données dans une base MySQL. Elle gère les relations
entre les objets métiers : super administrateurs, agences, administrateurs,
biens, types de biens, clients, contrats, locations, ventes, paiements, modes de
paiement et favoris.
Figure 13 : llustration de l’architecture MVC (Model View Controller)

b) Architecture de l'application mobile MVVM (Flutter)

L'application mobile adopte une architecture MVVM (Modèle – Vue –

VueModèle) grâce au framework Flutter, permettant une séparation claire entre
l'interface utilisateur et la logique métier. Elle est organisée autour des couches
suivantes :

 Couche Modèle (Model) : Cette couche représente les données de

l'application et les règles métier. Elle contient les classes de données (Bien,
Client, Contrat, Agence...) et les repositories qui communiquent avec l'API
REST Laravel pour récupérer ou envoyer des données.
 Couche Vue (View) : Développée en Dart avec les widgets Flutter, cette couche
constitue l'interface utilisateur de l'application mobile. Elle affiche les données
 fournies par le ViewModel et transmet les interactions de l'utilisateur (clics,
saisies) vers le ViewModel sans contenir de logique métier.
 Couche VueModèle (ViewModel) : Elle joue le rôle d'intermédiaire entre la
Vue et le Modèle. Elle récupère les données depuis les repositories, les
transforme pour l'affichage, et notifie la Vue des changements d'état grâce au
système de gestion d'état (Provider ou Riverpod).

2. Outils et Techniques de Développement

2.1. Langages de développement utilisés

Pour le développement de notre application, plusieurs langages ont été

utilisés, chacun répondant à un besoin spécifique :

Côté Backend (Application web Laravel) :

 PHP (version 8.2) : langage principal côté serveur, utilisé pour implémenter la
logique métier de l'application web et exposer l'API REST consommée par
l'application mobile.
 Blade : moteur de templates intégré à Laravel, utilisé pour la génération des
pages HTML de l'interface web.
 HTML5 : structuration des pages web de l'interface d'administration et de la
plateforme client.
 CSS3 : mise en forme et personnalisation des interfaces utilisateur.
 Bootstrap 5 : framework CSS pour un design responsive et moderne,
permettant une utilisation confortable aussi bien sur ordinateur que sur
tablette.
 JavaScript : pour les interactions côté client.
 SQL (avec Eloquent ORM) : pour la gestion des requêtes vers la base de
données relationnelle MySQL, via l'ORM Eloquent intégré à Laravel.

Côté Frontend mobile (Application mobile Flutter) :

  Dart : langage principal utilisé pour le développement de l'application mobile
avec Flutter. Il permet de créer des interfaces fluides et performantes pour
Android et iOS à partir d'un seul code source.
 Flutter : framework de développement mobile multiplateforme de Google,
utilisé pour concevoir l'interface utilisateur de l'application mobile ImmoGo.

2.2. Techniques de développement adoptées

Pour garantir la qualité, la maintenabilité et l'évolutivité de l'application,

les techniques suivantes ont été mises en œuvre :

✓ Approche MVC (Modèle-Vue-Contrôleur) côté web : séparation claire entre la

logique métier, l'interface utilisateur et la gestion des données dans l'application web
Laravel.

✓ Approche MVVM (Modèle-Vue-VueModèle) côté mobile : architecture adoptée

dans l'application Flutter pour séparer la logique de présentation de la logique métier,
facilitant la testabilité et la maintenance du code mobile.

✓ POO (Programmation Orientée Objet) : structuration du code en objets

réutilisables et faciles à maintenir, aussi bien côté Laravel que côté Flutter/Dart.

✓ API REST (Laravel Sanctum) : conception d'une API REST sécurisée exposée
par le backend Laravel, consommée par l'application mobile Flutter. L'authentification
est gérée via des tokens Bearer générés par Laravel Sanctum.

✓ Utilisation du Framework Laravel 12 : pour structurer l'application web, gérer les

routes, la sécurité, les migrations de base de données, les modèles Eloquent et les
contrôleurs.

✓ Utilisation du Framework Flutter : pour développer l'application mobile

multiplateforme (Android et iOS) à partir d'un seul code source, offrant une expérience
native sur les deux plateformes.
✓ Système d'authentification et de gestion des rôles : pour distinguer les accès entre
visiteurs, clients, administrateurs d'agence (principal et assistant) et super
administrateur, aussi bien sur l'interface web que mobile.

✓ Intégration de Kkiapay : pour la gestion des paiements en ligne (acompte de 10%,

paiement total, solde restant) via Mobile Money (MTN, Moov) et autres moyens de
paiement électronique disponibles au Bénin.

✓ Gestion des fichiers et médias : utilisation du système Laravel Storage pour le

stockage et la gestion des photos des biens immobiliers (10 photos maximum par bien)
et des logos des agences.

✓ Utilisation de GIT : pour la gestion du code source, le versioning et le travail

collaboratif entre les deux membres de l'équipe de développement.

✓ Test fonctionnel : vérification du bon fonctionnement des fonctionnalités critiques

telles que l'authentification, la réservation, le paiement et la gestion des biens.

✓ Méthodologie Agile (itérative) : construction progressive de l'application avec des

phases de développement, de test et de retour d'expérience, permettant d'ajuster les
fonctionnalités au fur et à mesure de l'avancement du projet.

II. Implémentation de la base de données

1.1. Schéma logique relationnel
 users (id, name, prenom, email, telephone, role, password, created_at). Table
centrale contenant tous les utilisateurs (super_admin, admin_agence, client)
 super_admins (id, #user_id, whatsapp, created_at)
 agences (id, nom_commercial, secteur, ville, adresse_complete, email, telephone,
logo, kkiapay_public_key, kkiapay_private_key, kkiapay_secret, kkiapay_sandbox,
statut, created_at)
 admin_agences (id, #user_id, #agence_id, est_principal, whatsapp, created_at)
 type_biens (id, libelle, created_at)
 biens (id, #agence_id, #type_bien_id, titre, description, prix, superficie,
localisation, ville, chambres, salles_bain, transaction, statut, is_premium,
is_published, created_at)
 bien_photos (id, #bien_id, chemin, is_principale, created_at)
 contrats (id, #bien_id, #client_id, type_contrat, statut, date_limite, created_at)
 paiements (id, #contrat_id, #client_id, montant, date_paiement, type_paiement,
mode_paiement, reference, kkiapay_transaction_id, statut, created_at)
 favoris (id, #user_id, #bien_id, created_at)
 notifications_immogo (id, #user_id, titre, message, lien, lu, created_at)

1.2. Scripts SQL d'implémentation de la base de données

➢ Création de la table users

CREATE TABLE users (

id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
name VARCHAR(191) NOT NULL,
prenom VARCHAR(191) DEFAULT NULL,
email VARCHAR(191) NOT NULL UNIQUE,
telephone VARCHAR(191) DEFAULT NULL,
role ENUM('super_admin','admin_agence','client')
NOT NULL DEFAULT 'client',
email_verified_at TIMESTAMP NULL DEFAULT NULL,
password VARCHAR(191) NOT NULL,
remember_token VARCHAR(100) DEFAULT NULL,
created_at TIMESTAMP NULL DEFAULT NULL,
updated_at TIMESTAMP NULL DEFAULT NULL,
PRIMARY KEY (id)
);

➢ Création de la table super_admins

CREATE TABLE super_admins (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
user_id BIGINT UNSIGNED NOT NULL UNIQUE,
whatsapp VARCHAR(191) DEFAULT NULL,
created_at TIMESTAMP NULL DEFAULT NULL,
updated_at TIMESTAMP NULL DEFAULT NULL,
PRIMARY KEY (id),
FOREIGN KEY (user_id)
REFERENCES users(id)
ON DELETE CASCADE
);

➢ Création de la table agences

CREATE TABLE agences (

id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
nom_commercial VARCHAR(191) NOT NULL,
secteur ENUM('Résidentiel','Commercial','Industriel','Mixte')
NOT NULL DEFAULT 'Résidentiel',
ville VARCHAR(191) NOT NULL,
adresse_complete VARCHAR(191) NOT NULL,
email VARCHAR(191) NOT NULL UNIQUE,
telephone VARCHAR(191) DEFAULT NULL,
logo VARCHAR(191) DEFAULT NULL,
kkiapay_public_key VARCHAR(191) DEFAULT NULL,
kkiapay_private_key VARCHAR(191) DEFAULT NULL,
kkiapay_secret VARCHAR(191) DEFAULT NULL,
kkiapay_sandbox TINYINT(1) NOT NULL DEFAULT 1,
statut ENUM('actif','en_attente','suspendu')
NOT NULL DEFAULT 'en_attente',
created_at TIMESTAMP NULL DEFAULT NULL,
updated_at TIMESTAMP NULL DEFAULT NULL,
 PRIMARY KEY (id)
);

➢ Création de la table admin_agences

CREATE TABLE admin_agences (

id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
user_id BIGINT UNSIGNED NOT NULL UNIQUE,
agence_id BIGINT UNSIGNED NOT NULL,
est_principal TINYINT(1) NOT NULL DEFAULT 0,
whatsapp VARCHAR(191) DEFAULT NULL,
created_at TIMESTAMP NULL DEFAULT NULL,
updated_at TIMESTAMP NULL DEFAULT NULL,
PRIMARY KEY (id),
FOREIGN KEY (user_id)
REFERENCES users(id)
ON DELETE CASCADE,
FOREIGN KEY (agence_id)
REFERENCES agences(id)
ON DELETE CASCADE
);

➢ Création de la table type_biens

CREATE TABLE type_biens (

id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
libelle VARCHAR(191) NOT NULL,
created_at TIMESTAMP NULL DEFAULT NULL,
updated_at TIMESTAMP NULL DEFAULT NULL,
PRIMARY KEY (id)
);

➢ Création de la table biens

CREATE TABLE biens (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
agence_id BIGINT UNSIGNED NOT NULL,
type_bien_id BIGINT UNSIGNED NOT NULL,
titre VARCHAR(191) NOT NULL,
description TEXT DEFAULT NULL,
prix DECIMAL(15,2) NOT NULL,
superficie DOUBLE DEFAULT NULL,
localisation VARCHAR(191) NOT NULL,
ville VARCHAR(191) NOT NULL,
chambres INT DEFAULT NULL,
salles_bain INT DEFAULT NULL,
transaction ENUM('location','vente')
NOT NULL DEFAULT 'location',
statut ENUM('disponible','reserve','vendu',
'loue','indisponible')
NOT NULL DEFAULT 'disponible',
is_premium TINYINT(1) NOT NULL DEFAULT 0,
is_published TINYINT(1) NOT NULL DEFAULT 0,
created_at TIMESTAMP NULL DEFAULT NULL,
updated_at TIMESTAMP NULL DEFAULT NULL,
PRIMARY KEY (id),
FOREIGN KEY (agence_id)
REFERENCES agences(id)
ON DELETE CASCADE,
FOREIGN KEY (type_bien_id)
REFERENCES type_biens(id)
);

➢ Création de la table bien_photos

CREATE TABLE bien_photos (

 id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
bien_id BIGINT UNSIGNED NOT NULL,
chemin VARCHAR(191) NOT NULL,
is_principale TINYINT(1) NOT NULL DEFAULT 0,
created_at TIMESTAMP NULL DEFAULT NULL,
updated_at TIMESTAMP NULL DEFAULT NULL,
PRIMARY KEY (id),
FOREIGN KEY (bien_id) REFERENCES biens(id) ON DELETE CASCADE
);

➢ Création de la table contrats

CREATE TABLE contrats (

id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
bien_id BIGINT UNSIGNED NOT NULL,
client_id BIGINT UNSIGNED NOT NULL,
type_contrat ENUM('location','vente') NOT NULL,
statut ENUM('en_attente','confirme', 'annule')
NOT NULL DEFAULT 'en_attente',
date_limite DATE DEFAULT NULL,
created_at TIMESTAMP NULL DEFAULT NULL,
updated_at TIMESTAMP NULL DEFAULT NULL,
PRIMARY KEY (id),
FOREIGN KEY (bien_id) REFERENCES biens(id) ON DELETE CASCADE,
FOREIGN KEY (client_id) REFERENCES users(id) ON DELETE CASCADE
);

➢ Création de la table paiements

CREATE TABLE paiements (

id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
contrat_id BIGINT UNSIGNED NOT NULL,
client_id BIGINT UNSIGNED NOT NULL,
 montant DECIMAL(15,2) NOT NULL,
date_paiement DATETIME NOT NULL,
type_paiement ENUM('acompte','solde','complet') NOT NULL,
mode_paiement ENUM('mobile_money','virement','especes','carte') NOT NULL
DEFAULT 'mobile_money',
reference VARCHAR(191) NOT NULL UNIQUE,
kkiapay_transaction_id VARCHAR(191) DEFAULT NULL,
statut ENUM('en_attente','confirme','echoue') NOT NULL DEFAULT 'en_attente',
created_at TIMESTAMP NULL DEFAULT NULL,
updated_at TIMESTAMP NULL DEFAULT NULL,
PRIMARY KEY (id),
FOREIGN KEY (contrat_id) REFERENCES contrats(id) ON DELETE
CASCADE,
FOREIGN KEY (client_id) REFERENCES users(id) ON DELETE CASCADE);

➢ Création de la table favoris

CREATE TABLE favoris (

id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
user_id BIGINT UNSIGNED NOT NULL,
bien_id BIGINT UNSIGNED NOT NULL,
created_at TIMESTAMP NULL DEFAULT NULL,
updated_at TIMESTAMP NULL DEFAULT NULL,
PRIMARY KEY (id),
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE,
FOREIGN KEY (bien_id) REFERENCES biens(id) ON DELETE CASCADE
);

➢ Création de la table notifications_immogo

CREATE TABLE notifications_immogo (

id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
user_id BIGINT UNSIGNED NOT NULL,
 titre VARCHAR(191) NOT NULL,
message TEXT NOT NULL,
lien VARCHAR(191) DEFAULT NULL,
lu TINYINT(1) NOT NULL DEFAULT 0,
created_at TIMESTAMP NULL DEFAULT NULL,
updated_at TIMESTAMP NULL DEFAULT NULL,
PRIMARY KEY (id),
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
);

III. Développement des interfaces homme-

machine

Dans notre projet ImmoGo, le développement des interfaces Homme-Machine

occupe une place centrale. C'est en effet à travers ces interfaces que les utilisateurs
vont interagir au quotidien avec le système, que ce soit pour consulter un bien
immobilier, effectuer une réservation ou gérer les annonces d'une agence. Une
interface mal conçue peut décourager l'utilisateur, même si les fonctionnalités derrière
sont excellentes. C'est pourquoi nous avons accordé une attention particulière à la
simplicité, à la lisibilité et à la fluidité de navigation.

Notre application se décline sur deux supports complémentaires : une

application web accessible depuis un navigateur, et une application mobile
développée avec Flutter pour Android et iOS. Les deux interfaces partagent la même
logique de navigation et la même charte graphique, avec la couleur principale
turquoise qui donne à ImmoGo son identité visuelle reconnaissable.

Dans ce projet, nous nous sommes concentrés sur trois axes principaux :

 Le design de l'interface : choix des couleurs, disposition des éléments, lisibilité

des informations et cohérence visuelle entre les pages.
 Le parcours utilisateur : l'objectif est qu'un visiteur puisse trouver un bien, le
réserver et effectuer son paiement en un minimum d'étapes.
 L'accessibilité multiplateforme : les interfaces web s'adaptent à toutes les
tailles d'écran grâce à Bootstrap 5, tandis que l'application mobile offre une
expérience native sur Android et iOS.
Interfaces de l'application web
3.1. Interface d'accueil

Figure 14 : Interface d'accueil

3.2. Interface d'inscription

Figure 15 : Interface d'inscription

3.3. Interface de connexion

Figure 16 : Interface de connexion

3.4. Interface de liste et recherche des biens

Figure 17 : Interface de liste et recherche des biens

3.5. Interface de détail d'un bien

Figure 18 : Interface de détail d'un bien

3.6. Interface de réservation d'un bien

Figure 19 : Interface de réservation d'un bien

3.7. Interface de paiement via Kkiapay

Figure 20 : Interface de paiement via Kkiapay

3.8. Interface de l'historique des réservations du
client

Figure 21 : Interface de l'historique des réservations

3.9. Interface des favoris du client

Figure 22 : Interface des favoris du client

3.10. Interface du tableau de bord de
l'administrateur d'agence

Figure 23 : Interface du tableau de bord administrateur d'agence

3.11. Interface de gestion des biens

Figure 24 : Interface de gestion des biens

3.12. Interface d'ajout d'un bien

Figure 25 : Interface d'ajout d'un bien

3.13. Interface des notifications d’un client

Figure 26 : Interface des notifications d’un client

3.14. Interface de gestion des agences

Figure 27 : Interface de gestion des administrateurs

3.15. Interface du tableau de bord du super
administrateur

Figure 28 : Interface du tableau de bord super administrateur

3.16. Interface de création d'une agence avec son
administrateur principal

Figure 29 : Interface de création d'une agence

Interfaces de l'application mobile

L'application mobile ImmoGo a été développée avec Flutter, ce qui permet de

proposer une seule application fonctionnant aussi bien sur Android que sur iOS. Elle
consomme l'API REST exposée par le backend Laravel, offrant ainsi aux utilisateurs
mobiles les mêmes fonctionnalités que la version web, dans une expérience adaptée
aux petits écrans et aux usages nomades.
3.17. Interface d'accueil mobile

Figure 30 : Interface d'accueil de l'application mobile

3.18. Interface d'inscription et de connexion
mobile
Figure 31 : Interface d'inscription et de connexion mobile
3.19. Interface de détail d'un bien et de
réservation mobile
Figure 32 : Interface de détail d'un bien et de réservation mobile
3.20. Interface de paiement mobile via Kkiapay

Figure 33 : Interface de paiement mobile via Kkiapay

3.21. Interface des historiques du client mobile

Figure 34 : Interface des historiques du client mobile

3.22. Interface des favoris mobile

Figure 35 : Interface des favoris mobile

IV. Mesures de sécurité

La sécurité est un aspect que nous n'avons pas pris à la légère dans le développement
d'ImmoGo. Notre application manipule des données sensibles : informations
personnelles des clients, transactions financières, identifiants de connexion des
administrateurs d'agence et du super administrateur. Il était donc indispensable de
mettre en place des mécanismes solides pour protéger ces données et garantir la
fiabilité du système, aussi bien sur la version web que sur l'application mobile.

1. Authentification sécurisée
Tous les mots de passe sont chiffrés avec l'algorithme bcrypt avant d'être enregistrés
en base de données. Il est donc impossible, même pour un administrateur système, de
lire un mot de passe en clair. Pour l'application mobile, l'authentification repose sur
des tokens Bearer générés par Laravel Sanctum, transmis de manière sécurisée à
chaque requête API.

2. Gestion des rôles et des accès

Chaque utilisateur n'a accès qu'aux fonctionnalités qui correspondent à son profil. Le
visiteur peut parcourir les annonces sans créer de compte. Le client peut réserver,
payer et gérer ses favoris. L'administrateur assistant peut consulter les biens et
réservations de son agence sans pouvoir gérer les autres membres. L'administrateur
principal dispose en plus de la capacité de créer, de supprimer des comptes assistants
et de gérer l’agence. Enfin, le super administrateur gère exclusivement les agences et
leurs administrateurs principaux, sans accès aux données opérationnelles des agences.
Ces restrictions sont appliquées à la fois dans les vues et dans les contrôleurs, pour
éviter tout contournement.

3. Protection contre les attaques web courantes

Chaque formulaire de l'application web intègre un token CSRF généré

automatiquement par Laravel, ce qui empêche les attaques par falsification de
requêtes. Toutes les données saisies par les utilisateurs sont validées côté serveur avant
d'être traitées ou enregistrées, protégeant ainsi le système contre les injections SQL et
les attaques de type XSS. L'ORM Eloquent de Laravel prépare automatiquement les
requêtes SQL, éliminant le risque d'injection directe dans la base de données.

4. Protection des fichiers et médias

Les photos des biens immobiliers et les logos des agences sont stockés dans un espace
sécurisé via Laravel Storage, inaccessible directement sans passer par les routes
définies de l'application. Chaque agence configure ses propres clés API Kkiapay
(publique, privée, secret) qui sont stockées de manière chiffrée en base de données et
ne sont jamais exposées côté client.

5. Chiffrement des communications

L'application est conçue pour fonctionner exclusivement en HTTPS, garantissant que

toutes les données échangées entre l'utilisateur (web ou mobile) et le serveur sont
chiffrées. Cela protège notamment les tokens d'authentification et les informations de
paiement contre toute interception.

6. Traçabilité des actions

Un système de journalisation des activités a été intégré via la table

activity_logs. Chaque action importante est enregistrée : connexion d'un
utilisateur, création ou modification d'un bien, changement de statut, création d'une
agence. En cas d'incident ou d'action suspecte, il est possible de retrouver précisément
qui a fait quoi et à quel moment.

7. Sécurité des paiements

Toutes les transactions financières passent par Kkiapay, un prestataire de paiement en

ligne spécialisé dans les paiements mobiles en Afrique de l'Ouest. L'application ne
stocke jamais les données bancaires des utilisateurs. Seule la référence de la
transaction et son statut sont conservés localement. En mode sandbox lors des tests, les
transactions ne sont pas réelles, permettant de valider le bon fonctionnement du
système sans risque financier.

Conclusion

Le développement d'ImmoGo nous a permis de concrétiser une idée en une application

fonctionnelle, répondant à un besoin réel dans le secteur immobilier béninois. Depuis
l'analyse du problème jusqu'à la réalisation des interfaces, en passant par la conception
de la base de données et l'implémentation des fonctionnalités, chaque étape a été
menée avec le souci de produire une solution robuste, utilisable et sécurisée.
Le fait de travailler sur deux supports simultanément, une application web et une
application mobile, nous a confrontés à des défis techniques intéressants, notamment
la mise en place d'une API REST partagée, la gestion des sessions et des tokens selon
le contexte, et l'adaptation des interfaces à des tailles d'écran différentes. Ces défis
nous ont permis d'approfondir nos compétences en développement full-stack avec
Laravel, ainsi qu'en développement mobile avec Flutter.

Au-delà de l'aspect technique, ce projet nous a également appris à travailler de manière

organisée et méthodique, en suivant une démarche de conception rigoureuse basée sur
UML, avant de passer à l'implémentation. Les diagrammes de cas d'utilisation, de
séquence, d'activité et de classes ont constitué un guide précieux tout au long du
développement.

ImmoGo est aujourd'hui une plateforme capable de relier agences immobilières et

clients de manière simple et efficace, contribuant ainsi à la modernisation d'un secteur
qui en a besoin. Elle est prête à être déployée en production et pourra évoluer selon les
besoins futurs, grâce à son architecture modulaire et extensible.