I

Epigraphe

Quand le pourquoi est suffisamment fort, on trouve l’énergie

Pour le comment
 II

DEDICACES

A mes très chers parent MUSIMBWA JEANT-JEANCQUE et NGALIMA

BIBICHE qui, malgré les multiples difficultés rencontrées, ont dû se battre afin de me
voir persévérer dans la vie d’étudiante.
A mes sœurs : BILONDA KAYEMBE MARTINE et NGOY WA NGOY
YOERLY ; ET mes frères : KASHINDIKA KAMAYI ANACLET et MUYA MUYA PIERRE,
pour le confiance témoignée à notre égard, la chaleur fraternelle et soutien moral,
matériel et financier envers moi.
 III

REMERCIEMENT

Le présent travail, que nous avons l’honneur de vous présenter, marque la fin de
notre cycle de licence en informatique de gestion à l’institut supérieur de statistique de
Lubumbashi.

Cependant, nous ne saurons entrer dans de ce travail sans pour autant exprimer
notre reconnaissance aux personnes qui de près ou de lion ont largement contribué à la
réalisation de ce travail.

Nos remerciements vont tout droit à l’éternel notre Dieu, source de toute sagesse
et intelligence pour le souffle de vie accordé durant tout ce cycle de licence.

Au chef des travaux Chef des travaux BULA BUTUPU pour avoir accepté de
diriger ce travail malgré ses multiples ses multiples occupations.

Une profonde gratitude à l’assistant PRINCE KABONGO pour son encadrement,

suivi et sa disponibilité à répondre et à résoudre les problèmes que l’on a eu à
rencontrer ce, malgré ses multiples occupations.

Mes remerciements s’adresse également à mon très cher père JEAN-JEAQUE

MUSIMBWA et ma très cher maman ILUNGA ANNIE pour leurs prières et leurs efforts
consentements pour la formation de leurs fille.

Aux autorités académiques ainsi qu’à tout le corps professoral de l’institut

supérieur de statistique en général et ceux du département de l’informatique en
particulier professeurs, chefs des travaux et assistants qui se sont livrés corps et âme
pour nous donner une formation efficace, la quelle vient de façonner notre personnalité.

Que tous ceux qui, de près ou de loin, ont contribué à la réalisation de ce travail
et dont les noms n’ont pas été cités explicitement, puissent trouver au travers de ces
mots l’expression de notre profonde gratitude.
 IV

LISTE DES ABREVIATIONS, SINLES ET SYMBOLES

 AJAX Asynchrones javaSript and XML

 API application programming interface
 BD Base de données
 CRUD Create read Update delete
 CSS Cascade style sheet
 DAO Data access object
 HTML Hypertext markup language
 HTTP Hyper texte Transfer Protocol
 IDE Intégrale développent environnement
 IHM Interface homme machine
 JS Java Script
 MVC modèle vue contrôleur
 MYSQL My structured Query language
 SGBD Système de gestion de base de données
 UML Unified modeling language
 XAMPP (across) Apache Maria DB perl Php
 UP Unified process
 PHP Personal home page
 URL Uniform resource locator
 SQL Structur query language
 V

RESUMER
Aujourd’hui l’accès à un logement décent et au juste prix est l’une des
préoccupations majeures de la population congolaise.
Les enjeux multiples et les problèmes récurrents posent une grande
acuité qui nous interpelle d’une façon ou d’une autre.
Pour redynamiser la production de logement aussi bien social, que pour
des organisations et permettre l’accès à organiser un plus grand nombres
des personnes, le gérant s’est rendu compte qu’un système informatique
serait le plus accepter dans la résolution des différentes taches dont elle e la
charge.
La salle ne dispose pas de système informatique. Elle est confrontée à
une gestion efficiente de l’information du fait du nombre de plus croissant de
demande de titre de propriété, de problèmes liés à la délivrance des
attestations, de l’utilisation des fiches et l’exiguïté voire l’inexistence de
locaux d’archivage.
Or sans la solution efficace il sera très difficile de satisfaire sa clientèle,
ce qui entraine des nombreux handicaps qui ralentissent considérablement
ou freinent son développement.
Ce moire propose la conception d’une application web pour l’autorisation
de la gestion afin de faciliter le processus de suivre la location de(salle de
fête ) et la clientèle pour y parvenir, des études et des entretiens one été
menées auprès des différents utilisateurs
Nous avons adopté la méthodologie UP pour développement de notre
application.
Apres ceci, nous avons fait une spécification et une analyse des besoins
fonctionnels pour formaliser les données avec UML (unified modeling
laguage).
Pour la structuration et le stockage des données nous avons utilisé le
système de gestion des bases de données relationnelles (SGBDR) MSQL.
L’implémentation en PHP , HTML, CSS, javaSript et le framework
bootstrap nous a permis de mettre en place une application simple, sécurisée
et permettant d’automatiser la gestion de location de (salle de fête) et des
clients et dématérialiser les documents administratifs et dossiers clients qui
s’y rapportent.
 1

INTRODUCTION

1. PRESENTATION DU SUJET

De nos jours la société se voit envahit dans beaucoup de domaine

sans exception par l’informatique dans la cherche des solutions aux différente
difficultés.

Par sur croit, avec une application web qui se définit comme étant
logiciel qui s’exécuté dans votre navigateur web. Les entreprises doivent changer des
informations et fournir des services il n’y a pas d’installation préalable à réalise sur son
poste de travail au sur sa tablette (contrairement à un logiciel ou une application
mobile) le sauve gardes sont centralisée sur le serveur et il n’y a plus besoin de réaliser
des mises à jours sur tous les poste du travail.

Ainsi l’application a pour but d’adapter la possibilité de gérer les

informations d’une manière automatique en réduisant les temps de leurs exécutions afin
de permettre une recherche rapide des informations de toute organisation qui se veut
moderne.

De ce fait il est important pour nous de concilier le monde informatique

et celui de travail au travers de ces outils informatique qui par ailleurs cherchent de
trouver des nouvelles applications grâce au développement des techniques innovantes
dans différents domaines avec objectif de réduire les contrats.

C’est dans cette idée nous nous sommes intéressées au

développement d’une application web de gestion de location d’une salle de fête de
mariage cas de Auguy NDALA.

Le système manuel mis en application web de gestion qui pourra servir

aux responsables compétents de bien pouvoir faire le suivi des contacts de location
maintenus sous contrôle la salle.

Et celle-ci fera le sujet par lequel nous allons exploiter tout au long de
notre travail.
 2

2. ETAT DE LA QUESTION

Il consiste un passage en revue des travaux antérieurs similaires un lien

avec celui que nous traitons.

Cette opération est un inventaire consistant à vérifier si ce sujet qui fait

l’objet de notre réflexion a été traité ; car nous sommes dans un monde complémentaire
ou tout a été dit et redit.

Pour effectuer ce travail nous avons recouru aux différents travaux de

nos prédécesseurs que voici

 SOKE KAHABWELE VICTOIRE

Qui a parlé sur le « développement d’une solution web de suivi des locations des
maisons dans une agence immobilière

Ce prédécesseur avait comme préoccupation

 La perte de temps lors de vente des documents

 Lenteur dans l’exécution de processus d’enregistrement de location
 Difficultés de passer une commande de réservation.

Il soulevé la question de question de savoir,

« Partant des difficultés énoncées ci haut notre préoccupation majeure est de savoir
qu’elle sera la solution à donner réorganisés et partager les donnes » voilà autant des
questions qu’ont constitué notre problématique.

 MAKONGA YANNICK qui a parlé sur « développement d’une application web de

réservation des chambres dans un hôtel »
 Mauvaise gestion de processus
 Difficulté liées au contrôle
 Confusion liées aux informations des clients

Il a soulevé comme préoccupation à savoir : « que faire pour améliorer le système de

gestion de location de vente des articles de cette organisation ?» les problèmes
 3

soulevés par ces dernier fut la lourdeur dans la transmission des informations des
clients dans la prise des certaines décisions.

Pour notre perte le souci, majeur est de mettre en place un système informatique.

De ce qui précède, tout en nous situant dans le prolongement des études de nos
prédécesseurs ; le nôtre se démarque par le fait qu’elle cherche à mettre à la disposition
de la salle de fête un outil informatique de faciliter un bon suivi des clients dans la
location de salle effectué un en sécurité

3. CHOIX ET INTERET DU SUJET

Dans ce cadre d’une recherche scientifique le choix et l’intégrer du sujet son d’une
importance capitale car il permet à l’étudiant ou au chercheur de rendre concret le
problème pos.

3.1. CHOIX DU SUJET

Notre choix sur ce sujet la salle du mariage connait des problèmes dans le la gestion de
contra des clients, nous amené à faire l’examen sur ce dernier en vue d’apporter une
modelé contribution, en mettant

Au point une application informatique à la porte des responsable.

3.2. INTERET DU SUJET

Les impératifs scientifiques exigent que toute recherche bien amenée relevé un intégrer
pour les chercheures même.

