INSTITUT UNIVERSITAIRE DU GOLFE DE

GUINEE

INSTITUT SUPERIEUR DES TECHNOLOGIES AVANCEES

SESSION : JUIN 2020

RAPPORT DE STAGE

THEME : CONCEPTION ET REALISATION

D’UNE APPLICATION DE GESTION DES
LOGEMENTS

Stage effectué du 17 Juin au 20 Août 2019 en vue de l’obtention du Brevet de Technicien

Supérieur

OPTION : INFORMATIQUE GENIE LOGICIEL

Rédigé Et Soutenu par :

KABIWA JEAN DE DIEU

Sous l’encadrement professionnel de : Sous la supervision académique de :

M. MOMO Ludovic M.GUIKO TEMGOUA Arsène

Année académique 2020 - 2021

P a g e 1 | 47
A MA FAMILLE

P a g e 2 | 47
 REMERCIEMENTS

Ce rapport est l’aboutissement d’un travail qui nous permet de pouvoir exprimer toute
notre gratitude à tous ceux ayant soutenu et participé de près mais aussi de loin à
l’élaboration de ce rapport à travers leurs conseils que leur sollicitude. Nous pensons
particulièrement à :

 M. MOMO Ludovic, notre encadreur professionnel pour sa disponibilité en tout

temps et tout lieu, son aide, ses conseils, ses apports et son soutien inconditionnel.
 M. GUIKO TEMGOUA Arsène Peggy, notre encadreur académique pour sa
disponibilité, son soutien et ses conseils.
 Ma famille plus précisément à ma mère Mme. TCHEUNKAM Marie et mon grand
frère MARCEL FEUKWA pour tous les sacrifices faits pour que nous puissions
continuer nos études.
 Tout le personnel enseignant de l’Institut Universitaire du Golfe de Guinée
 M. ONDAPHE Arthur pour l’aide dans l’apprentissage de nouvelles technologies
qu’il nous a apporté.
 Nous ne saurions ne pas faire mention de nos frères et sœurs, notre famille, nos
amis et camarades de classe, nos connaissances qui nous ont tous apporté leur
appui notamment sur le plan intellectuel, moral, financier et affectif.

P a g e 3 | 47
 AVANT - PROPOS

Créé par l’arrêté ministériel N°90/E50 MINEDUC/DET du 14 Décembre 1994 et porté

au MINESUP par la réforme universitaire du 19 Janvier 1993, vu l’arrêté
N°0007/MINESUP/DDES/CJ du 28 Février 2000 portant création de la commission
nationale d’organisation de l’examen du Brevet des Techniciens Supérieurs (BTS).

L’Examen national de Brevet des Techniciens Supérieurs (BTS) se déroule au

Cameroun depuis des années sous la supervision du Ministère de l’Enseignement
Supérieur. Le complexe universitaire ESG-ISTA-ISA aujourd’hui IUG (Institut
Universitaire du Golfe de Guinée) a acquis son existence légale graduellement par les
arrêtés ministériels N°02/0062/MINESUP/DDES du 10 Juin 1993,
N°0/0090/MINESUP/DDES du 13 Septembre 2002 et en 2009 sous l’initiative de son
président fondateur Louis-Marie DJAMBOU. Ce complexe est un institut privé agréée
par le ministère de l’enseignement supérieur, qui a pour objectif premier la formation
des jeunes nationaux et étrangers compétents et responsables, qu’il met au service de
l’entreprise selon leurs besoins et qualifications. Le BTS et DSEP s’obtient dans ce
complexe après deux années de formation.

Dans le souci de proposer ainsi une solution, en termes d’urgence mais aussi de
nécessité, au problème se posant d’une formation pratique et dynamique pour un
entreprenariat de pointe dans un contexte économique caractérisé par les nouvelles
exigences du marché du travail toujours ouvert et en constante modernisation et
évolution, il était en fait devenu impérieux de prendre en compte le secteur privé alors
en plein essor. Il fallait donc à ce problème et ces nouvelles exigences, une réponse
palliative et se voulant graduelle et pour cela le gouvernement camerounais par
l’intermédiaire du ministère de l’enseignement supérieur a permis l’ouverture de

P a g e 4 | 47
plusieurs institutions privées offrant des enseignements de niveau supérieur, leur
permettant ainsi de contribuer en adéquation avec le monde professionnel, une
formation académique et professionnelle de qualité.

C’est à travers ce processus que fut fondée en 1993, l’Institut Universitaire du Golfe de
Guinée située dans la région du Littoral, département du Wouri, arrondissement de
Douala 4ème, au quartier PK8. A ce jour, l’Institut Universitaire du Golfe de Guinée
(IUG) compte actuellement trois établissements d’enseignement supérieur basé dans le
même campus à Douala – Bassa. Ces trois grands établissements sont :

1. L’Ecole Supérieure de Gestion (ESG)qui forme ses étudiants dans les filières
de gestion et de communication qui sont :
 Action Commerciale (AC)
 Banque (BQ)
 Comptabilité et Gestion des Entreprises (EG)
 Commerce International (CI)
 Gestion des Systèmes d’Information (GSI)
 Secrétariat de Direction et Bureautiques Bilingues (SD et SBB)
 Logistique et Transport (LT)
 Communication d’Entreprise (CE)
 Journalisme (JO)
 Droit des Affaires (DA)
 Marketing Commerce Vente (MC)
 Comptabilité et Finance (CF)