En suite pour la discipline scientifique et en fin la société.

 Interner scientifique

Du point de vue scientifique le pèsent travail à apporte un petit plus au

monde scientifique surtout aux analystes concepteurs de système d’information d’avoir
une compréhension claire sur les différents outils utilises.

De plus ce travail permettra aux chercheurs dans ce domaine d’étude

d’avoir une base sur le thème et d’améliorer ou adapter ce travail pour une bonne
marche de la science
 4

 Intérêt personnel

Ce sujet c’est une opportunité qui s’offre à nous entant que chercheur afin
d’élargir mes compétences dans le domaine d’enregistrement des documents au contrat
de location utilise à la salle de conception de système d’information d’interne, de gestion
de base de données du web, et de la programmation des applications informatique.

 Intérêt social

La nécessité d’être informer en temps réel est la préoccupation de tout le

monde l’application informatique qui découlera de cette étude aidera les responsables
de vérifier à tout moment si l’une de vos salles est disponible et de la réserver
facilement et conserver toutes informations des clients leurs documents sans exception.

4. PROBLEMATIQUE

La problématique est définie selon le dictionnaire français le grand Robert « qui

prête à discussion : dont l’existence, la vérité, la certitude réussite est douteuse.

Mais selon le professeur PATRICK MASANGU « la problématique est l’ensemble des

questions que les chercheurs se posé sur la réalité selon le problème auquel il est
confronté ».

Elle permet aussi de parvenir à un stade plus avancé d’un raisonnement

personnel au travers d’une question.

De ce fait une salle de fête de fête rencontre les problèmes ci-après :

 La perte de temps de la vérification des contrats de location et autres

documents de vente,
 La lenteur dans l’exécution des processus d’enregistrement des contrats de
location de salle de fête dans le registre,
 Incapacité de prouver l’historique des contrats de
 Vente et location anciennes des clients
 5

 Les contrats sont stocks dans des armoires, il y a risque de perdre certaines
informations et aussi le manque d’espace dans le bureau pour place les fiches, et
cela crée de l’encombrement ;
 La perte de temps lors de la vérification des contrats de location et autres
documents de vente.

« Partant de difficultés annoncer plus ci haut, notre préoccupation majeure est de savoir
quelle sera la solution à donner face à ces difficultés comment

5. HYPOTESE

Sécuriser réorganiser et partager les données ? » Voilà autant des questions

qu’on constitue notre problématique.

Une hypothèse set l’idée que l’on veut défendre ou démontrer comme point de
vue tout au long de notre travail. Par rapport à la problématique elle est la réponse est
une proposition à partir de laquelle no résonne pour résoudre un problème, pour
montrer un thème au regard de ces définitions.

Nous pouvons dire que l’hypothèse est une réponse donnée provisoirement à la
question ou aux interrogations soulevées dans la problématique.

Partant de ces définitions, tout se référant à la question posée dans, la

problématique, AUGUY NDALA nous proposons de mettre à la disposition de la salle
de mariage une application informatique pouvant difficulté.la méthode utiliser dans notre
travail set la méthode UML comme langage de modélisation.

IL Est à noter qu’UML n’offre pas une méthodologie pour l’analyse et la

conception, mais un langage qui permet le résultat de cette phase.

6. METHODE ET TECHNIQUES

6.1. METHODE

La méthode est définie comme l’ensemble des opérations intellectuelles par les
quelles une discipline cherche à attendre les vérités qu’elles poursuivent, le démontrer.
 6

En informatique, dans le domaine d’analyse et conception de système d’information, elle

est définie dont l’objectif est de produire un logiciel de qualité qui prend aux besoins de
ses utilisateurs.

6.2. TECHNIQUE

La technique est le procéder ou ensemble des procéder mis en œuvre pour

obtenir un résultat déterminer (dans un domaine particulier)

Elle est aussi un instrument utiliser et juger nécessaires pour récolter l’information
pouvant servir à l’élaboration d’un travail scientifique.

Ainsi pour nous permettre de bien collecter les données utiles à l’élaboration de notre
travail nous avons fait recours à la technique suivante :

 Technique documentaire

Cette technique nous a permis de consulter divers documents utilisés à la salle :

 Le contrat de localisation
 Les preuves de paiement
 Technique d’interview

L’interview est un procéder d’investigation scientifique utilisant un processus

de communication verbale pour recueillir des informations en relation avec le but fixé.

Cette technique nous a permis d’entre en compact avec les responsables concerner et
ainsi poser des questions afin de recueillir les informations utiles.

 Technique d’observation

L’observation comprend l’ensemble d’observations par le quelles le modelé

d’analyse (constitue l’hypothèse et concepts avec leurs dimensions et leurs indicateurs)
est sous mis à l’épreuve des faits confronter à des données observables attentivement
le déroulement les des activités dans la salle.

7. DELIMITETION DU SUJET

Les normes de la rédaction d’un travail scientifique exigent à ce que

nôtres travail soit limiter dans le temps et dans l’espace.
 7

C’est ainsi que nous les limitations dans le temps sur une période allant de 2023 à 2024
et dans l’espace pour ne pas être trop abstrait, nous allons considérer au sein du
bureau d’archivage des documents de location, pour lequel nous cherchons à mettre un
nouveau système et situer dans la ville de Lubumbashi, province du haut Katanga.

8. SUBDIVISION DU TRAVAIL

Outre l’introduction et la conclusion générales ce travail est subdivisé en quatre

chapitres à savoir :

 CHAPITRE1 : cadre conceptuel et considération théorique : Ce chapitre sera

question de définir tous les concepts, les termes opérationnels et la considération
théorique et méthodologique qui sont utilisé dans le présent travail.
 CHAPITRE 2 : analyse du métier : Ce chapitre Sara dédie à la présentation
de la structure générale de la salle qui est du métier pour en foin finir avec une étude
approfondie du problème et voir comment proposer une solution.
 CHAPITRE 3 : analyse et conception de système : Ce chapitre sera basé sur
la conception d’un système d’information en mettant en place des modèles à l’aide de la
notion UML selon la démarche UP.
 CHATRE 4 : implémentation du système : Ce chapitre sera basé à la mise en
place d’une application en écrivant aussi les étapes de programmation que nous avons
faite pour l’implémentation de notre application ainsi que son déploiement.
 8

CHAPITRE I. CADRE CONCEPTUEL ET CONSIDERATION THEORIQUE

Dans le but de donner une idée générale sur la conception de notre travail, ce
chapitre présentera les définitions des concepts théorique essentiel qui cadre avec notre
sujet et ceux cadrant avec le domaine informatique qui ont été utilisés dans notre travail
de manière bref afin de donner une idée globale aux lecteurs

1. DEFINITIONS DES CONCEPTS

1.1CONCEPTES DU DOMAINE D’ETUDE

 Suivi : qu’on suit, Quin se fait d’une manière continue.

 Solution : d’une manière générale, elle désigne une action permettant de
surmonter un problème selon le grand LAROUSSE illustré 2020, une solution est une
résolution d’une difficulté ; une réponse à un problème.
 Location : action par laquelle le propriétaire d’une chose donne à quelqu’un, à
titre de louage ou de batail
 Une salle de fête (polyvalente) : est un lieu publique qui est mis à la
disposition des habitants pour tenir un évènement festif .le battement est généralement la
propriété de la commune géré par le service municipal chargé par de la vie associative.
Les salles spécifiques sont nécessaires si l’activité culturelle est plus importante et
nécessite de mobiliser plus souvent l’espace

1.2. CONCEPTION DU DOMAINE INFOMATIQUE

Logiciel : d’après le grand robre, ce terme désigne un ensemble des

programmes procèdes et règles éventuellement de la domination relatifs au
fonctionnement d’un ensemble de traitement de l’information.

Application partagée : la répartition c’est fait d’un seul et même traitement entre
différentes machines. MS :(content management système) est un moteur de ici site web,
généralement spécialiser pour un site permettant d’éditer facilement tout ou une partie
de comptent du site.
 9

Langage de programmation : un langage de programmation est un ensemble des règles

et des signes guidant à l’élaboration d’un programme destiné à donner les instructions à
un ordinateur. Avec la remarquable évolution dans le domaine informatique, il existe
aujourd’hui plusieurs langages de programmation .nous avons cites : C#.net, java,
python, PHP, perl, c/c ++, etc.

 Données : une donnée peut se définir différemment. Selon un vieux dictionnaire de

statistique indique qu’une donnée est « le résultat d’une observation faite sur une
population » C’est aussi une information représentée sous une forme
conventionnelle, afin de pouvoir être traitée automatiquement.
 Système informatique : le système informatique est un ensemble organisé
d’objectifs techniques matériels, logiciels, applicatifs qui présentent l’infrastructure
d’un système d’information. Il est parti informatisée du système d’information
automatisable.
 Informatique de gestion : l’informatique de gestion est la discipline du traitement
de l’information utile et nécessaire à automatiser toutes parties de l’administration
des intérêts ou des affaires des entreprises.
 Analyse système : c’est spécifie en détail la façon dont le système d’information
doit faire.
 Conception de système : c’est spécifie en détail la façon dont les nombreux
composants d’un système d’information doivent être physiquement implanté.
 Programmation : codification des instructions indiquant les opérations

Qu’on doit effectuer un ordinateur.

 Langage informatique : on appelle « langage informatique » un langage destiné à

décrire l’ensemble d’actions qu’un ordinateur doit exécuter, il est ainsi une façon
pratique pour nous de donner des instructions a un ordinateur.
 Base de données(BD) ou data base en anglais : ensemble organisé de données,
servant de support à une application informatique, interrogeable par le contenue.

Généralement, une base de données est contrôlée par un système de gestion

permettant d’effectuer la recherche de la fusion de données, ainsi que toute autre
 10

requête relative à ces données. Les bases de données comptent l’heure actuelle de
nombreux domaine de mis en pratique : gestion de clientèle, etc…

Elle est aussi définie comme un ensemble structuré de données apparentées qui
modélisent un univers réel.

 Informatique : science du traitement automatique de l’information

 Ordinateur : dispositif ou machine électronique de traitement de l’information,
exécutant les instructions d’un programme préalablement enregistre dans sa
mémoire.
 Système d’information : le système d’information (IS) est un ensemble organisé
de ressources qui permet de collecter, traiter et distribuer de l’information, en
général grâce à un ordinateur.
 Internet : internet est un réseau informatique qui relie des ordinateurs du monde
entier entre eux et qui leur permet d’échanger des informations.

Les données sont transmises par l’intermédiaire de lignes téléphoniques, de

Câbles ou de satellites.

Pour communiquer entre eux, les ordinateurs connectés à internet utilisent un langage
commun (nommé protocole) et sont équipes de logiciel (ou programmes) permettant
l’échange de données. Il suffit de cliquer sur un lien pour être dirigé vers une nouvelle
page.

Les informations de ces pages peuvent apparaitre sous forme de textes, d’images, de
son ou de vidéo.

Chaque page crée par un particulier, une entreprise ou une organisation.

 Réseau informatique : ensemble des connexions entre l’ordinateur et périphérique,

un réseau informatique, permet à ses utilisateurs d’envoyer et de recevoir des
informations de leurs poste de travail.
 Serveurs (informatique) : ordinateur ou programme prenant en charge certaines
fonctions pour le compte des autres systèmes d’un réseau informatique.
 Architecture clients /serveurs : en informatique, arrangement propre à certains
réseaux locaux qui fait appel au concept d’intelligence distribuée pour considérer le
 11

serveur et stations de travail comme des dispositifs intelligent et programmables,

exploitant ainsi les pleines capacités de chacun d’eux.

Cet arrangement est obtenu en partageant le traitement d’une application en deux

composantes : un client, au premier plan, en un serveur, à l’arrière-plan.

 Protocole (informatique) : ensemble de règle de communication qui permet à deux

ou plusieurs entités (ordinateur, application logicielles, périphériques d’ordinateur,
etc.)

D’échanger des données entre elles, un protocole peut être comparé à une langue :
pour que deux personnes puissent se comprendre, il faut qu’elles utilisent la même
langue, et de la même manière que deux entités puissent échanger des données, elles
doivent impérativement utiliser le même protocole.

 Sécurité informatique : ensemble des mesures prises pour gérer un ordinateur et

les données qu’il contient

La sécurité informatique dépend du type de système et de l’importance des

informations. Dans tous le cas, la sécurité doit être assurée de manière globale. Un
système possède en effet la sécurité.

La sécurité recouvre les points suivant :

 L’indentification : qui est celui qui se connecte sur l’ordinateur ?

 L’authentification : est-on sûr de l’identité de celui qui est connecté ?
 La confidentialité : est-ce qu’un utilisateur peut accéder à des dons
Nées qu’il n’a pas le droit de voir ?
 L’intégrité des informations : est-on sûr que l’information n’a pas été modifiée par
quelqu’un de non autorisé ?

De plus, le problème s’accroit si l’ordinateur que l’on veut sécuriser est connecté à un
réseau comme internet.

Dans ce cas, les possibilités d’intrusion sont beaucoup plus grandes et l’utilisation d’un
pare-feu (ou firewall) s’avère alors indispensable.
 12

Pour leurs actes d’intrusion illégale, les hackers sont appelés les pirates de
l’informatique.

Ils utilisent généralement un bogue (ou une faiblesse) du système d’exploitation de

l’ordinateur cible ou prennent illégalement l’identité d’un utilisateur autorisé.

 Navigateur ou browser en anglais : est un logiciel conçu pour web, permettant aux
utilisateurs d’explorer les ressources à l’intérieure d’un réseau internet, extranet.

Il gère l’affichage des pages web et le suivie des liens hypertextes ou hypermédias entre
les différentes pages.

Les navigateurs les plus utilisés sont internet explorer de Microsoft, Firefox de la
fondation Mozilla et chrome de Google.

Système de gestion de base de données (SGBD) : est un logiciel qui gère et contrôle
l’accès à une base de sonnées (data base management système).

C’est un système qui permet de gérer une base de données partagée par plusieurs
simultanément. Le système de gestion de base de données nous permet de :

 D’écrire les données, langage de définition de données (DDL),

 Manipuler les données, langage de manipulation de données (DML)
 Contrôler les données, langage de contrôler de données (DCL)

1. 3. CONSIDERATIONS THEORIQIUES

a) Généralités sur UML et UP

La conception d’un système d’information n’est pas évidente car il faut

réfléchir à l’ensemble de l’organisation que l’on doit mettre en place.

La phase de conception nécessite des méthodes permettant de mettre en place un

modèle sur lequel on va s’appuyer.

La modélisation consiste à crée une présentation virtuelle d’une réalité de telle façon à
faire ressortir les points auxquels on s’intéresse.

Ce type des méthodes appeler analyse.

 13

L’entreprise est bun système complexe dans lequel transitent de nombreux Flux
d’informatique. Sans un dispose de maitrise de ces flux, l’entreprise peut être dépassée
et ne plus fonctionner avec une qualité de services satisfaisante.

L’enjeu de toute entreprise qu’elle soit de négoce, industrielle ou de service

consiste donc à mettre en place un système destiné à collecter, mémoriser, traiter, et
distribuer l’information (avec un temps de réponse suffisamment bref). Ce système
d’information Assurera le lien entre deux autres systèmes de l’entreprise : le système
opérant et le système de pilota

2. PRESENTATION D’UML

Le langage UML (unifie Mödling langage) est un langage de modéliser qui a

pour but de faciliter les transitions, lors du développement, du besoin originel à la phase
d’implémentation.

Néanmoins, l’utilisation d’UML n’est pas restreinte au développement de

système informatisé, mais peut servir au développement de système de gestion, tout
comme à la résolution des problèmes d’organisation de tout style.

De plus, UML, de représentation essentiellement graphique, fait extrême

vulgarisé et intuitif, est utilisable par les êtres humains ainsi que les machines.

Il est a noté que on parle contrairement de langage UML et non de méthode,

car UML propose des outils et des concepts de modélisation, et non pas une
méthodologie à respecter impérativement.

OBJECTIF

Au final, le langage UML est une synthèse se tous les concepts et

formalisme méthodologiques les plus utilisés, pouvant être utilisés, grâce à sa simplicité
et son universalité, comme le langage de modélisation pour la plupart des systèmes
devant être développes.

Le langage UML permet ainsi d’apporter des solutions lors du développement de

systèmes informatisés :
 14

 Décomposer le processus de développement en distinguant la phase d’analyse

(aspects fonctionnelles) de la phase de réalisation (aspects technologiques et
architecturaux).
 Décomposer le système en sous-systèmes plus facilement abordables : réduction
de la complexité, répartition du travail, réutilisation des sous-systèmes ;
 Utiliser une technologie de haut niveau proche de la réalité pour aborder le
développement.

La modélisation proposée par le langage UML se réalise principalement

sous forme graphique, en usant de vers types de diagrammes spécifique, dans sa
version 2 UML proposent treize diagrammes qui peuvent être utilisés dans la description
d’un système.

Ces diagrammes sont répartis en deux groupes :

 Structure du système : ces diagramme, sont aux nombres de six diagrammes qui
représente l’aspect statique d’un système (classique, objectif, composants…).
 Diagramme de classes : ce diagramme représente la description statique du
système en intégrant dans chaque classe la partie dédiée aux données et celle consacrée
au traitement.
C’est le diagramme pivot de l’ensemble de la modélisation d’un système
 Diagramme d’objectifs : le diagramme d’objectifs permet la représentation
d’instances des classes et des liens entre instance.
 Diagramme de composants : ce diagramme présente les différents constituants du
logiciel au niveau de l’implémentation d’un système.
 Diagramme de déploiement : ce diagramme d’écrit l’architecture technique d’un
système avec une vue centrée sur la réparation des composants dans la configuration
d’exploitation
 Diagramme des paquetages (UML v2) : ce diagramme donne une vue d’ensemble