2. L’Institut Supérieur des Sciences Appliquées (ISA) qui forme ses étudiants
dans les domaines des sciences paramédicales qui sont :
 Sage-Femme (SF)
 Sciences Infirmières (SI)
 Kinésithérapie (KT)
 Technologies de Laboratoire et d’Analyse Numérique (TL)
 Radiologie et Imagerie (RI)
P a g e 5 | 47
3. L’Institut Supérieur des Technologies Avancées, ISTA qui forme ses
étudiants dans les domaines informatiques mais aussi ceux industriels. Ce
sont :
 Electrotechnique (ET)
 Maintenance des Equipements Industriels (MEI)
 Maintenance des Systèmes Electrotechniques (MSE)
 Bâtiment (BAT)
 Travaux Publics (TP)
 Maintenance Après-Vente Automobile (MAVA)
 Mécatronique (MK)
 Maintenance Industrielle et Productique (MIP)
 Froid et Climatisation (FC)
 Génie Logiciel (GL)
 Maintenance des Systèmes Informatiques (MSI)
 Informatique Industrielle et Automatisme (II)
 Télécommunications (TEL)
 Réseaux et Sécurité (RES)

P a g e 6 | 47
 INTRODUCTION GENERALE

Depuis plusieurs années, on observe un grand flux migratoire des populations vers
les zones urbaines pour diverse raisons. Ce déplacement massif de la population entraine
une pénurie en logement dans nos villes. C’est dans l’optique de palier à ce problème
que l’Etat, les hommes d’affaires, les entrepreneurs et certains particuliers ont décidé de
lancer une vaste campagne de construction des logements sociaux pour abriter ce surplus
de population. Mais face au nombre sans cesse croissant de logement, un autre problème
est né celui de la gestion de ces logements puisque celle-ci est un travail exclusivement
réservé aux professionnels et solliciter leur assistance n’est pas toujours une mince
affaire.

Dès lors on se demande donc comment sont gérés ces logements au quotidien sans
assistance des cabinets de gestion locative ? plusieurs informaticiens ont développé des
applications de gestion locative pour venir en aide aux propriétaires des logements, et
certains entrepreneurs ce qui facilite correctement le travail. Mais ces applications
posent plusieurs problèmes tout aussi grave : la plupart de ces applications ne sont ni
gratuit, ni open source se sont les applications propriétaires taillées sur mesure et
payante. Dès lors on peut donc se demander si la situation des propriétaires de logements
a réellement changé dans la mesure où ses applications de gestion locative ne sont plus
à la portée de tout le monde ? Quelle solution nous proposons pour la résolution de ce
problème ? Quels sont les moyens, méthodes et techniques que nous allons utiliser pour
cette résolution ?

Nous répondrons à ces interrogations progressivement tout au long de notre rapport

tout en vous présentant en première partie le cadre dans lequel on a effectué notre stage
et en deuxième partie nous présenterons la mise en œuvre de notre travail c’est-à-dire le
dossier de conception et la réalisation de notre application.

P a g e 7 | 47
 PREMIERE PARTIE : CADRE DU
STAGE

Dans cette partie nous présenterons dans le chapitre I l’ensemble de

structure de l’entreprise Briok son historique et au chapitre II nous
présenterons notre critique face au système existant et proposerons
quelques pistes de solutions.

P a g e 8 | 47
 CHAPITRE I : PRESENTATION GENERALE DE
L’ENTREPRISE ET DEROULEMENT DU STAGE

SECTION I : PRESENTATION DE L’ENTREPRISE

I- HISTORIQUE
L’idée de la création de l’entreprise BRIOK est née en 2014 par un groupe de jeunes
informaticiens camerounais convaincus après leur formation que se lancer dans
l’entreprenariat était non seulement un moyen pour eux de s’auto-employer mais aussi
d’employer d’autres jeunes. Au départ, il s’agissait juste d’une petite START-UP où
trois personnes travaillaient (les trois fondateurs) mais en 2016 il décide de quitter du
statut de start-up à entreprise. Au départ la start-up ne faisait que du développement
web, mais avec la demande qui devenait de plus en plus forte sur le marché du logiciel
et application l’entreprise a compris qu’il fallait vite se réajuster. Aujourd’hui BRIOK
est une SSII (Société de Service et d’Ingénierie Informatique) qui fait en plus du
développement web, le développement des logiciels, progiciels, les feuilles de style
personnalisées Microsoft Excel, MS office, la présentation Microsoft PowerPoint, la

P a g e 9 | 47
maintenance et offre les formations dans le domaine du développement de logiciels, site
web. Elle a déjà à ce jour crée plus de 50 sites web, plus de 40 applications, 10 logiciels,
plus de 100 personnes déjà formées, plus 500 clients satisfaits. Aujourd’hui, BRIOK
compte en son sein plus de 10 experts. Site officiel de BRIOK www.briok.fr .

Figure 1 : plan de localisation

II- ORGANIGRAMME ET FONCTIONNEMENT DE

L’ENTREPRISE BRIOK

P a g e 10 | 47
 1- Organigramme

DIRECTEUR GENERAL

DIRECTEUR DIRECTEUR
COMMERCIAL TECHNIQUE

SERVICE SERVICE SERVICE SERVICE SERVICE

COMMERCIAL MARKETING DEVELOPPE FORMATION MAINTENANC
MENT E
Figure 2 : organisation de BRIOK

2- Fonctionnement
BRIOK a en son sein un ensemble de directions et de services aujourd’hui qui lui
permettent de fonctionner de manière optimale.

 Directeur General

Le Directeur général est en charge de l’implémentation générale de la stratégie et de la

politique l’entreprise. Il fixe les objectifs et donne les orientations pour les atteindre.

 Directeur Commercial

Le directeur commercial définit, anime et supervise les stratégies commerciales en vue

d'accroître les ventes de l'entreprise et d'augmenter le chiffre d'affaires.

P a g e 11 | 47
  Directeur Technique

Le directeur technique gère l'ensemble des activités et des ressources techniques de

l’entreprise. Il accompagne les projets de production et participe également à la
conception de nouveaux produits et procédés, en étudiant leur faisabilité technique.

 Service Commercial

Le service commercial permet de mieux vendre les produits de l’entreprise et permet

aussi d’acheter le matériel de production. C’est dans ce service que l’entreprise exerce
sa politique de vente et d’achat des produits.

 Service Marketing

Le rôle du service marketing est avant tout de tisser un lien entre l’entreprise et les clients
ou prospects. Il propose aux clients ou prospects l’ensemble des produits et services
dont dispose l’entreprise. Son rôle principal est la recherche des futurs clients pour
l’entreprise.

 Service Développement

Le service développement a pour rôle la réalisation des interfaces ou la maintenance des

applications ayant un dossier de conception déjà complet. Ce service est directement
rattaché au service technique.

 Service Formation

Le service de formation est un service qui consiste à former les apprenants sur les outils
de bureau tel que MS Word, Excel, power point. A créer les feuilles de styles
personnalisées. Sur les langages de développement, Framework comme par exemple
JAVA, PHP, JQUERY, BOOTSTRAP.

 Service Maintenance

P a g e 12 | 47
Ce service est en charge de la maintenance des équipements et des outils dans
l’entreprise. Ce service stocke également les pièces de rechange.

SECTION II : DEROULEMENT DU STAGE

I- ACCUEIL AU SEIN DE L’ENTREPRISE BRIOK

Nous avons commencé le stage le lundi 17 juin 2019. A notre arrivé, la secrétaire nous
a fait visiter les différents services de l’entreprise et à la fin de la visite elle nous a envoyé
au service informatique et nous avons rencontré le chef de service qui nous a souhaité
la bienvenue. Après une semaine dans ce service nous avons eu nos encadreurs
professionnels.

II- CHRONOGRAMME DES ACTIVITES

Les différentes activités ainsi que les dates sont présentées dans ce tableau récapitulatif

ACTIVITE DE STAGE DATE DE DEROULEMENT

Activités formations Du 20 juin au 7 juillet
Activités Maintenances des équipements du 8 juillet au 27 juillet

Activités programmations Du 28 juillet au 20 août

Tableau 1 : chronologie des activités

P a g e 13 | 47
 III- DEROULEMENT DES ACTIVITES DU STAGE

1- Activités formations
Ce département est dirigé par le responsable des formations qui gère plusieurs unités
de formations. C’est un département qui est divisé en deux parties :

 La partie formation en interne : cette partie s’occupe de la formation des apprenants

sur des logiciels comme Word, Excel, power point, la création des feuilles de style
personnalisées.

 La partie formation externe : ici les formateurs travaillent plus à l’extérieur cas ils
s’occupent de la formation du personnel des entreprises qui utilisent les logiciels
développés par BRIOK. Cette formation consiste à adapter le personnel de
l’entreprise au nouveau logiciel de travail.

2- Activités maintenances des équipements et systèmes

informatiques
Nous avons été reçus par le responsable des maintenances qui nous a expliqué que ce
département est divisé en deux parties :

 La première partie s’occupe de la maintenance des équipements et système de

l’entreprise. Comme maintenance d’équipements on peut avoir les équipements
terminaux, les équipements réseaux. Et comme maintenance logiciel on a le
système d’exploitation, les différents logiciels qu’utilise l’entreprise.

 La seconde partie du département s’occupe de la maintenance des logiciels et sites

web que l’entreprise développe pour les clients. Cette partie du département est
très importante pour l’entreprise

P a g e 14 | 47
 3- Activités Programmations
C’est l’unité la plus importante de l’entreprise. Elle est constituée de plusieurs sous
unités :

 Unité d’analyse : cette unité est chargée d’analyser la faisabilité technique du

projet ainsi que l’ensemble des ressources nécessaires pour sa réalisation. Elle
produit après chaque analyse un dossier d’analyse technique.

 L’unité de conception : cette unité se charge de la partie conception de

l’application. A la fin de la conception elle produit un dossier de conception.

 L’unité de développement : cette unité est chargée de la réalisation de

l’application sur la base de la base de données fournie par l’unité de conception
et du langage choisit par l’unité d’analyse. A la fin de la réalisation, l’unité a
aussi la charge de tester l’application par un test d’intégration.

IV- APPORT DU STAGE ET JUSTIFICATION DU THEME

1- Apport Du Stage
Les deux mois que nous avons passé en stage nous ont permis de nous enrichir sur trois
(03) plans :

Apports humains : intégration dans le milieu professionnel (Entreprise), formation,

rapports hiérarchiques, rapports humains, etc.

Apports techniques : découverte des plusieurs méthodes et techniques dans le

développement logiciel, la découverte et l’apprentissage de plusieurs langages de
programmations (PHP, JAVASCRIPT, etc…) et Framework (BOOSTRAP,
LARAVEL, etc…).

Apport méthodique : L’utilisation de plusieurs méthodes dans l’analyse et la

conception d’un projet informatique.

P a g e 15 | 47
 2- Justification du thème de stage