du système structuré en paquetage. Chaque paquetage représente un ensemble
homogène d’éléments du système (classe, composants…).
 15

 Diagramme de structure composite (UML v2) : ce diagramme permet de d’écrire

la structure interne d’un ensemble complexe composé par exemple de classe ou l’objet et
des composants technique.
Ce diagramme met aussi l’accent sur les liens entre les sous-ensembles qui
collaborent.
 Comportement du système : ce diagramme est destiné à représenter les besoins
des utilisateurs par rapport au système.
Il constitue un des diagrammes les plus structurants dans l’analyse d’un système.

 Diagramme de cas d’utilisation : ce diagramme est destiné à représenter les

besoins des utilisateurs dans l’analyse du système.
 Diagramme d’états transitions : ce diagramme montre les différents états des
objets en relation aux évènements.
 Diagramme d’activités : ce diagramme donne une vision des enchaînements des
activités propres à une opération ou à un cas d’utilisation.
Il permet de représenter les flots de contrôle et les flots des données
 Diagramme de séquence : ce diagramme permet de d’écrire les scenarios de
chaque cas d’utilisation en mettant l’accent sur la chronologie des opérations en itération
avec les objets.
 Diagramme de communication (autre fois appelé collaboration):ce diagramme à
une autre représentation scenarios de cas d’utilisation qui met plus l’accent sur les objets
et les messages échangés.
 Diagramme de vue globale des interactions (UML) : ce diagramme fournit une
vue générale des interactions d’écrits dans le diagramme d’activités
 Diagramme de temps (UML) : ce diagramme permet de représenter les états et les
interactions d’objets dans un contexte ou le temps à une forte influence sur le
comportement du système à gérer.

Certains de ce diagrammes sont indépendant, alors que d’autres servent de base

de travail ou bien sont la continuité d’autres diagrammes.
 16

Aujourd’hui UML d’écrit les concepts et le formalisme de ces treize diagrammes

mais ne propose pas de démarche de construction couvrant l’analyse et la conception
d’un système.

Ce qui a pour conséquence par exemple de ne pas disposer d’une vision des
interactions entre les diagrammes.

1.2.2 Présentation du processus unifié UP

Un processus unifié est une méthode générique de développement de

logiciel ; processus UP est construit sur UML (unified Mödling languange).

Les processus unifiés sont le résultat de l’unification, non pas des processus, mais plus
exactement les meilleurs pratiques du développement objet.

Il est :

 Itératif : le logiciel nécessite une compréhension progressive du problème à travers

des raffinements successifs et développer une solution effective de façon
incrémentale par des itérations multiples.
 Centré sur centré sur l’architecture : le choix de l’architecture logicielle est
effectué lors des premières phases de développement du logiciel.la conception des
composants du produit est basée sur ce choix.
 Conduit par les cas d’utilisation : le processus est orienté par les besoins
d’utilisateurs présenté par le cas d’utilisation.
 Piloté par les risques : les causes majeures d’échec d’un projet logiciel doivent
être écartées en priorité.

Les phases et les disciplines du processus unifié

La gestion d’un processus est l’organisée en suivant les phases suivantes :

 La phase d’initialisation conduit à définir la « vision » du projet, sa portée, sa

faisabilité, son business, afin de pouvoir décider au mieux de sa poursuite ou de son
arrêt.
 La phase d’élaboration poursuit trois objectifs principaux en parallèle :
 I ’identifier et d’écrire la majeure partie de besoins d’utilisations ;
 17

 Conduire (et pas seulement d’écrire dans un document) l’architecture de

base du système ;
 Lever les risques majeurs du projet.
 La phase de construction consiste à concevoir et implémenter l’ensemble des
éléments opérationnels (autres que ceux de l’architecture de base).
C’est la phase la plus consommatrice en ressources et en effort.
 En fin la phase de tension permet de faire passer le système informatique des
développeurs à celles des utilisateurs, déploiement.
Chaque phase est elle-même décompose séquentiellement en itérations limitées
dans le temps (entre 2 et 4 semaines).

Le résultat de chacune d’elles est un système testé, intégré et

exécutable. Itérative est fondée sur la croissance et l’affinement successifs d’un
système par les moteurs principaux permettant de converger vers un système
satisfaisant.

Le système croit avec le temps de façon incrémentale, itération, et c’est pourquoi cette
méthode porte également le nom de développement itératif et incrémental

IMPLEMENTATION (ARCHITECTURE LOGICIELLE)

L’implémentation est la finale d’élaboration d’un système informatique

qui permet au matériel, aux logiciels et aux procédures d’entrer en fonction.

C’est le résultat de la conception pour implémenter le système sous forme de

composants, c’est-à-dire de code source, de scripts de binaire, d’exécutable et d’autres
éléments du même type.

L’objectif de l’implémentation de mettre en œuvre les modèles issus de l’analyse et de la

conception.

Cependant, lors de l’implémentation de la solution, plusieurs critères de

choix techniques s’opèrent pour la mise en œuvre de la solution ainsi obtenue ;

- Choix des outils de développement : il s’agit de spécifier le langage de

programmation à utiliser, du SGD sur lequel sera implémenté le modèle physique.
 18

- Choix de l’architecture d’application : il s’agit de spécifier la façon dont seront

organisés et déployés les composants du système à mettre en place.

CHAPITRE II. ANALYSE DE L’EXISTANT

Toute informatisation d’un système d’information doit nécessairement commencer

par une analyse préalable qui est un ensemble d’étude préliminaire qui doit déboucher à
une ébauche des solutions.

C’est une étape au cours de laquelle, il sera question de faire l’examen de ce qui
existe, c’est-à-dire l’étude des processus et des moyens utilisés pour réaliser les
problèmes de la gestion que l’informatique aura envisagé.

L’issue de cette étude, une décision sera prise et elle portera sur les objectifs qui
seront traités par l’application informatique.

1. Présentation de l’existant
1.1 présentation de la location de salle de fête
a) compétences matérielles

La salle auguy ndala,( S .A.N ) service en sigle est une firme immatriculée sa
création remonte au 25 JUIN 2014 son initiateur et propriétaire est un congolais
répondant au nom AUGUY NDALA sise au N 57, avenue de PLAINE Quartier Naviundu
Commune Annexe à Lubumbashi dans la province du Haut-Katanga, en république
démocratique du Congo(RDC).

b) Situation géographique
 19

la salle AUGUY NDALA se trouve au 57, avenue de PLAINE au quarter

naviundu commune annexe dans la ville de Lubumbashi province haut- Katanga, en
république démocratique du Congo.

c) Domaine d’activité

Voici les domaines d’activités dans les quels résident les services
offert :

 la salle de fête
 le guest house
 une terrasse

d) Les servisses

 la salle de fête : garantie une assistance individuelle ou spécialisée aux

propriétaires de biens à louer à son excellente connaissance du marché et sa forte
base de clientèle.
 le guest house :est un type d’hébergement chez l’habitant qui propose des chambre
 une terrasse : est un de vie extérieur ou un espace ouvert qui peut être relie ou non
relie à un bâtiment.
 le restaurant : est un établissement de commerce où l’on sert des plats préparés et
des boissons à consommer sur place, en échange d’un paiement.
 le dépôt de boissons : est un établissement où l’on vend des boissons consommer
sur place ou and hors

e) Les personnels d’encadrement et de gestion

Le personnel de la salle de fête est constitué des professionnels compétents qui

participent à la concrétisation rapide des projets de la salle ; constitué d’argents aux
différents profils, l’équipe de travaille dans un esprit d’intégrité, d’efficacité et de
transparence de satisfaire la clientèle dans ses critères de recherche.

f) Gestion comptable et financière des biens immobiliers

 20

la salle propose la gestion financière et comptable des biens immobiliers à louer

afin d’assurer la bonne application des conventions passées entre les parties
contractantes par la tenue d’une comptabilité permettant : aux clients ou locateurs
d’orienter le choix d’investissement dans les biens adaptés à ses besoins à son mode
de vie sur base de la valeur.

g) ORGANIGRAMME

C’est une représentation schématique des liens et les relations

fonctionnelles, organisation et hiérarchique qui existe entre élément et les individués
d’une organisation.

GERANT

Marketeur Réceptionniste

Coordonnateur
Caissier
 21

Figure de 2-1 : organigramme de salle fête

Source : direction générale de la location de salle de fête

II.3. Modélisation métier

La modélisation du métier vise à mieux connaitre le fonctionnement et les règles

qui

Régissent avec le système organisationnel dans lequel on envisage d’implanter un

nouveau système informatisé. Si l’on souhaite que le système informatique à concevoir
corresponde aux exigences réelles du métier ciblé, il est vital de bien identifier les
objectifs, les priorités, les règles de gestion et les processus clés de l’organisation avant
toute tentative d’informatisation. L’importance que revêt cette activité pour le reste du
projet justifie son positionnement en amont par rapport aux autres activités.

II.3.1. Description textuelle du processus métier

Pour réserver la salle de fête, le processus commence lorsque le client sollicite

le dit service auprès du réceptionniste d’Auguy Ndala, ce dernier vérifie la disponibilité
de la salle de fête demandé, en cas de disponibilité le réceptionniste procède à
l’identification du client en l’enregistrant dans le cahier de service, puis lui autorise d’aller
régler sa facture à la caisse. Arrivé à la caisse, le client verse le montant indiqué sur la
facture, le caissier vérifie la conformité des frais et si cela est conforme il établit un reçu
de paiement en double exemplaire dont l’original est au client comme preuve de
paiement et la copie est envoyée au gérant.
 22

Le gérant ayant accusé réception de la copie du reçu de paiement, autorise la

réservation de la salle sollicité par le client et procède à la mise à jour du planning de
réservation pour préparer la prise de décisions administratives.

A la fin de la journée, le réceptionniste et le caissier sont censés élaborer des

rapports chacun selon ses tâches exécutées au sein de l’établissement, en vue
de permettre au Gérant de suivre de près le déroulement des activités au sein
de Auguy NDALA.

II.3.2. Indentification des intervenants métiers

Dans le cadre de notre étude, les acteurs dans le processus de réservation de

salle de mariage sont les suivants :

N° INTERVENANTS TYPE ROLE

C’est toute personne qui sollicite la

1 Client Acteur métier réservation d’un service chez Park
hôtel.

C’est un agent de l’hôtel qui a pour

2 Réceptionniste Travailleur métier tâche de traiter les demandes de
réservation, faites par les clients.

C’est un agent de l’hôtel chargé

3 Caissier Travailleur métier d’encaisser et de décaisser le
montant perçu.

Il est le gérant de l’hôtel qui a pour rôle

4 Gérant Travailleur métier
de coordonner les activités de l’hôtel.
 23

II.3.4. Diagramme de processus cas d’utilisation

Le diagramme de processus métier, illustre sur un schéma l’ensemble des

acteurs du métier, liés chacun au processus métier qui peut être global ou décomposé
en sous processus selon que la complexité du processus métier.

Dans le cas de l’espèce, le diagramme de processus métier, est le suivant :

Processus de location de salle

Gérant

II.3.5. Diagramme d’activités

Ce diagramme sert à schématiser l’enchainement des activités qui constituent le

processus métier tel qu’il est.

Nous avons opté pour une représentation globale du diagramme d’activités que
voici :
24

Gérant
Gérant
 25

II.3.6. Diagramme des classes du domaine

C’est la description d’un ensemble d’objets ayant une structure, un comportement

et des relations similaires. Elle est généralement représentée par un rectangle ayant
trois compartiments : le nom de la classe, les attributs et les opérations. On peut
simplifier la représentation en ne conservant que le premier compartiment.

Gérant

Salle de fête
 26

II.3.7. Critiques et proposition de solution

II.3.7.1. Critiques

Avant d’aboutir à la proposition des solutions relatives à notre sujet, nous

aimerions donner les points positifs et négatifs rencontrés au sein de l’organisation qui
fait l’objet de cette étude.

- Points positifs du système existant :

• L’harmonie entre employés au sein de l’organisation sur le lieu du travail;

• Les dossiers des clients sont gardés dans l’armoire qui ne peut être ouvert
que par le gérant en charge de la gestion de dites dossiers.

- Points négatifs :

Le problème qui se pose dans l’organisation est celui qui entraine le gaspillage
de temps lors de traitement des dossiers des clients, entre autre :

• Il y a des tâches qui sont effectuées sur les documents manuels dès
l’arrivée du client, le réceptionniste enregistre les informations du client sur
un cahier de service et lorsque ce cahier se rempli, ce dernier est obligé
d’acheter un autre cahier cela entre dans les dépenses inutiles de
l’entreprise.

• Les difficultés pour communiquer entre les postes de l’organisation ; entre

autre la circulation des documents et les traitements des dossiers sur la
gestion de la demande de location de salle.

• Manque d’un suivi automatisé dans leur système d’information étant que la
salle auguy ndala manque un système informatique centralisé.

II.3.7.2. Proposition de la solution nouvelle

A chaque problème correspond toujours une solution. Vu les problèmes

rencontrés dans l’organisation (Auguy NDALA), pour la rendre plus performante, nous
proposons à cet entreprise une mise en œuvre des matériels et logiciels informatiques
capables d’assurer une bonne gestion dans la location de salle.
 27

CHAPITRE III : CONCEPTION DU SYSTEME INFORMATIQUE

III.1. Introduction

Ce chapitre a pour objet de présenter et de documenter de quelle manière la

solution attendue à la fin de cette étude sera conçue. Cette solution est présentée à ce
niveau comme un ensemble d’échelons qui se suivre pour aboutir à un seul but.

La conception du système, permet d’élaborer le plan de la solution informatique,

c’est-à dire déterminer comment le logiciel va réaliser les fonctionnalités préalablement
définies en utilisant les moyens informatiques

Nous allons donc passer par l’analyse informatique afin de reformuler les règles
traditionnelles de façon à ce que le nouveau système soit donc basé sur celles-ci,
ensuite chuter par la conception détaillée.

III.2 Analyse des exigences et spécifications du système informatique

L’entreprise Auguy NDALA souhaite se doter d’un système informatique

performant ou d’un logiciel qui doit gérer le processus de location de salle de fête
(mariage ou la salle évènementielle), et qui lui permettra de faire le suivi de ces
processus efficacement.

Cette partie du travail a pour but de recueillir toutes les contraintes imposées au
futur système informatique.

III.2.1 Spécifications des besoins sous forme d’un cahier de charge

L'analyse de ce sujet nous a permis d'identifier les divers besoins auxquels doit
répondre notre application. Ces besoins dégagés sont classés en deux catégories à
savoir : les besoins fonctionnels et les besoins non fonctionnels.

- Besoins fonctionnels

Les besoins fonctionnels dans un système sont ceux qui se rapportent aux
activités métier des utilisateurs du système d’où l’objectif est de produire un système
adapté aux besoins des utilisateurs pour :
 28

• Permettre de consulter les demandes de location faites par les clients.

• Aider à l’internaute de créer un compte avant toute demande de location.

• Permettre d’organiser le planning de location c’est-à-dire donner un

programme de location (salle occupées et non occupées).

• Payer la facture en ligne.

• Permettre à gérer les clients : ajout, modification, suppression, listage.

• Permettre les tâches de gestion de locations : ajout, modification,

annulation et suppression (communication avec l’entreprise Auguy NDALA
et la centrale de location).

• Permettre de générer des statistiques sur les locations effectuées.

• Permettre au client de suivre l’état de sa demande jusqu’à ce que celle-ci

puisse être traitée.

- Besoins non fonctionnels

Une fois les besoins fonctionnels sont bien définis, les besoins non fonctionnels
doivent être pris en compte tout au long du processus de développement de l’application
à savoir :

• L’application doit offrir un fonctionnement en ligne.

• Ergonomie et convivialité : l’application doit fournir aux différents utilisateurs une

interface (espace des utilisateurs).

• La latence (délai de réponse) doit être raisonnable.

• Portabilité réflexible : l’application doit être portable et multiplateforme, c’est-à-

dire fonctionnelle sur n’importe quelle machine (ordinateurs) et accessible sur
toute sorte de plateforme (Smartphone, tablettes, ordinateur, Mac, etc.).

• Sécurité : l’application doit assurer un niveau de sécurité pour les informations

traitées grâce à l’authentification.

• La gestion de comptes utilisateurs et l’attribution des rôles par un super

utilisateur.
 29

III.2.2. Identification des acteurs

Nous allons maintenant énumérer les acteurs qui vont interagir directement avec
le système informatique qui sera mis en place. L’acteur peut consulter et/ou modifier
directement l’état du système. Les acteurs qui interagissent avec l’application à
concevoir sont les suivant :

- Le client : toute personne qui sollicite une location de la salle après avoir créé
son compte utilisateur.

- Le gérant : l’agent de la salle de location chargé de coordonner l’ensemble

de la gestion de l’entreprise et en particulier les locations des salles.

- L’administrateur système : il est le super utilisateur du système informatique

de l’entreprise qui a la charge de gérer les profils des utilisateurs et leurs mots
de passe soit en créant des nouveaux utilisateurs, soit en supprimant ceux qui
sont hors normes, soit en réinitialisant leurs mots de passe selon le besoin,
etc.

- Le réceptionniste : celui qui gère les clients et traite leurs demandes de

location de salle de fête.

- Le caissier : il est chargé d’enregistrer le paiement des frais de location des

clients et contrôle la caisse de ce dernier.

III.2.3. Diagramme de contexte informatique

A partir des informations obtenues, nous allons modéliser le contexte de notre

application. Ceci va nous permettre dans un premier temps, de définir le rôle de chaque
acteur dans le système, et dans un second temps nous allons présenter notre premier
diagramme qui est le diagramme de contexte, dont le système est considéré comme
une boîte noire :

Le diagramme de contexte informatique consiste à délimiter le périmètre du système