A notre arrivé à BRIOK, il existait déjà un grand thème qui portait sur la création d’une
application web de gestion locative et/ou de vente. Cette application contenait plusieurs
modules parmi lesquels la gestion locative module sur lequel nous avons effectivement
travail en travaillant sur ce module nous avons pris pour référence la gestion des
logements.

P a g e 16 | 47
 CHAPITRE II : ETUDE DU SYSTEME EXISTANT

SECTION I : CRITIQUE DU SYSTEME EXISTANT ET

PROPOSITION DE SOLUTION
Dans cette section nous allons porter quelques critiques sur les systèmes existants et
proposer quelles pistes de solutions puis présenter les fonctionnalités de notre
application.

I- CRITIQUE DU SYSTEME EXISTANT

Les systèmes existants présentent plusieurs problèmes :
 La plupart des solutions de gestion locative sont développées avec des
langages qui ne sont pas facilement accessible et non pas une grande
communauté.
 Les meilleures applications de gestion locative ne sont pas gratuites par
d’exemple certains modules sur DOLIBARR et ODO ;
 Les applications de gestion locative existante ne sont pas totalement
libres ;
Sur le plan technique la plupart des applications de gestion locative
présentent plusieurs problèmes :
 Elles ne donnent pas la possibilité aux locataires d’interagir avec le
technicien directement lorsqu’il y’a un problème de maintenance ;
 Elles n’offrent pas la possibilité au propriétaire d’un logement de suivre
de manière régulier les paiements d’un locataire ;

P a g e 17 | 47
  Elles n’intègrent pas les nouveaux moyens de paiement comme
par exemple le paiement mobile.

II- PROPOSITION DE SOLUTION

Nous proposons de créer une application web de gestion locative qui est totalement libre,
gratuite et qui prend en compte le suivi des paiements du locataire. Cette application
mettra en relation direct le technicien, le bailleur et le locataire dans le processus de
maintenance. Cette application prendra aussi en compte les nouveaux moyens de
paiement et sera développée avec un langage accessible et populaire.

SECTION II : CAHIER DE CHARGE

Un cahier de charges est un document contractuel qui décrit de façon explicite ce que
le maitre d’ouvrage attend du maitre d’œuvre (les spécifications de l’application).

I- CONTEXTE
La gestion des logements est une tâche extrêmement complexe dans le monde en
générale et au Cameroun en particulier cas les spécialistes du domaine et les cabinets de
gestion coûtent extrêmement cher. Face à cette situation, plusieurs développeurs ont mis
en place des applications de gestion locative pour aider les propriétaires, les spécialistes
et les cabinets de gestion locative à mieux s’exercer. Mais le problème qui se pose est
que la plupart de ces applications de gestion locative ne sont pas libres ni open source
et présentent aussi certaines failles sur le plan technique ce qui rend le problème de la
gestion locative plus difficile cas la plupart des propriétaires de logement n’ont pas accès
de moyens pour se procurer ces applications.

II- OBJECTIF DE L’APPLICATION

Concevoir et développer un module qui gère les logements dans une application web.

P a g e 18 | 47
 III- FONTIONNALITES FUTURE DE L’APPLICATION
A la fin, notre application sera capable de :
 Gérer des logements
 Ajouter un nouveau logement
 Modifier un logement
 Supprimer un logement
 Consulter la liste des logements
 Gérer les contrats de location
 Modifier un contrat de location
 Supprimer un contrat de location
 Ajouter un nouveau contrat
 Consulter la liste des contrats
 Imprimer un contrat
 Valider une location
 Gérer des factures de location
 Ajouter une facture de location
 Modifier une facture
 Supprimer une facture
 Consulter la liste des factures
 Imprimer une facture
 Gérer les locataires
 Ajouter un locataire
 Modifier un locataire
 Supprimer un locataire

P a g e 19 | 47
 IV- ESTIMATION DES RESSOURCES ET DU BUDGET
PREVISIONNEL DU PROJET
1- Ressources matérielles
Les ressources matérielles nécessaires pour la mise en place de l’application de gestion
des logements sont décrites dans ce tableau ci-dessous.

Matériels caractéristiques Quantité Prix Montant

unitaire Total
Un laptop Core i3, 4Go RAM, 1 350 000 350.000
500 G0 SSD, ROM,
CPU 2.5Go AMD,
écran 16//
Windows 10 PRO
Modem - 4 G ORANGE 1 30.000 30.000
WIFI
CLE USB 16 Go SAMSUNG 1 15.000 15.000
ONDULEUR CHROME 1000 1 85 500 85.500
EOVICLINK
TOTAL 400.500

2- Ressources logicielles
LOGICIEL QUANTITE PRIX UNITAIRE Montant Total
POWER AMC 1 65.000 65.000
GANTT PROJET 1 - -
XAMPP 1 - -

P a g e 20 | 47
MICROSOFT 1 50.000 50.000
OFFICE 2016
TOTAL 115.000

3- Ressources humaines
Ressource Rôle Unité Rémunérat Durée Montant
humaine ion de
En mois travail
(en
mois)
Concepteur( Conception de 2 299.000 2 1 196 000
s) l’interface * 2
graphique du
logiciel
Analyste Analyste et 2 500 000 * 2 1 1 000 000
conception de
solution
Programme Codage et test 5 200 000 * 4 4 000 000
ur(s) d’intégration et 5
test d’assurance
qualité
Imprévue(s) 300 000

TOTAL 6 496 000