Informatique par rapport à son environnement au sein de l’organisation dont il fait partie

Ce diagramme est donc présenté dans le schéma suivant :

 30

Auguy NDALA

Système de gestion de
location de salle de fête
Auguy Ndala

Gérant

III.2.4. Détermination des cas d’utilisation système

Un cas d’utilisation modélise un service rendu par le système. Il exprime les interactions

acteurs/système et apporte une valeur ajoutée « notable » à l’acteur concerné.

N° CAS D’UTILISATION ACTEURS OPERATIONS

Connexion
1 S’authentifier Utilisateurs
Déconnexion

Ajouter utilisateur
Administrateur
2 Gérer utilisateurs Supprimer utilisateur
système
Modifier utilisateur

Saisir coordonnées

3 Créer compte Client Modifier le profil

Supprimer le compte
 31

Remplir formulaire de demande

4 Passer demande Client Soumettre demande

Modifier demande

Afficher détails service

5 Consulter catalogue Client
Voir tarif

Ajouter la demande

Annuler la demande
6 Traiter la demande Réceptionniste
Valider la demande

Lister demandes

Consulter liste réservation

Vérifier frais
7 Enregistrer paiement Caissier
Créer reçu

Imprimer reçu

Ajouter service

8 Gérer catalogue Directeur Modifier service

Supprimer service

Ajouter réservation
9 Gérer planning Directeur
Supprimer réservation

Saisir frais
10 Régler facture Client
Soumettre paiement
 32

III.2.5. Diagramme des cas d’utilisation système

Il s’agit de la représentation schématique des cas d’utilisation des besoins fonctionnels

et non fonctionnels identifiés à l’étape précédente et ce diagramme se présente comme
suit :

Réglé facture
Traiter
demande
Réceptionniste
« Include »
« Include »
Demande
location Client
Enregi.
Paiement « Include » « Include »
« Extend »

Authentification
Crée compte

Caisse
« Include » « Extend »
Gérer planning « Include »
Consulter
« Include » catalogue

Gérer
catalogue Gérer
Gérant utilisateur

Admin system

III.2.6. Description détaillée des cas d’utilisation

La fiche de description textuelle d’un cas d’utilisation n’est pas normalisée par
UML. Nous préconisons pour notre part la structuration suivante pour chaque cas
d’utilisation :

 Sommaire d’identification (obligatoire), inclut titre, objectif, résumé, dates,

version, responsable, acteurs...
 33

 Description des enchaînements (obligatoire), décrit le scénario nominal,

les enchaînements alternatifs, les enchaînements d’exception, mais aussi
les préconditions, et les post-conditions.

 Description formelle : elle consiste à décrire chaque cas d’utilisation avec

le formalisme UML et cela se schématise sous deux sortes de vues, qui
sont : la vue statique (diagramme des classes participantes) et la vue
dynamique (diagramme de séquence système).

II.2.6.1. Description du cas d’utilisation “ s’authentifier”

- Sommaire d’identification :

o Titre : s’authentifier

o Objectif : permettre aux utilisateurs de se connecter au système afin

d’ouvrir leurs sessions selon leurs privilèges pour utiliser les fonctionnalités
de l’application.

o Acteurs : tous les utilisateurs du système (client, réceptionniste, caissier,

Gérant, admin système).

- Description des enchainements

- Préconditions : système activé

o Scénario nominal : l’utilisateur active le système, le système demande

l’authentification, l’utilisateur fournit un login ainsi que son mot de passe,
cliquer sur connexion, le système vérifie les données saisies, afficher la
session.

o Scénario alternatif : si login ou mot de passe incorrect, le système bloque

l’accès et affiche un message d’erreur mais au cas contraire le système
connecte l’utilisateur à son interface et envoie un message de succès.

o Post conditions : Ouverture de session

- Description formelle par le diagramme de séquence système :

 34

DSS : S’authentifier

Système gestion de
location de salle de
fête

Système gestion de
réservation de la salle
polyvalente SNCC
Utilisateur

Activer système

Saisir mot de passe

Vérifier validité

II.2.6.2. Description du cas d’utilisation “ gérer utilisateurs”

- Sommaire d’identification :
Accès autorisé
o Titre : gérer utilisateur

Accès refusé
 35

o Objectif : permettre à l’administrateur du système gérer les comptes des

autres utilisateurs soit en créant un nouvel utilisateur, soit à en supprimant
un compte inactif, soit en modifiant les coordonnées d’un utilisateur à sa
demande, soit en listant l’ensemble des utilisateurs du système.

o Acteurs : administrateur système

- Description des enchainements

o Préconditions : être authentifié

o Scénario nominal : l’admin s’authentifie, le système lui donne accès à son

interface d’administration, l’admin choisit une action sur son menu
principal, le système affiche une interface correspondant à la demande de
l’admin, l’admin exécute l’action voulue et le système confirme l’exécution
de l’action en envoyant un message de succès si l’action réussit.

o Scénario alternatif : aucun

o Scénario optionnel : si l’action choisie est « ajouter utilisateur », l’admin

complète les coordonnées de connexion de l’utilisateur puis les soumet, le
système confirme l’exécution par un message ; si l’action choisie est «
supprimer utilisateur », l’admin choisi l’utilisateur à supprimer puis clique
sur supprimer, le système confirme la suppression par un message ; si
l’action est « modifier utilisateur » l’admin édite les informations requises et
soumet les modifications au système qui confirme l’exécution par un
message.

o Post conditions : utilisateur ajouté ou utilisateur supprimé ou utilisateur

modifié ou utilisateurs listés.

- Description formelle par le diagramme de séquence système :

 36

Système gestion de
location de salle de
fête

II.2.6.3. Description du cas d’utilisation “ créer compte”

- Sommaire d’identification :

o Titre : créer compte

o Objectif : permettre aux clients de créer leurs comptes client pouvant leur
permettre de passer une demande de service et en faire le suivi en temps
réel.
 37

o Acteurs : client.

- Description des enchainements o Préconditions : système activé o Scénario

nominal : le client active le système, le système s’active, le client clique sur créer
compte, le système lui affiche un formulaire de création, le client rempli ce
formulaire avec ses coordonnées puis le soumet au système, ce dernier vérifie la
validité des données soumises et confirme la création du compte client par un
message de succès et le redirige en même temps sur son interface de menu
principal après avoir connecté automatiquement.

o Scénario alternatif : si les données saisies sont invalides, le système bloque

l’accès et affiche un message d’erreur mais au cas contraire le système
enregistre le compte client et connecte l’utilisateur à son interface tout en
envoyant un message de succès. o Post conditions : Compte client créé

- Description formelle par le diagramme de séquence système :

38

Système gestion de
location de salle de
fête
 39

II.2.6.4. Description du cas d’utilisation “ passer

demande ” - Sommaire d’identification :

o Titre : passer demande

o Objectif : permettre aux clients de solliciter une salle de fête en passant

leurs demandes en ligne.

o Acteurs : client

- Description des enchainements

o Préconditions : être authentifié

o Scénario nominal : le client après s’être authentifié, clique sur nouvelle
demande, le système lui affiche un formulaire de demande vide, le client
rempli le formulaire en indiquant son besoin par rapport à la location puis
soumet les données saisies, le système vérifie la validité des données et
enregistre dans la base de données puis renvoie un message de succès.

o Scénario alternatif : Si les données ne sont pas valides, le système affiche

un message d’erreur mais au cas contraire le système enregistre la
demande et envoie un message de succès.

o Post conditions : demande soumise

- Description formelle par le diagramme de séquence système :

40

Système gestion de
location de salle de fête
Système gestion de
location de salle de fête
 41

II.2.6.5. Description du cas d’utilisation “ consulter catalogue”

- Sommaire d’identification :

o Titre : consulter catalogue

o Objectif : permettre aux clients de consulter le catalogue de différents

services disponibles et leurs détails tarifaires.

o Acteurs : client

- Description des enchainements

o Préconditions : système activé, catalogue disponible.

o Scénario nominal : le client active le système, le système s’active, le client

va sur la page de catalogue, le système lui affiche la liste des services
disponibles sur le catalogue, le client choisit une location et le système lui
fournit les détails sur le tarif de la location.

o Scénario alternatif : aucun.

o Post conditions : catalogue consulté

- Description formelle par le diagramme de séquence système :

 42

Système gestion de
location de salle de fête

II.2.6.6. Description du cas d’utilisation “ traiter demande”

- Sommaire d’identification :

o Titre : traiter demande

o Objectif : permettre au réceptionniste de traiter les demandes de location

de salle de fête qui sont en attente de traitement.
 43

o Acteurs : réceptionniste

- Description des enchainements

o Préconditions : être authentifié, présence d’une demande en attente

o Scénario nominal : le réceptionniste après s’être authentifié, visualise la
liste des demandes en attente, le système lui affiche la liste, le
réceptionniste choisit une demande par identifiant, le système affiche les
détails de la demande correspondante, le réceptionniste vérifie la
disponibilité de location, en cas de disponibilité, il approuve la demande
puis autorise le client à procéder au paiement de la facture liée à sa
demande.

o Scénario alternatif : Si le service demande n’est pas disponible, le

réceptionniste rejette la demande ou la met en attente et dans l’autre cas
la demande est traitée et classée.

o Post conditions : demande traitée et paiement autorisé.

- Description formelle par le diagramme de séquence système :

44

Système gestion
de location de
salle de fête
 45

II.2.6.7. Description du cas d’utilisation “ enregistrer paiement”

- Sommaire d’identification :

o Titre : enregistrer paiement

o Objectif : permettre au caissier d’enregistrer le paiement en établissant un

reçu de paiement.

o Acteurs : caissier (principal)

- Description des enchainements

o Préconditions : être authentifié, présence d’une facture

o Scénario nominal : le caissier après s’être authentifié, le caissier lance la

page de paiements, le système lui en affiche, le caissier vérifie la
conformité du monté verser, si conforme le caissier confirme le paiement
en établissant un reçu de paiement en deux exemplaires.

o Scénario alternatif : Si le montant n’est pas conforme, le caissier rejette le

paiement, le système un message d’échec et au cas contraire, le reçu de
paiement est établi.

o Post conditions : paiement enregistré et reçu établi.

- Description formelle par le diagramme de séquence système :

46

Système gestion de
location de salle de
fête
 47

II.2.6.8. Description du cas d’utilisation “ Gérer catalogue”

- Sommaire d’identification :

o Titre : Gérer catalogue

o Objectif : permettre au directeur de gérer les éléments sur le catalogue en

le mettant à jour.

o Acteurs : Gérant.

- Description des enchainements

o Préconditions : être authentifié

 48

o Scénario nominal : le gérant clique sur catalogue, le système affiche la

page de catalogue, le directeur choisit une option à exécuter, le système
confirme l’exécution de l’action par un message. Scénario optionnel : Si

Système gestion de location

de salle de fête

option « éditer », le système affiche l’élément à modifier, le gérant applique

les ajouter », le gérant saisit les données à ajouter et soumet le formulaire,
le système enregistre les données, si option
 49

II.2.6.9. Description du cas d’utilisation “ Gérer planning”

- Sommaire d’identification :

o Titre : Gérer planning

o Objectif : permettre au directeur de gérer le planning à chaque qu’il y a un

paiement de réservation qui s’effectue.

o Acteurs : Gérant

- Description des enchainements

o Préconditions : être authentifié, nouveau paiement de réservation

o Scénario nominal : le directeur clique sur le planning, le système affiche la
page de planning, le directeur ajouter la nouvelle réservation au planning,
le système enregistre la réservation puis envoie un message de succès.

o Scénario optionnel : Si l’option choisie est « éditer » le gérant met la liste

des locations à jour, si l’option est « Supprimer », le système affiche un
message d’avertissement, le directeur confirme la suppression, le système
applique la suppression.

o Post conditions : planning complété et mis à jour.

- Description formelle par le diagramme de séquence système :

50

Système gestion de
location de salle de fête
 51

II.2.6.10. Description du cas d’utilisation “ Régler facture demande”

Système gestion de
location de salle de
fête

III.3. Conception détaillée du système informatique

La conception détaillée du système informatique considère le système non plus comme

Une boite noire mais plutôt, comme une structure vue de l’intérieur sous forme d’un
ensemble d’objets qui interagissent pour produire un résultat concret. C’est ici que nous
 52

allons transformer les besoins des utilisateurs qui sont des cas d’utilisation, en
fonctionnalités informatiques.

cas d’utilisation Risque Priorité Itération

Passer demande bas moyen 8

Traiter demande haut moyen 4

Enregistrer paiement haut moyen 6

Gérer catalogue moyen bas 9

Consulter catalogue bas bas 10

S’authentifier haut haut 1

Gérer utilisateurs haut haut 2

Gérer planning moyen Haut 3

Créer compte bas moyen 7

Régler facture moyen haut 5

III.3.1. Diagrammes de classes participantes de conception

Les diagrammes de classes participantes dans la conception, sont particulièrement

Importants car ils font la jonction entre les cas d’utilisation, la maquette et les
diagrammes de conception logicielle (diagrammes d’interaction et diagrammes de
classes).

Les trois types de classes utilisées dans le diagramme de classes participantes et

 53

Proposées par Jacobson sont les dialogues (écran d’échange), les entités (données) et
les contrôles

(Logique applicative). Principe à suivre et à respecter pour l’élaboration des classes

participantes de conception :

- Les acteurs ne peuvent interagir (envoyer des messages) qu’avec les dialogues.

- Les dialogues peuvent interagir avec les contrôles.

- Les contrôles peuvent interagir avec les dialogues, les entités, ou d’autres
contrôles.

- Les entités ne peuvent interagir qu’entre elles.

III.3.1.1. Diagramme de classes participantes cas d’utilisation “S’authentifier »

 54

III.3.1.2. Diagramme de classes participantes cas d’utilisation “gérer utilisateurs »

III.3.1.3. Diagramme de classes participantes cas d’utilisation “Gérer planning »

Gérant
 55

III.3.1.4. Diagramme de classes participantes cas d’utilisation “Traiter demande »

III.3.1.5. Diagramme de classes participantes cas d’utilisation « Régler facture »

 56

III.3.1.6. Diagramme de classes participantes cas d’utilisation “ Enregistrer

paiement »

III.3.1.7. Diagramme de classes participantes cas d’utilisation “Créer compte »

 57

III.3.1.8. Diagramme de classes participantes cas d’utilisation “Passer demande »

III.3.2. Diagrammes de séquences détaillées

Ces diagrammes servent à décrire un cas d’utilisation de manière détaillée afin de

montrer

Toutes les interactions qui s’effectuent entre les classes qui participent à la réalisation
d’un cas d’utilisation.
 58

III.3.2.1. Diagramme de séquence détaillée cas d’utilisation « s’authentifier »

59
 60

III.3.2.2. Diagramme de séquence détaillée cas d’utilisation « gérer utilisateurs »

 61

III.3.2.3. Diagramme de séquence détaillée cas d’utilisation « Gérer planning »

Gérant
 62

III.3.2.6. Diagramme de séquence détaillée cas d’utilisation « créer compte »

 63

III.3.2.7. Diagramme de séquence détaillée cas d’utilisation « passer demande »

 64

III.3.3. Diagramme de classes de conception

Le diagramme de classes de conception permet de déterminer les objets/classes qui

vont

servir pour la sauvegarde des données persistantes.

Gérant
 65

III.4. Architectures du système informatique

En génie logiciel, une architecture est considérée comme un squelette d’un

système informatique qui présente l’ensemble d’éléments que va constituer le dit
système.

Les architectures permettent de donner une vue d’ensemble sur les logiciels et
matériels qui seront utilisés lors de l’implémentation de la solution attendues à la fin
d’une étude de conception d’un système.

III.4.1. Choix de l’architecture de référence

Nous portons notre choix sur le type d’architecture Application client web léger.
Nous justifions ce choix par le fait qu’une application client web léger permet de rendre
simple la manière de déployer le système informatique dans son environnement.
L’ensemble des données de persistance et la logique applicative des toutes les
fonctionnalités sont conservées sur un serveur distant (hébergeur web) et les utilisateurs
peuvent y accéder grâce leurs navigateurs web de versions récentes d’où les postes
utilisateurs sont légers dans le traitement des données indispensable à la gestion et à la
prise des décisions adéquates. III.4.2. Choix du style d’architecture en couches

En rapport avec ce style d’architecture, nous avons fait recours au style

d’architecture en trois couches. Ces trois couches logicielles sont les suivantes :

- La couche de présentation : elle restitue les données à l’utilisateur, et

transformer ses actions en évènements de l’application.

- La couche applicative : elle représente les objets de contrôle et pilote

les règles de l’application, y-compris les règles d’échanges entre
fonctionnalités de l’application.

- La couche de persistance : représente les objets métier, implémente

leurs règles de gestion, restitue les représentations métier à partir du
moyen de stockage, et assure la persistance des données.

En UML, les couches logicielles correspondent à des packages et sont

stéréotypées par la notation « Layer »
 66

CHAPITRE IV : IMPLEMENTATI ON DE LA SOLUTION

IV.1. INTRODUCTION
Dans le cadre de la réalisation de notre application mobile de vente de farine,
cette section se concentre sur l’implémentation de la solution. Nous avons
opté pour la plateforme Adalo pour faciliter la création et la gestion de notre
application sans nécessiter de compétences poussées en programmation.

IV.2. Choix des Outils

Choix du Langage de Programmation

Le choix des outils est critique pour la réussite de notre projet. Nous avons
sélectionné :

 Adalo : Une plateforme de développement sans code qui permet de

concevoir des applications mobiles de manière intuitive.
 UML (Unified Modeling Language) : Pour la modélisation des processus et
des structures de notre application.

Choix du Langage de Programmation