P a g e 21 | 47
 4- Coût total du projet

RESSOURCES MONTANT
Ressources humaines 6 496 000
Ressources matérielles 400.500
Ressources logicielles 115.000
TOTAL 7 011 500
Tableau 2 : estimation du cout du projet

V- Les contraintes liées au projet

La réalisation de notre application web prendra un certain temps compte tenu de la taille
du projet, des moyens financiers limités mais la première version sortira à la fin d’année
2020.

P a g e 22 | 47
 DEUXIEME PARTIE : MISE EN
ŒUVRE (DE LA MISSION)

Dans cette partie nous commencerons par présenter le dossier d’analyse

comme chapitre III et suite nous présenterons la mise en œuvre au
chapitre IV.

P a g e 23 | 47
 CHAPITRE III : DOSSIER D’ANALYSE

L’analyse est un procédé qui a pour objectif de permettre la formation des étapes
préliminaires du développement d’un système afin de rendre ce développement plus
fidèle aux besoins du client. Cette étude consistera à mettre en œuvre un certain nombre
d’outils d’analyse qui permettront de modéliser le besoin et de le rendre compréhensible
par ceux qui vont le couvrir. Nous allons décrire la méthode utilisée pour la réalisation
de l’application, puis viendra la description des diagrammes associés.

SECTION I : METHODE D’ANALYSE ET ACHITECTURE

DE DEVELOPPEMENT

Nous proposons ici une démarche d’application d’UML qui prend appui sur une des
méthodes agiles.

I- METHODE D’ANALYSE : AGILE

La méthode agile a été créée dans les années 2001 par un groupe de 17 experts en
développement logiciels. Cette méthode a été créé pour une plus grande implication du
client et une meilleure réactivité des équipes. Agile possède 12(douze) principes
généraux et ses valeurs sont au nombre de 4 (quatre) à savoir :

 L’équipe, soit des individus et des interactions plutôt que des processus et des
outils ;

P a g e 24 | 47
  L’application, c’est-à-dire des fonctionnalités opérationnelles plutôt que de la
documentation exhaustive ;
 La collaboration avec le client plutôt que la contractualisation des relations ;
 L’acceptation du changement plutôt que le suivi d’un plan ;

Méthode Scrum
Agile compte plusieurs méthodes parmi lesquelles Scrum. SCRUM est considéré
comme un cadre ou « Framework » de gestion de projet. Ce cadre est constitué d'une
définition des rôles, de réunions et d'artefacts.

Scrum définit 3 rôles :

 Le « Product Owner » qui porte la vision du produit à réaliser

(représentant généralement le client).
 Le « Scrum Master » garant de l'application de la méthodologie Scrum.
 L'équipe de développement qui réalise le produit.

La vie d'un projet Scrum est rythmée par un ensemble de réunions clairement définies
et strictement limitées dans le temps (timeboxing).

Figure 3 : Une présentation synthétique du processus SCRUM

P a g e 25 | 47
 II- PRESENTATION DU LANGAGE DE
MODELISATION

1- Présentation du langage UML

UML(en anglais Unified Modeling Language ou langage de modélisation unifié en
français) est un langage graphique de modélisation des données et des traitements. C’est
une formalisation non-propriétaire de la modélisation objet utilisée en génie logiciel ;
spécifiant plusieurs objectifs (comprendre et décrire les besoins, spécifier un système,
établir l’architecture logiciel) qui font un outil exact de communication. UML comporte
13 diagrammes

Les avantages de UML

 Gain de précision
 Gage de stabilité
 Encourage l'utilisation d'outils
 Il cadre l'analyse.
 Il facilite la compréhension de représentation
 Abstraites complexes. ?
 Son caractère polyvalent et sa souplesse en font un langage universel.

2- Les inconvénients de UML

 La mise en pratique d'UML nécessite un apprentissage et passe par une
période d'adaptation.
 L’intégration d'UML dans un processus n'est pas triviale et améliorer un
processus est une tâche complexe et longue.

P a g e 26 | 47
 III- ACHITECTURE DE DEVELOPPEMENT
Le modèle MVC décrit une manière d’architecturer une application informatique en la
décomposant en trois sous-parties :

 la partie Modèle ;

 la partie Vue ;
 la partie Contrôleur.

Ce modèle de conception (design pattern) a été imaginé à la fin des années 1970 pour
le langage Small talk afin de bien séparer le code de l’interface graphique de la logique
applicative. Il est utilisé dans de très nombreux langages : bibliothèques Swing et Model
2 (JSP) de Java, Framework PHP, ASP.NET MVC, etc.

1- Rôles des composants

La partie Modèle d’une architecture MVC encapsule la logique métier (business logic)
ainsi que l’accès aux données. Il peut s’agir d’un ensemble de fonctions (Modèle
procédural) ou de classes (Modèle orienté objet).

La partie Vue s’occupe des interactions avec l’utilisateur : présentation, saisie et

validation des données.

La partie Contrôleur gère la dynamique de l’application. Elle fait le lien entre

l’utilisateur et le reste de l’application.

2- Interactions entre les composants

P a g e 27 | 47
La demande de l’utilisateur (exemple : requête HTTP) est reçue et interprétée par le
Contrôleur. Celui-ci utilise les services du Modèle afin de préparer les données à
afficher. Ensuite, le Contrôleur fournit ces données à la Vue, qui les présente à
l’utilisateur (par exemple sous la forme d’une page HTML).