Étant donné que nous utilisons Adalo, qui fonctionne sur une approche sans
code, nous ne recourons pas à un langage de programmation traditionnel.
Cependant, pour l’intégration d’éventuels modules personnalisés, nous
pourrions envisager l’utilisation d’API REST pour enrichir les fonctionnalités.

Nous avons intégré plusieurs outils et bibliothèques pour améliorer les

fonctionnalités de notre application :

 Stripe : Pour gérer les paiements en ligne de manière sécurisée.

 Firebase : Pour l’authentification des utilisateurs et le stockage des
données en temps réel.
 Zapier : Pour automatiser les tâches entre l’application et les autres
outils.
 67

1. CHOIX DU SYSTEME DE GESTION DE BASE DE DONNEES

Firebase : Adalo utilise Firebase comme base de données pour stocker les
données des applications créées sur sa plateforme de développement sans
code.

Firebase n’est pas un SGBD (Système de Gestion de Base de Données)

traditionnel. C’est une plateforme de développement d’applications mobiles
et web proposée par Google, offrant des services tels que l’authentification
des utilisateurs, le stockage de fichiers, les bases de données en temps réel
et bien d’autres fonctionnalités pour faciliter le développement
d’applications.

III.5. Diagramme de déploiement

Le diagramme de déploiement est la représentation de la manière à laquelle
les composants logiciels seront implantés sur les composants matériels au
système informatique. Ce diagramme sert aussi à schématiser la
matérialisation de l’architecture physique d’un système informatique.
68
69
70
71
 72

CONCLUSION

Grande a été notre de rédiger ce mémoire de fin d’étude qui touche à sa

fin, et grande est notre satisfaction d’avoir apporté une modeste solution
informatique par le développement d’une application web de gestion de
location de salle de fête.

En fait, l’objet de ce travail était de créer une application web de gestion

de location de salle de fête, lequel système permettra de résoudre des
difficultés rencontré que nous avons évoqué dans la problématique.

A cette problématique nous avons donnés comme hypothèse la mise

en place d’une application informatique pouvant faciliter :

L’accès à distance aux catalogues de location de salle de fête

L’enregistrement des nouveaux clients

La sauvegarde efficace à l’aide d’une base de données toutes les

informations des locations

Et toute amélioration

Pour la compréhension du système, nous, nous sommes servis de la

méthode analyse basées sur le langage de méthode UML en utilisant le
processus de développement logiciel UP.

Notre travail a été subdivisé en quatre chapitres qui sont :

Cadre conceptuel et considération théorique : il été question dans ce

premier chapitre de définir les grands concepts intervenant dans la
réalisation de la modélisation et de notre application, des concepts de
persistance de données, le concept du langage de programmation et de
processus de développement de logiciel.

Analyse du métier : dans ce deuxième chapitre il été question de

présenter la structure générale système existant.
 73

Analyse et conception du système : dans ce troisième chapitre il été

question de résumer les parties de notre application à travers la
méthodologie en UP et la modélisation par UML à l’aide des différents
diagrammes.

Réalisation du nouveau du système : à travers ce quatrième chapitre et

dernier chapitre nous avons ainsi implémenté (concrétiser) le système et le
mettre en place pour rendre accessible aux utilisateurs.

Et nous avons préconisé le déploiement de l’application sur une architecture

ou nous aurons un serveur sur lequel sera déployé l’application, une autre
sur le quel sera installer le SGBD ; les utilisateurs pourrons accéder à
l’application via le téléphone portable.

Ainsi donc ce travail reste soumis à des perpétuelles améliorations.

Nous espérons qu’il permettra de répondre aux questions qu’on pourrait se

penchant sur ce sujet et qu’il ouvrira d’autres voies de recherche.

En conclusion, ce travail est une forme de solution aux problèmes au sein de

la salle IM et MO résolution, c’est-à-dire que le résultat obtenu à travers cette
solution web, à la faciliter l’enregistrement des nouveau des clients, la
conservation des informations et la production des preuves pour le paiement
et la sécurité des données.
 74

BIBLIOGRAPHIE
1. OUVRAGE
 J-P Rosen, pensées, proverbe et situation, inédit, P.2
 Pascal Roque, UML2 par la pratique étude et exercices corrigé, Eytolles
 Christian SOUTOU, UML2 pour les bases de données,éd Eytolles paris, 2017, P.103
 Joseph G et David G UML2, analyse et conception mise en œuvre guidée étude de cas, paris
Dupond 2008
 Gilles Roy, Conception d’une base de données avec UML, pu Québee, 2009, P.25
 Pascal Roques et Franck Vallée, UML2 en action, éd Eytolles
 Philippe Rigaud, conception d’une base de données, inédit
 Conception et langage des bases de données relationnelles, IUTR de Nice-Cours SGBDI,
département informatique, P.4
 Maleleine Grawtz , méthode de recherche en science sociaux

2. Travail de fin d’études

 KIZITO SIKAKULYA Jonson qui a parlé de « la conception d’un logiciel multiplateforme
pour la facture d’un restaurant »
 MACTAR CAMARA a parlé de «la conception et implémentation d’une Application web
de Gestion des Tickets et accès au Restaurant »
3. DICTIONNAIRE ET ENCYCLOPEDIES
 Dictionnaire français la Rousse
 Dictionnaire français le grand Robert
 Dicos Encarta 2009
 Dictionnaire statistique Dodge 2017
4. SITES INTERNET
 https://fr . wikipedia.org/ wiki/système_d_Information
 www.google.cd/le _langage_UML, V8.1.1.1
 www.bootstrap.com
 www.google.fr/Free_informayion_systèmes_for_management_application
 www.bookboon.com
 www.aforge.com
 www.php.com
 www.mysql.com
 75

 https://www.dictionnaire-juridique.com/definition/ministre-public.php

Table des matières

Epigraphe.............................................................................................................................................

DEDICACES.......................................................................................................................................

REMERCIEMENT.............................................................................................................................

LISTE DES ABREVIATIONS, SINLES ET SYMBOLES............................................................

RESUMER..........................................................................................................................................

INTRODUCTION................................................................................................................................

1. PRESENTATION DU SUJET................................................................................................

2. ETAT DE LA QUESTION.......................................................................................................

3. CHOIX ET INTERET DU SUJET..........................................................................................

3.1. CHOIX DU SUJET...............................................................................................................

3.2. INTERET DU SUJET..........................................................................................................

4. PROBLEMATIQUE.................................................................................................................

5. HYPOTESE..............................................................................................................................

6. METHODE ET TECHNIQUES..............................................................................................

6.1. METHODE............................................................................................................................

6.2. TECHNIQUE.........................................................................................................................

7. DELIMITETION DU SUJET...................................................................................................

8. SUBDIVISION DU TRAVAIL.................................................................................................

CHAPITRE I. CADRE CONCEPTUEL ET CONSIDERATION THEORIQUE..........................

1. DEFINITIONS DES CONCEPTS.............................................................................................

1.1CONCEPTES DU DOMAINE D’ETUDE...............................................................................

1.2. CONCEPTION DU DOMAINE INFOMATIQUE.................................................................

 76

CHAPITRE II. ANALYSE DE L’EXISTANT..................................................................................

II.3. Modélisation métier...............................................................................................................

II.3.1. Description textuelle du processus métier.................................................................

II.3.2. Indentification des intervenants métiers.....................................................................

II.3.4. Diagramme de processus cas d’utilisation................................................................

II.3.5. Diagramme d’activités...................................................................................................

II.3.6. Diagramme des classes du domaine.........................................................................

II.3.7. Critiques et proposition de solution.............................................................................

CHAPITRE III : CONCEPTION DU SYSTEME INFORMATIQUE...........................................

III.1. Introduction...........................................................................................................................

III.2 Analyse des exigences et spécifications du système informatique..............................

III.2.1 Spécifications des besoins sous forme d’un cahier de charge..............................

- Besoins fonctionnels..............................................................................................................

- Besoins non fonctionnels......................................................................................................

III.3. Conception détaillée du système informatique...............................................................

III.3.1. Diagrammes de classes participantes de conception............................................

III.3.2. Diagrammes de séquences détaillées......................................................................

III.3.3. Diagramme de classes de conception......................................................................

III.4. Architectures du système informatique............................................................................

III.4.1. Choix de l’architecture de référence..........................................................................

III.4.2. Choix du style d’architecture en couches.................................................................

CHAPITRE IV : IMPLEMENTATI ON DE LA SOLUTION...........................................................

IV.1. INTRODUCTION..............................................................................................................

IV.2. Choix des Outils..............................................................................................................

1. CHOIX DU SYSTEME DE GESTION DE BASE DE DONNEES.................................

 77

III.5. Diagramme de déploiement....................................................................................................

CONCLUSION..................................................................................................................................

BIBLIOGRAPHIE..............................................................................................................................

1. OUVRAGE..............................................................................................................................

2. Travail de fin d’études..............................................................................................................

3. DICTIONNAIRE ET ENCYCLOPEDIES..............................................................................

4. SITES INTERNET...................................................................................................................