3- Avantages et inconvénients
Le modèle MVC offre une séparation claire des responsabilités au sein d’une
application, en conformité avec les principes de conception déjà étudiés : responsabilité
unique, couplage faible et cohésion forte. Le prix à payer est une augmentation de la
complexité de l’architecture.

Dans le cas d’une application Web, l’utilisation du modèle MVC permet aux pages
HTML (qui constituent la partie Vue) de contenir le moins possible de code serveur,
étant donné que le Scripting est regroupé dans les deux autres parties de l’application.

SECTION II : CONCEPTION DETAILLEE

P a g e 28 | 47
 I- DIAGRAMME DES CAS D’UTILISATION ET DE
SEQUENCE

Un diagramme des cas d’utilisation capture le comportement d’un système, d’un sous-
système, d’une classe ou d’un composant tel qu’un utilisateur extérieur le voit.

1- Acteur
Un acteur est l’idéalisation d’un rôle joué par une personne externe au système
d’information à l’étude qui interagit avec le système.

Nom de l'acteur

Formalisme d’un acteur

2- Cas d’utilisation
Un cas d’utilisation est une unité cohérente représentant une fonctionnalité visible de
l’extérieur.

Nom du cas d'utilisation

Formalisme d’un cas d’utilisation

3- Une association
Une association est une relation entre éléments d’UML (classe, cas d’utilisation, etc…)
qui décrit un ensemble de lien. Elle est utilisée dans le cadre du diagramme de cas
d’utilisation pour relier les acteurs et les cas d’utilisation par une relation qui signifie
simplement :<<participer à>>

P a g e 29 | 47
Formalisme d’une association

P a g e 30 | 47
 Diagramme 1 : cas d’utilisation gestion locative

4- Description des cas d’utilisation

P a g e 31 | 47
- Acteurs principaux : ils déclenchent le cas d’utilisation dans le but d’atteindre un
objectif et récupérer un résultat du système.
- Précondition : son rôle est de décrire les contraintes qui doivent être vérifiées
lorsque le cas d’utilisation est déclenché. En général une précondition indique
qu’une autre s’est déroulé auparavant.
- Post condition : permet de décrire les contraintes qui doivent être vérifiées
lorsque le cas d’utilisation est terminé.
- Scénario nominal : il décrit la séquence normal d’action associée au cas
d’utilisation.
- Scenario alternatif : il s’agit d’identifier toutes les autres situations possibles de
succès ou d’échec.

 Cas d’utilisation : consulter la liste des logements

Consulter la liste des logements

Acteur : propriétaire, locataire
Résumé : ce cas permet à l’utilisateur de consulter la liste des logements
Présupposé : l’acteur a démarré l’application
Pré condition : l’acteur possède le droit d’accès
Scénario nominal :
1- Le système affiche le tableau de bord
2- L’utilisateur clic sur consulter les logements disponibles
3- Le système affiche les types de logement disponible
4- L’utilisateur choisit le type de logement souhaité
5- Les systèmes affichent tous les logements de ce type disponibles

Scénario alternatif : A l’étape 4, si la requête échouée, le système renvoie un

message d’erreur et revient à l’étape 3 du scénario nominal
Post condition succès : l’utilisateur visualise tous les logements disponibles
Post condition d’échec : la demande a échouée

P a g e 32 | 47
 Arrêt : l’utilisateur quitte l’application

Tableau : cas d’utilisation consulter liste des logements

CONSULTER LES LOGEMENTS DISPONIBLES

SYSTEME BASE DE DONNEES

LOCATAIRE

ref
authentification()

afficher le tableau de bord

consulter la liste des logements

disponibles

affiche les types de logement disponibles

choisi le type de logement à consulter

requête

reponse (vraie ou faux)

alt Condition (faux)

erreur lors de l'afficharge des logements

Condition (vraie)

afficharge des logements

P a g e 33 | 47
  Cas d’utilisation effectuer une location

Effectuer une location

Acteur : locataire, propriétaire
Résumé : ce cas d’utilisation permet à l’utilisateur d’effectuer une location
Présupposé : acteur a démarré l’application
Pré condition : l’acteur possède le droit d’accès
Scénario nominal :
1- L’utilisateur clic sur consulter les logements en location
2- L’application affiche la page des logements disponibles
3- L’utilisateur choisit le logement qui souhaite souscrire
4- Le système affiche le contrat de location de ce logement
5- L’utilisateur remplit le formulaire et enregistre
6- Le système enregistre le formulaire, revient à l’étape 3 et affiche
souscription bien enregistrée et en attente de validation
Scénario alternatif : A l’étape 5, si tous les informations ne sont pas
correctement remplis alors retour à l’étape 4 du scénario nominal avec une
notification ‘veuillez vérifier si tous les champs sont correctement remplis’
Post condition de succès : l’utilisateur a souscrire à une location
Post condition d’échec : échec lors de l’enregistrement de la nouvelle location
Arrêt : l’utilisateur quitte l’application
Tableau 3 : effectuer une location

P a g e 34 | 47
SOUSCRIRE A UNE LOCATION

SYSTEME BASE DE DONNEES

LOCATAIRE

ref
authentification()

affiche la liste des logements

disponibles

clic sur le logement qu'il souhaite

souscrire

afficher le contrat de location de ce

logement

saisi les données dans le formulaire

affiche le contat de location

remplir le formulaire en enregistre

verification des champs

requête d'enregistrement

reponse (vraie ou faux)

alt Condition (reponse = faux)

erreur lors de l'enregistrement de la

demande de location

Condition(condition = vraie)
demande de location enregistrée avec
succès et en attente de validation

P a g e 35 | 47
  Cas d’utilisation ajouter une facture

Ajouter une facture

Acteur : propriétaire
Résumé : ce cas d’utilisation permet d’ajouter une facture
Présuppose : l’acteur a démarré l’application
Pré condition : l’acteur possède un droit d’accès
Scénario nominal
1- L’utilisateur clic sur ajouter facture
2- Le système affiche la page de travail
3- L’utilisateur saisi les différentes informations de la facture
4- Le système enregistre la facture et revient à la page de travail
5- Le système affiche la nouvelle facture enregistrée
Scénario alternatif : A l’étape 3, si les champs ne sont pas correctement remplis
alors retour à l’étape 2 du scénario nominal avec notification veuillez vérifier si
tous les champs sont correctement remplis
Post condition de succès : nouvelle facture enregistrée avec succès
Post condition d’échec : échec lors de l’enregistrement d’une nouvelle facture
Arrêt : l’utilisateur quitte l’application

Tableau 4 : enregistrer une facture

P a g e 36 | 47
DIAGRAMME D'AJOUT D'UNE FACTURE

SYSTEME BASE DE BONNEES

PROPRIETAIRE

ref
authentification()

affiche tableau de bord

demande l'interface d'ajout d'une facture

affiche formulaire d'ajout d'une facture

saisi données et enregistrées

verification

requête d'ajout

resultat(vrai ou faux)

alt Condition(resultat = faux)

message d'erreur lors de l'ajout d'une

nouvelle facture

Condition(condition = vrai)

nouvelle facture ajoutée avec succès

Diagramme 2 : ajout d’une facture

P a g e 37 | 47
 II- DIAGRAMME DE CLASSE
1- Définition
Un diagramme de classe UML décrit les structures d’objets et d’informations utilisées
sur notre site web, à la fois en interne et en communication avec ses utilisateurs. Il décrit
les informations sans faire référence à une implémentation particulière. Ses classes et
relations peuvent être implémentées de nombreuses manières, comme les tables de
classe de base de données, les nœuds XML ou encore les compositions d’objets logiciel.

2- La composition d’un diagramme de classe

En général un diagramme de classe peut contenir les éléments suivants :

- Les classes : une classe représente la description formelle d’un ensemble d’objets
ayant une sémantique et des caractéristiques communes. Elle est représentée en
utilisant un rectangle divisé en trois sections. La section supérieur est le nom de
la classe, la section centrale définie la propriété de la classe alors que la section
du bas énumère les méthodes de la classe.
- Les associations : 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 que les liens peuvent exister entre
des instances des classes associées.
- Les attributs : les attributs représentent les données encapsulées dans les objets
des classes.
Chacune de ces informations est définie par un nom, un type de données, une
visibilité et peut être initialisé. Le nom de l’attribut doit être unique dans la classe.

P a g e 38 | 47
 typefacture
- idtype_facture : int
- name : char
- description : String
+ deleted () : char
+ add () : char
+ edited () : char
+ search () : char

0..*

0..1

Facture_logement
Paiement
- idfacture : int
- numero_facture : int - idpaiement : int
- date_creation_facture : Date 1..1 - mode : char
- description : String - date_paiement : Date
1..* - montant : float
- etat : boolean
- montant : float - date limite de paiement : Date
- typepaiement : char
+ deleted () : char
+ deleted () : char
+ add () : char
+ edited () : char + add () : char
+ search () : char + edited () : char
0..*
0..* + imprimer () : char + search () : char

1..1

0..1 1..1 1..*

Detail_Facture
- iddtlfacture : int 1..1 1..1 1..*
- name : char emplacement
- Description : char - idemplacement : int Detail_paiement
- quantité : float utilisateur - nom : char
- prix unitaire : float - idutilisateur : int - pays : char - iddtlpaiement : int
- name : char
+ deleted () : char - nom : char - ville : char
- prenom : char - quartier : char - description : String
+ add () : char
+ edited () : char - datenaissance : Date - rue : char + deleted () : char
+ search () : char - adresseactuelle : char - adresse : char + add () : char
- ville : char - description : String + edited () : char
- telephone : int + search () : char
+ deleted () : char
- email : char + add () : char
- nationalite : char + edited () : char
- profession : char + search () : char
+ deleted () : char ...
1..1 + add () : char
1..1
+ edited () : char
Type_logement
+ search () : char
- idtypelogement : int
- name : char
- discription : String
1..* 0..*
+ deleted () : char
1..* + add () : char
contrat_location + edited () : char
- idcontrat : int logement + search () : char
- date_etablissementcontrat : Date - idlogement : int 0..1
- date_but_contrat : Date - numero_logement : char 0..*
- date-fin-contrat : Date - etat logement : char
- usage : String - prix location : float
- duree_location : Date - photo : char
- detail_contrat : char
+ deleted () : char
- echeance_paiement : char
+ add () : char
- montant_echeance : float 0..*
+ edited () : char detailogement
+ deleted () : char 1..* + search () : char
+ add () : char 1..1 - iddtllogement : int
+ edited () : char - nombre de piéce : char
+ search () : char - superficie : float
0..1 - description : char
+ imprimer () : char
+ deleted () : char
+ add () : char
+ edited () : char
+ search () : char

Diagramme 5 : diagramme de classe gestion des logements

Pour conclure, nous dirons que cette partie consacrée à la conception nous a permis de
modéliser le système à travers plusieurs diagrammes. Ces diagrammes spécifient les
P a g e 39 | 47
fonctionnalités de l’application à développer les interactions entre les objets pendant son
utilisation.

P a g e 40 | 47
 CHAPITRE IV : REALISATION DE
L’APPLICATION

SECTION I : LANGAGES UTILISES ET FONCTIONNEMENT

DES APPLICATIONS WEB

I – LANGAGES UTILISES

 HTML & CSS

HTML : Hyper Text Markup Language est un langage dit de balises dont le rôle est de
formaliser l’écriture d’un document avec des balises. Les balises indique la façon doit
être présenté. ?

P a g e 41 | 47
CSS : Cascading Style Sheets est un langage qui permet de gérer l’apparence de la page
web (l’apparence, décoration, positionnement, couleur, taille et police du texte…).

 Le SQL

Le SQL ou langage de requêtes structurées est un langage permettant de communiquer

avec une base de données. Ce langage informatique est notamment très utilisé par les
développeurs web pour communiquer avec les données d’un site web. C’est grâce à lui
qu’on peut effectuer les opérations d’ajout, de mise à jour, de supprimer, de sélection.

II-ENVIRONNEMENT LOGICIEL
 LARAVEL

Laravel est un Framework web open source écrit en PHP respectant le principe modèle-
vue-contrôleur et entièrement développé en programmation orienté objet. Nous l’avons
utilisé pour la conception de notre API REST.

 XAMPP

XAMPP est un ensemble de logiciels permettant de mettre en place facilement un

serveur Web local, un serveur FTP et un serveur de messagerie électronique.

1- Logiciels utilisés

P a g e 42 | 47
 LOGICIEL UTILITE

VISUAL PARADIGM pour la réalisation des diagrammes : cas

d’utilisation, séquence, classe

POWER DESIGGNER Pour la réalisation du diagramme de

séquence et de classe

VISUAL STIDIO CODE pour la réalisation du code

XAMPP Pour la réalisation de notre base de

données

2- Sites visités
 Openclassroom à l’adresse : www.openclassrom.com
 Le site du zéro à l’adresse : www.siteduzero.com

III – FONCTIONNEMENT DES APPLICATIONS WEB

Parmi les applications web on distingue deux types qui sont : application web
Statique et application web dynamique.
 Statique
Voici ce qui se passe lorsqu’on visite une page HTML dite statique sur internet.

P a g e 43 | 47
 Figure : Fonctionnement d’une application web statique.
Votre navigateur envoie l’adresse URL (Uniform Ressource Locator) que vous avez
tapé. Le serveur web est un « ordinateur » présent sur internet et qui héberge la page que
vous avez demandé. Ce serveur on trouve Apache
Le logiciel apte à traiter les requêtes HTTP que vous envoyez lorsque vous demandez
une page web. Apache va donc chercher le fichier demandé dans son arborescence et
renvoie à votre navigateur la page cherchée.
Votre navigateur interprète les différents langages se trouvant dans ce fichier (HTML,
CSS, JavaScript, etc.)

 Dynamique
Maintenant voyons ce qui se passe lorsque notre page HTML contient du code PHP,
SQL, etc.

P a g e 44 | 47
 Figure 12 : Fonctionnement d’une application web dynamique.

Votre navigateur envoie l’adresse que vous avez tapé

 Le serveur cherche dans son arborescence si le fichier existe, et si celui-ci
porte une extension reconnue comme une application PHP (. PHP, .PHP3,
.PHP4 par exemple). Si c’est le cas, le serveur web transmet ce fichier à
PHP.

 PHP analyse et exécute le code PHP qui se trouve entre les balise
< ?php…?> du fichier. Si le code contient les requêtes SQL, la base de
données renvoie les informations voulues au script qui peut les exploiter
(pour les afficher par exemples).

 PHP continue de l’analyse du code de la page, puis retourne le fichier

dépourvu du code PHP au serveur web.
P a g e 45 | 47
  Le serveur web renvoie donc un fichier ne contenant plus de PHP, donc
seulement du code HTML au navigateur qui l’interprète et l’affiche

SECTION II : CREATION DE LA BASE DE DONNEES AVEC

PHPMYADMIN ET BILAN DE STAGE
I – CREATION DE LA BASE DE DONNEES AVEC PHPMYADMIN
PhpMyAdmin (PMA) est une application multiplateforme web de gestion
pour les systèmes de gestion de base de données MySQL réalisée principalement en
PHP et JavaScript et distribué sous licence GNU GPL. C’est avec PhpMyAdmin que
nous avons créé notre base de données « MAISON ».

P a g e 46 | 47
 CONCLUSION GENERALE
Ce stage nous a permis de voir comment fonctionne le monde professionnel à
travers l’entreprise Briok.

Durant notre période de stage, l’entreprise nous a attribué un thème de stage qui
portait sur la gestion locative en nous avons pris pour référence la gestion des
logements. En effet il était question pour nous de concevoir et développer une
application de gestion des logements qui viendra corriger les manquements des
applications déjà existant. Pour mener à bien notre mission nous avons divisé le
travail en quatre (4) chapitres et chaque chapitre avait un rôle spécifique. Nous
avons dans le cadre de notre développement présenté l’entreprise et son
fonctionnement, nous avons aussi présenté le système d’information donc il était
question et enfin nous vous avons montré les technique d’analyse, de conception
et de développement utilisées pour le développement du nouveau système. Donc
nous pouvons dire que notre mission a été accompli dans l’entreprise Briok cas
nous avons atteint notre objectif.

P a g e 47 | 47