~I~

EPIGRAPHE

« Les affectations sont faites pour la

performance de l’entreprise. »

De Griffo/ Evene.fr-Novembre 2006

MUKONGA TSHAONA Elie

 ~ II ~

DEDICACE

À tous les chercheurs scientifiques dans le domaine d’analyse et programmation.

MUKONGA TSHAONA Elie

 ~ III ~

REMERCIEMENTS

La réussite de ce travail n'aurait été possible sans le soutien de plusieurs

personnes. C'est un réel plaisir pour nous d'être reconnaissant à tous ceux qui ont contribués
de près ou de loin à la rédaction de ce travail :
Pour leurs contributions et encouragements, nous exprimons très sincèrement
notre reconnaissance t nos remerciements.
A notre créateur Dieu Tout Puissant par son fils bien aimé Jésus-Christ, qui nous à
protégés durant tout le parcours de nos études et qui nous a donné la vie, que sa bénédiction
règne pour le siècle des siècles.
Que l’assistant Grâce MILAMBO trouve ici l’expression de notre profonde
gratitude pour avoir accepté la direction de ce travail.
Aux autorités académiques de (l’ISES), informatique et autres sciences.
Au corps professoral de l'option informatique pour leur enseignements consentis et
riches;
A vous cher père MUJINGA DITEND SAMY et mère TSHUMBA BIBICHE pour
tous vos soutiens matériels, financiers et spirituels à mon égard.
A mes amis et condisciples de la promotion.
A présent toutes les organisations sont intéressées par cet outil, pour assouplir
leurs gestions. D’où, c’est avec ce même moyen de traitement des informations que nous
allons réaliser une application web de réservation de chambre.

MUKONGA TSHAONA Elie

 ~ IV ~

LISTE DES ABREVIATIONS

UML : Unified Modèle Langage.

UP : Unified Process.
SGBD : Système de Gestion des Bases de Données.
HTML: Hyper Text Markup Langage
WWW: Word Wide Web
CSS : Cascading Style Sheets
LMD : Langage de Markup de Donnée
LDD : Langage de Description de Donnée
SQL: Structured Query Langage
MySQL: My Structured Query Langage
HTTP : HyperText Préprocesseur
PHP : HyperText Préprocesseur
FTP : File Transfer Protocol
UI : User Interface
TCP : Transfer Control Protocol
IP : Internet Protocole
SGBDR : Système de Gestion de Base de Données Relationnelle
 ~1~

INTRODUCTION GENERALE

I.0 PRESENTATION DU SUJET

Aujourd’hui l’évolution du monde scientifique nécessite une utilisation

rationnelle de l’informatique. Dans le temps, le traitement, la gestion et le stockage des
informations s’effectuaient traditionnellement donc manuellement. Ce qui constituait une
perte de temps vue la concurrence sur le marché et l’employeur était buter à un problème
sérieux de bénéfice. Vue l’ampleur et l’expansion de la technologie, les sociétés et
organisations ont opté, pour la sécurité et l’optimisation des informations, le système
informatique.
L’expression informatique de gestion est à comprendre comme informatique
appliquée à la gestion c’est-à-dire la gestion est un domaine d’application, elle est centrée sur
la notion de système d’information organisationnel (conception des logiciels de gestion
dédiées). Le système est définit comme, l’ensemble d’éléments (personnels, matériels,
logiciels…) permettant d’acquérir, traiter, mémoriser et communiquer des informations. 1.
Remarquons que leurs tâches subsistent encore tels qu’il faut porter attention
et y apporter des solutions nouvelles pour la modélisation et le développement des bases
de données. Grâce à la technologie et la mise en place de ladite application, l’organisation de
l'hôtel du Golf arrivera à bien gérer ses tâches en rapport avec la réservation de chambre
pour mieux gérer ses clients.
Ainsi notre sujet est intitulé : « conception et réalisation d’une application
web de réservation de chambre ; « cas de l'hôtel du Golf »

I.1 PROBLEMATIQUE

Selon Emile Benveniste (de par la lecture compte rendu de la dernières leçons-
collèges de France « 1968-1969 »par Chloé laplantine), les questions posées se transforment
en “problèmes” si elles constituent ce que l’on nomme une problématique. Mais cela ne se
résume pas seulement ainsi. Il y a également une dimension de “l’inachevé” qui inclut le fait
que cette grande question – pour lui : le langage – n’a pas et n’aura jamais de réponse
définitive. Il nous faut donc construire une méthode qui va être jugé aux solutions qu’elle va

1
Www. Wikipedia.com
 ~2~

proposer. Car si on raisonne uniquement sur des conclusions déjà acquises, on n’apprend rien
de nouveau et le travail pourrait s’avérer stérile.
Selon Michel Beaud (1999) « l’ensemble construit autour de la question
principale ». Mais chaque question ne constitue pas une problématique ; on nous précise alors
que la question doit être pertinente.
Nous définition la problématique comme étant un ensemble des questions
scientifiques à résoudre pour espérer y proposer une solution a priori sous l’hypothèse 2,
lors de notre de passage à l 'hôtel du Golf qui fait l’objet de notre étude, nous avons relevé le
rôle que joue ce dernier pour la réservation de chambre. Nous avons constaté que dans son
état actuel, la gestion de réservation de chambre pose problème.
De ce fait nous avons que les agents avaient des difficultés à accéder aux
informations antérieurs relatives à la chambre ; ils traitent manuel des informations
importantes cadrant avec la gestion de l 'hôtel, ce qui engendre une masse de farde de papiers
risque de perdre des documents important ; difficile à donner l’historique d’un client qui a
occupé la chambre plusieurs fois, question d’appliquer une réduction des frais ; pertes de
temps considérable lors de la recherche des informations ; parfois l’attribution de la chambre
pose problème du fait que certains clients portent l’identité de même nature.
Suite aux différents difficultés rencontre a l’hôtel, nous nous posons les
questions suivants ;
 Quelles seront les différant besoin matériel, logiciel et concept nécessaire à
l’aboutissement du travail ?
 Qu’est-ce que sait l’hôtel du golf ?
 Que faut-il faire pour concevoir notre système d’information ?
 N Comment implémenter notre application?

Telles sont des questions auxquelles la présente étude se propose de donner des
éléments des réponses : mais quelles en sont les hypothèses ?

I.2 HYPOTHESE

Francis Bacon, baron de Vérulam, vicomte de Saint-Alban défini l’hypothèse

comme étant une proposition énoncée en vue d’expliquer un phénomène, admise à titre
provisoire et destinée à être soumise à une vérification par sa confrontation (expérimentale,
observationnelle) avec le réel. Le chercheur fait une hypothèse lorsqu’il suppose et imagine
par avance le résultat qu’il cherche.
2
Jargon informatique
 ~3~

Selon Emil Simard (dans un article de la revue Laval théologique et

philosophique ; volume 3, numéro 1 de 1947) c’est des procédés par lesquels se découvre la
vérité qui devait être fondée sur un examen des vérités qui ont été découvertes. La maxime
ainsi énoncée paraît assez évidente: pourtant, elle n’a été, jusqu’à ce jour, que bien rarement
suivie.
Nous pouvons aussi dire que c’est la problématique qui conduit à la
formulation d’hypothèses de recherche. L’hypothèse est en effet une réponse provisoire à la
question préalablement posée. Elle tend à émettre une relation entre des faits significatifs et
permet de les interpréter.
Pour mettre en place notre systéme nous devront d’abord et avant tous
déterminer les besoins primaire pour l’informatise a l’aide d’un logiciel et un ou plusieurs
langages de programmation, déterminer le milieu et le besoin qu’il vient remplir
Pour les besoins logiciel et matériels plusieurs solutions s’offre à nous, mais
avec cette myriade d’options il serait sage de ne pas trop se dispersais et se limiter à un
logiciel fait sur la programmation de types web et un logiciel qui permettre de tester géré ou
mettre en ligne notre bibliothèque et nous ferons bien sûr recours à un hébergeur pour rendre
le site accessible à distance.
Pour arriver a réalisé un bon système d’information, nous allons commencer
par étudié le système existant, modélisé ses processus en analysant les besoins et en décrivant
les données puis passée à la programmation et une base des données réalisé avec MySQL,
persistante qui faciliterait l’accès aux informations et évité toute forme de redondance.
L’application réaliser sera à mesure d’attribuer à chaque client qui sollicite la salle un numéro
question de constater toutes ces occupations et faire de recherche des informations relatives de
la chambre parmi tant d’autre.
I.3 ETAT DE LA QUESTION

L’état de la question est une transition sinéquanone dans la recherche

scientifique, en tant que chercheur nous devront faire preuve à l’originalité et faire une
démarcation nette entre nos propres idées et celles déjà diffusées par nos prédécesseurs,
En effet une multitude de littératures a déjà vu jour bien avant nous sur les
processus de réservation des salles sous différents angles, de ce fait nous ne sommes pas le
premier à aborder un tel sujet,
Pour cela nous citons quelques sujets :
 ~4~

Gabriel Donia, de l’université protestant dans son mémoire intitulé « mise en

place d’une application web pour la réservation des billets d’avion à une agence »,
l’auteur met à la disposition une application web pour la réservation des billets d’avions à une
agence, afin d’évité le double enregistrement des billets. L’auteur avait rencontré comme
problèmes, le manque d’un bon suivit des billets (confusion des numéros, pertes des billets
par manque de bon logiciels de stockage de billets et un bon endroit pour les archiver, par
exemple la base de données.
Gracia KABULU de l’université de KINSHASA dans son mémoire
intitulé « conception et réalisation d’une application web pour la réservation en ligne des
chambres » l’auteur met en place une application web pour l’amélioration des réalisations
existants déjà entre l’hôtel OKT et ses clients d’une part et d’autre part, les hâtelets ses futurs
clients à travers la mise en place de ce site. L’auteur avait rencontré comme problèmes :
 Attribution des chambres aux clients créer des confusions par manque d’un bon suivi,
pour savoir les chambres libres et non libres ainsi que les documents mal entretenus.
 Le problème fréquent est que deux clients pouvaient avoir le même numéro de la
chambre, cet aspect perturbe l’ordre et crée un désordre dans la gestion.
Quant à nous dans le même ordre d’idée, nous vivons la même solution que les
auteurs cité précédemment, celle de mettre à la disposition une application web de
réservation de chambre d'hôtel avec comme objectif d’améliore le système de gestion de
l'hôtel, par l’ajout des requetés qui n’ont pas été évoquées tel que : faire la statistique
périodique de la réservation d’une chambre afin d’éviter le double enregistrement de la date,
sous format particulier qui pourrait offrir une souplesse en lecture et écriture tout en assurant
la non volatilité de ces informations.
I.IV. CHOIX ET INTERET DU SUJET

a. CHOIX
En effet dans tous travails scientifiques, parmi les premiers actes que l'on pose
dans le processus de toute recherche scientifique, le choix du sujet en fait partie. Ceci
président la détermination d’un seul procédé pour le thème d’investigation.

Le choix du sujet a était définir des différentes manier par plusieurs auteur,
dont l’un d’eux est :

DIDIER VIREECK qui est écrivain, dans Ame nature il a publié en 2011 que :
Le choix d'un sujet est le point crucial de tout écrit, et il l'est plus encore quand cet écrit est
 ~5~

destiné à un livre. Le sujet sera ensuite traité selon un angle. Il peut paraître saugrenu à qui
pense savoir ce qu'il va écrire de travailler le choix du sujet, c'est pourtant déterminant. Trop
souvent, l'écriture flotte et la structure se dilue parce que l'auteur ne sait plus de quoi il parle.
Il mélange plusieurs sujets ou, plus fréquemment, plusieurs angles. 3

Dans un article Hugues Carpentier-Delattre datant 15. Octobre 2022, l'intérêt

du sujet : montrez en quoi est-ce important de traiter votre sujet. Pourquoi l'étudiez-vous
aujourd'hui ? Quel est le point de départ de votre réflexion ? La polymorphie du sujet : votre
sujet revête des dimensions multiples (économiques, sociologiques, financières, politiques,
psychologiques…).
En vue d’opter notre sujet selon une préférence, disons suite à de
nombreuses observations et visites effectuées dans cette enceinte leur gestion a pu retenir
notre attention. Par curiosité nous nous sommes lancés dans ce domaine pour apporter notre
degré des connaissances.

b. INTERET DU SUJET

L’INTERET PERSONNEL : sur le plan personnel, ce travail est pour nous

une occasion de mettre en pratique les connaissances acquises durant les 3 ans d’étude
universitaire pour concilier la théorie à la pratique et d’apporter notre contribution à la
résolution d’un des problèmes à l'hôtel du golf de Likasi. Ce dernier a des objectifs
primordiaux et majeurs parmi lesquels la pratique de l’information en fait partie.
Raison pour laquelle nous nous sommes intéressés à l’étude d’une création d’une base de
données auquel nous tenons à proposer une solution
L’INTERET SCIENTIFIQUE : nous pensons que d’autres chercheurs
intéressés par l’informatique, liront les pages de ce travail et ils auront quelques éléments
essentiels par rapport au thème qui est la réservation de chambre.
L’INTERET SOCIAL : l’intérêt social qui motive notre recherche tient du
faite que, Nous ambitionnons à l’issu de notre étude, mettre à la disposition de l'hôtel du
golf des outils capables de fournir à temps réel et en tout lieu indépendamment du service
régional. Cela ferait économiser à coup sûr aux usagers du temps, de l’énergie.

I.V METHODES ET TECHNIQUE

a. Méthodes

ame-nature.com/index.php/savoir écrire
3
 ~6~

Selon M. GRAWITZ (Méthodes des sciences sociales, 4ème Ed. Dalloz, Paris,
1974) la méthodologie est un ensemble des opérations par lesquelles une discipline cherche à
atteindre la vérité qu’elle poursuit, la démontre et la vérifie, elle se subdivise en méthodes et
techniques. Comme méthode, nous avons recouru à la méthode historique, à la méthode
comparative, et la méthode descriptive. Et les techniques d’analyse documentaire, l’interview,
l’observation et l’échantillonnage nous ont servi en vue de traiter et interpréter les données.
Par ailleurs Rita Leininger de l’International Process & Industrie Consult SA à
Munich la définit comme étant la description et spécification de la manière dont une tâche est
exécutée par une personne.
Une méthode est un ensemble d’opérations intellectuelles par lesquelles une
discipline Cherche à étudier les vérités qu’elle poursuit, les démontrent et les vérifient.
En effet dans se dit travail nous aurons à utiliser la méthode UP avec UML qui
se définis comme une méthode générique de développement de logiciel et UML (Langage de
Modélisation Unifié) est une notation permettant de modéliser un problème de façon standard,
c’est une programmation orientée objet consiste à modéliser informatiquement un ensemble
des éléments d'une partie du monde réel (que l'on appelle domaine) en un ensemble d'entités
informatiques. C’est ainsi nous aurons utilisé les diagrammes suivants : le diagramme de cas
d’utilisation nous permettra de représenter les besoins des étudiant et du système ou les
dialogues entre l’étudiant et l’application, le diagramme de séquence système nous permettra
de faire l’Interaction entre les objets et de spécifier l'ordonnancement temporel des
interactions entre les objets, de diagramme de séquence de conception il définit les cas
d’utilisation réalisés sous forme de collaborations entre les sous systèmes des classes et les
interfaces, le diagramme de classe de conception nous aidera à représenter l’ensemble de
composants connectés entre eux par assemblage, diagramme de déploiement et de composant
du système d’information consistera à représenter les relation entre le logiciel et le matériel.

b. Techniques

La technique étant un moyen qui permet d’acquérir et de traiter les

données dont on a besoin pour comprendre et expliquer un sujet donné. Dans le cas du
présent travail, nous avons recouru aux technique suivantes ;
L’observation : elle nous a permis de descendre sur terrain afin de ressortir
et palper les réalités quotidiennes ainsi que, l’atmosphère qui règne au sein de la l'hôtel
du golf.
 ~7~

L’observation documentaire : cette technique, nous a permis de lire

certains documents et ouvrages qui nous ont offerts une connaissance sur notre Object
d’étude, par ailleurs elles nous ont permis aussi d’étudier et d’analyser les documents
pour arriver à déterminer différentes informations portées sur ces derniers.
L’interview : elle a permis d’organiser un rapport ou communication
verbale afin de recueillir certaines informations concernant notre travail.

I.VI DELIMINATION DU SUJET

En effet, tout chercheur dans n’importe quelle étude ou il s’engage, doit être
capable de circonscrire le domaine où s’étend ses investigations si non, son discours ne
risquent d’être difficile et de perdre tout intérêt ainsi que notre travail sera délimité dans
le temps et dans l’espace.
Dans l’espace : notre recherche porte sur la réservation de chambre à l'hôtel
du golf sise sur l’avenue de Likasi, dans le temps : les données récoltés qui nous ont
servi dans cette étude, nous les avons collectées au cours de l’année Académique
2022-2023 et estimons que l’application proposée sera utilisée aussi longtemps que le
système de gestion de réservation de chambre actuelle demeurera.

I.VII. SUBDISION DU TRAVAIL

Pour présenter notre travail et le domaine dans lequel il m’inscrit, nous

avons retenu pour ce mémoire une organisation en quatre chapitres outre l’introduction
générale et la conclusion générale.
CHAPITRE PREMIER : état de l’art : Ce chapitre consiste à la description
de la méthode et des concepts liés au système d’information.
CHAPITRE DEUXIEME : l’analyse de l’architecture métier : Ce chapitre
consiste à présenter notre domaine d’étude et d’analyser son système d’information de gestion
de réservation de la salle.
CHAPITRE TROISIEME : conception détaillée du système informatique :
Dans ce chapitre nous allons modéliser le nouveau système d’information à l’aide de la
méthode UP.
 ~8~

CHAPITRE QUATRIEME : l’architecture technique et implémentation:

Dans ce chapitre il sera question de matérialiser notre application qui est solution de notre
travail.

CHAPITRE PREMIER : ETAT DE L’ART

I.1. INTRODUCTION
 ~9~

Pour la meilleure compréhension du présent travail et dans le souci scientifique, que le

lecteur soit fixé sur le sens de conception pour lui permettre de mieux comprendre son
contenu. Ceci est le point autour duquel le présent chapitre tournera, il porte deux points la
définition des concepts informatique et du domaine dans le cadre de la présentation d’un
système de gestion informatique et présentation de la méthode d’analyse à utiliser ainsi que le
langage de programmation.

1.1 DEFINITIONS DES CONCEPTS (CONCEPTS DE L’INFORMATION ET DU

DOMAINE D’APPLICATION

La conception : est le travail professionnel de l’informatique consistant à

décrire de façon non ambiguë le fonctionnement futur d’un système enfin de le réalisé
facilement.4
La réalisation : C’est une création de quelque chose de cohérent en y
consacrant du temps, de l’intelligence et du savoir-faire.5
L’application : c’est un programme ou un ensemble des programmes destinés
à aider l’utilisateur pour effectuer le traitement d’une tache précise ou un domaine délimité
pour le traitement duquel est écrit un programme.6
La réservation : Est l’action e réserver une place, lieu de transport,
emplacement sur un navire…7, etc.
Une application Web
Est Un logiciel applicatif hébergé par un serveur et accessible par le biais du navigateur web. 8
Une chambre : Est un lieu prévu pour accueillir des personnes désirant ou
sollicitant le repos ou passer nuit9, etc.
Un système : Un système, est un ensemble d’élément en interaction les uns
avec les autres c’est-à-dire un ensemble d’élément identification dans une autre chose ;
un environnement pour quelques chose : une finalité ou projet ou encore objectif qui
fait quelque chose : activité, fonctionnement quelque chose : une structure , une forme
stable qui se transforme : évolution dans le temps du système ressorts10.

4
Dictionnaires et recueils de correspondence
5
A. collongues & all, ”cour de méthode de conception”, boras, paris, 1986
6
Dictionnaires et recueils de correspondance
7
Https //fr.m.Wikipédia.org, jeudi 06/07/2023
8
Https //fr.m.Wikipédia.org, jeudi 06/07/2023
9
Https //fr.m.Wikipédia.org, vendredi 06/07/2023
10
www.wikipédia.fr
 ~ 10 ~

Un acteur : est un être humain ou une machine , qui crée , manipule ,

transforme les informations ou qui sollicite par la présence ou la valeur de certaines
informations c’est un utilisateur du système.
Le processus : est un plan d’ensemble indiquant comment les acteurs
collaborent au moyen des informations gérées pour accomplir l’objectif de production.
C’est un n, d’activités des acteurs11
L’implémentation : c’est phase consiste à la mise en œuvre des programmes
dans un langage de programmation conformément aux spécifications définies dans les phases
précédentes. Elle renferme en son sein les phases de test et de mise au point (débondage). A la
sortie il sera produit un modèle un modèle physique (collection de modules implémentés mais
non testés, documentation de programme expliquant le code.)
Le test : Les tests permettent de vérifier :
 La bonne implémentation de toutes les exigences (fonctionnelles et techniques) :
 Le fonctionnement correct des interactions entre les objets ;
 La bonne interaction de tous les composants dans le logiciel

Classiquement, différents niveaux de tests sont réalisés dans cette activité : test
unitaire, test d’intégration, test de réception, test de performance et test de no-régression.

I.1.1 Théories de l’information

Lorsque nous l’employons, nous sous-entendons une information pouvant

servir un but, une information renferme une certaine valeur. Dans le cadre de la recherche en
informatique, le concept information, la façon qu’il est utilisé dans l’expression sciences et
technologie de l’information et de la communication, par exemple dans les techniques prévus
à sécuriser l’information dans une base de donnée, la constitution de système d’information,
etc.12
Le projet de fonder une science de l’information s’est affirmé sous l’impulsion
des plusieurs auteurs entre autre Claude Shannon dés 1949, présenter dans la langue française
par Léon Brillouin en 1959, c’est une théorie mathématique qui formalise l’information et sa
transmission de manière probabiliste.
C’est ainsi, lorsque nous avons souhaité parler spécialement de l’information
génétique en1970, ce pendant nous avons tenté de place des liens avec la théorie
mathématique ; avec se résultat nous n’avons pas pu atteindre les ambitions annoncées.
Quand à la théorie de Shannon est une théorie du contenu en information relativement à des
11
Jargon Informatique
12
interstices.info/théorie-de- l’information
 ~ 11 ~

objectifs comme celui de compresser les informations à travers un canal, cette théorie dit
quelque chose lorsqu’il est employé sur une moyenne d’un ensemble de données

1.1.2 Théories en système d’information

Par dentition, un système est un ensemble d’éléments collaborant entre eux.

Cet ensemble regroupe des composantes Identifié, abstraites ou physiques, interagissant pour
atteindre un but ou un objectif commun. En outre un système d’information est un ensemble
organisé des ressources qui permet de collecter, stocker, traiter et diffuser de l’information. Il
s’agit d’un système sociotechnique composé de deus sous-système. Sa structure est constitué
des ressources les personnels les matériels, les logiciels, les procédures) organisées et
communique les informations. Le système d’information coordonne grâce à la structuration
des échanges, les activités de l’organisation lui permettent d’atteindre ses objectifs. En
ingénierie, les gains de connaissance obtenus par cette méthodologie se traduisent par des
progrès dans les démarches de conception ou de pilotage de ces systèmes. Chaque
composante a un périmètre d’action déterminé, un environnement connu et échange avec cet
environnement par des flux entrants et sortants de toute nature possible (matière, finance,
énergie, information...). Selon Jean-Louis Le Moigne (1977, 1992) et Jacques Mélèse (1990),
pour l’appliquer le SI à ces organisations particulières que sont les entreprises. C’est de ces
travaux qu’émerge le SI (Système d’Information) définie comme un sous-système du système
d’entreprise, et issu d’une décomposition que schématise Ce premier stade de décomposition
introduit trois sous-systèmes au même niveau de représentation, le système de transformation
(dit aussi système opérant) des intrants en extrants.

1.1.3 Théorie des systèmes

Le concept moderne de système date des années 1940. Il est défini comme
étant un ensemble des éléments interagissant entre eux selon certains principes ou règles. Il
est dû à l’apport au moins de cinq personnages, il se compose de quatre concepts, qui sont
fondamentaux pour comprendre ce qu’est un système :

1.1.3.1 L’interaction

Renvoie à l’idée d’une causalité non linéaire. Ce concept est essentiel pour
comprendre la coévolution et la symbiose en biologie. Une forme particulière
d’interaction est la rétroaction (ou feed-back) dont l’étude est au centre des travaux de la
cybernétique13.

13
Jean-Pierre Dupuy, Aux origines des sciences cognitives, La découverte,1994
 ~ 12 ~

1.1.3.2 La globalité.

Si un système est d’abord un ensemble d’éléments, il ne s’y réduit pas. Selon la

formule consacrée, le tout est plus que la somme de ses parties. Von Bertalanffy 14 montre,
contre l'avis de Russell qui rejette le concept d'organisme, "qu'on ne peut obtenir le
comportement de l'ensemble comme somme de ceux des parties et [qu'on doit] tenir compte
des relations entre les divers systèmes secondaires et les systèmes qui les "coiffent" [pour]
comprendre le comportement des parties". Cette idée s’éclaire par le phénomène d’émergence
: au niveau global, apparaissent des propriétés non déductibles des propriétés élémentaires, ce
qu’on peut expliquer par un effet de seuil.

1.1.3.3 L’organisation

C’est le concept central pour comprendre ce qu’est un système. L’organisation

est l’agencement d’une totalité en fonction de la répartition de ses éléments en niveaux
hiérarchiques. Selon son degré d’organisation, une totalité n’aura pas les mêmes propriétés.
On arrive ainsi à cette idée que les propriétés d’une totalité dépendent moins de la nature et du
nombre d’éléments qu’ils contiennent que des relations qui s’instaurent entre eux.

1.1.3.4 La complexité

La complexité d’un système tient au moins à trois facteurs : le degré élevé

d’organisation ; l’incertitude de son environnement ; la difficulté, sinon l’impossibilité
d’identifier tous les éléments et toutes les relations en jeu. D’où l’idée que les lois qui
permettent de décrire ce type de système ne conduisent pas à sa reproduction à l'identique,
mais à la détermination d'un comportement global caractérisé par une productivité réduite.

Sous son aspect structurel, un système comprend quatre composants : qui sont
les éléments constitutifs, une limite, des réseaux de relation: les éléments sont en effet inter-
reliés.15

1.1.4 Théories de l’interaction homme–machine

En effet la communication humaine est un phénomène social dans lequel

l’individu agit de façon rationnelle, c'est-à-dire la communication relève d’une tentative
d’ajustement où nous devons ajouter au transport de l’information, les interlocuteurs se
reconnaissent partant de leurs actes et de jeu des rôles, se qui fait la communauté linguistique
dans un domaine humain.
14
Ludwig von Bertalanffy, Théorie générale des systèmes, éd : 1973
15
www.euro92.com/edi/biblio/analysefin/complements1.htm
 ~ 13 ~

C’est ainsi se terme semble abusif, dans le sens où la machine n’est pas un être
social, n’a pas d’intention ni de culture. Elle ne peut pas agir non plus sur le monde réel. Elle
n’a de fait que sur son propre monde. C’est ainsi Le terme interaction homme-machine est
plus adéquat16.

Ce pendant la machine procure des équipements, des moyens d’accès pour

accomplir une tâche, elle permet de partager des données, un logiciel, avec d’autres humains
pour travailler de manière collaborative dans un même environnement informatique. Elle se
présente donc comme un inter-acteur, elle doit être quelque peu sociale pour collaborer
efficacement avec un utilisateur autour des tâches de plus en plus complexes qui lui sont
confiées.

L'interaction homme-machine se situe dans une relation opérateur-tâche où la

machine à un rôle collaboratif [Falzon, 90] 17. Pour cela elle doit avoir des capacités qui lui
permettent de comprendre les processus actionnels et dialogiques, c'est-à-dire elle doit
posséder :

 La connaissance de l’opérateur,
 La connaissance du domaine de la tâche,
 Des représentations d’elle-même (pour s’adapter),
 Les règles de l’intervention pédagogique (aides, guides, exemples),
 Les règles du dialogue (principes de négociation, de coopération, de réactivité,
etc.),
 Des règles de comportement social, les processus différentiels mettant en
œuvre ces connaissances.

1.2 CONSIDÉRATION THÉORIQUE (MÉTHODE + NOTATION, LANGAGE DE

PROGRAMMATION ET S.G.B.D)

1.2.1 La méthode MERISE

La méthode merise est une méthode d’étude et de réalisation informatique. Les

extensions de MERISE ont été proposées, au fur et à mesure, pour prendre en compte des
technologies ou des principes nouveaux.

16
Bisson et al. 92] BISSON P., NOGIER J.F. MELODIA. Actes ERGO.IA’92, Biarritz, p. 69-
90, 1992
17
FALZON P., Ergonomie Cognitive du Dialogue. PUG, Grenoble, éd:1990
 ~ 14 ~

Parmi des formalismes pour la modélisation conceptuelle (le modèle

conceptuel de données et le modèle conceptuel des traitements), la modélisation logique (le
modèle logique des données et le modèle logique des traitements) et la modélisation physique
(le modèle physique de données et le modèle opérationnel des traitements).MERISE
préconise un développement logiciel basé sur le modèle en cascade18.

Lors du développement du système, l’utilisateur participe seulement au début

pendant la phase d’analyse du système d’information. A l’étape technologique, MERISE est
surtout ajustée pour l’étude et la conception des bases de données qui peut être en mesure de
supporter un mode de traitement batch, synchrone et client-serveur. Elle peut aussi aboutir à
une programmation structurée. A notre connaissance, il n’existe pas d’adaptation ou
d’extension de MERISE permettant de prendre en compte le développement d’applications
basées sur X.M.L.

1.2.2 U.M.L

U.M.L est un moyen d'exprimer des modèles objet en faisant abstraction de

leur implémentation, c'est-à-dire que le modèle fourni par U.M.L est valable pour n'importe
quel langage de programmation. IL s‘appuis sur un méta-modèle, un modèle de plus haut
niveau qui définit les éléments d'U.M.L (les concepts utilisables) et leur sémantique (leur
signification et leur mode d'utilisation). En 1994, G. Booch, père de la méthode qui porte son
nom [BOO 91]19, et J. Rumbaugh, principaYl acteur de la proposition de la méthode O.M.T
[RUM 91.
Ainsi c’est en 1997 que la première version d’U.M.L a vue le jour et, au cours
de cette même année, le langage U.M.L a été accepté par l’O.M.G (Object Management
Group). Il est présentement disponible en version 2.0 (http://www.uml.org/). Les créateurs
d’U.M.L insistent tout que particulièrement sur le fait que leur notation est un langage de
modélisation objet et non pas une méthode. La notation U.M.L peut ainsi se substituer sans
perte de sémantique aux notations de Booch, d’O.M.T. Le lecteur intéressé dispose
d’ouvrages de qualité en français sur la notation U.M.L. La description des classes U.M.L se
divise en trois compartiments contenant respectivement le nom de la classe, les attributs de la
classe et la signature des méthodes de la classe.
Nous revenons U.M.L est un langage qui s'appuie Le méta-modèle permet de
se placer à un niveau d'abstraction supérieur car il est étudié pour être plus générique que le

18
Boehm B.W. Software Engineering Economics. Englewood Cliffs: Prentice Hall, éd: 1981.
19
G. BOOCH, Benjamin Cummings, Object Oriented Design with Application, éd. 991.
 ~ 15 ~

modèle qu'il permet de construire. Le méta-modèle d'U.M.L en fait un langage formel

possédant les caractéristiques suivantes:
 Un language sans ambiguities
 Un langage universel pouvant servir de support pour tout langage orienté objet
 Un moyen de définir la structure d'un programme
 Une représentation visuelle permettant la communication entre acteurs d'un même
projet.
 Une notation graphique simple, compréhensible même par des non informaticiens
Le méta-modèle permet de donner des bases solides et rigoureuses à ce langage
graphique, dont les représentations graphiques ne sont là que pour véhiculer des concepts de
réalisation.
Le méta-modèle U.M.L fournit une panoplie d'outils permettant de représenter
l'ensemble des) éléments du monde objet (classes, objets, ...) ainsi que les liens qui les relie.
Toutefois, étant donné qu'une seule représentation est trop subjective, UML fournit un moyen
astucieux permettant de représenter diverses projections d'une même représentation grâce aux
vues. Une vue est constitué d'un ou plusieurs diagrammes.
On distingue deux types de vues:

1.2.2.1 Les vues statiques

Il désigne le système physiquement

 Diagrammes d'objets
 Diagrammes de classe
 Diagrammes de cas d'utilisation
 Diagrammes des composants
 Diagrammes de déploiement

1.2.2.2 Les vues dynamiques

Il indique les fonctionnements du système

 Diagrammes de sequence
 Diagrammes de collaborations
 Diagrammes d'états-transitions
 Diagrammes d'activités 20

1.2.3 La méthode U.P

20
DI GALLO Frédéric Méthodologie UML - Cours du cycle B
 ~ 16 ~

U.P (Unified Process) est une méthode générique de développement de

logiciel.
Générique signifie qu'il est nécessaire d'adapter U.P au contexte du projet, de
l'équipe, du domaine et/ou de l'organisation. C'est, entre parenthèses, plus ou moins vrai pour
toute méthode, qu'elle se définisse elle-même comme générique ou pas.
Il existe donc un certain nombre de méthodes issues d’U.P.
Le processus unifié est un processus de développement logiciel : il regroupe les
activités à mener pour transformer les besoins d’un utilisateur en système logiciel.
Caractéristiques essentielles du processus unifié :
 Le processus unifié est à base de composants,
 Le processus unifié utilise le langage U.M.L (ensemble d'outils et de
diagramme),
 Le processus unifié est piloté par les cas d’utilisation, Centre sur
l’architecture, Iterative et incremental.
L’objectif principal d’un système logiciel est de rendre service à ses utilisateurs
; il faut par conséquent de bien comprendre les désirs et les besoins des futurs utilisateurs. Le
processus de développement sera donc centré sur l'utilisateur. Le terme utilisateur ne désigne
pas seulement les utilisateurs humains mais également les autres systèmes. L’utilisateur
représente donc une personne ou une chose dialoguant avec le système en cours de
développement. Les cas d’utilisation font apparaître les besoins fonctionnels et leur ensemble
constitue le modèle des cas d’utilisation qui décrit les fonctionnalités complètes du système 21.
1.2.3.1 Le processus unifié est piloté par les risques

Dans ce cadre , les majeures d’échec d’un projet logiciel doivent être
écartées en priorité. nous identifiions une première cause provenant de l’incapacité de
l’architecture technique à répondre aux contraints opérationnelles et une seconder cause
liées à l’inadéquation du développement aux besoins des utilisateurs .

1.2.3.2 Le cycle de vie du processus unifié

Le processus unifié répète un certain nombre de fois une série de

cycles. tout cycle se conclut par la livraison d’une version du produit aux client et
s’articule en 4 phases : création élaboration , construction s et transition , chacune d’entre
elles se subdivisant à son tour en itération.

21
Christian Soutou U.M.L 2 pour les bases de données Éditions Eyrolles P12-16
 ~ 17 ~

a. Création
Première phase du cycle de vie du processus unifié, la création traduit
une idée en vision de produit fini et présente l’étude de rentabilité pour ce produit. Elle
essaie de répondre à une question : que va faire le système pour les utilisateurs ? A qui
peut ressembler archicube d’un tel système ? Quels d’élaboration seront les principales
tâches à effectuer durant cette étape de création.
b. Elaboration
Elle permet de préciser la plupart des cas d’utilisation seront spécifiés.
L’identification des risques doit être exprimée sous forme de vue de chacun des
modelés. Lors de cette phase une architecture de référence sera conçue. Au terme cette
étape de projet doit être en mesure de prévoir les activités et d’estimer les ressources
nécessaires à l’achèvement du projet.
c. Construction
C’est le moment l’on construit le produit. L’architecture de référence se
métamorphose en produit complet, elle est maintenant stable. Le produit contient tous les cas
d’utilisation que les chefs de projet, en accord avec les utilisateurs ont décidé de mettre au
point pour cette version. Celle-ci doit encore avoir des anomalies qui peuvent être en partie
résolue lors de la phase de transition.
d. Transition
Le produit est en version bêta. Un groupe d’utilisateurs essaye le produit et
détecte les anomalies et défauts. Cette phase suppose des activités comme la fabrication, la
formation des utilisateurs clients, la mise en œuvre d’un service d’assistance et la correction
des anomalies constatées (ou le report de leur correction à la version suivante).

1.2.4 S.G.B.D

1.2.3.4.1Historique

Le premier S.G.B.D objet a été Gemstone, extension du langage objet Small

talk. Certains produits commerciaux existent, citons Java Data Object de GemStone,
FastObjects de Poet Software, Ontos, Objectstore d’Object Design, Objectivity, Versant. Les
S.G.B.D objet n’ont pas bénéficié de l’environnement d’exploitation performant auquel les
SGBD relationnels ont habitué les responsables informatiques : requêtes efficaces, volume
important d’informations à stocker, fiabilité, sauvegarde et restauration, performances
transactionnelles
O.L.T.P (On Line Transaction Processing), outils complémentaires, etc.
 ~ 18 ~

Les éditeurs de S.G.B.D objet n’ont pas eu le succès qu’ils attendaient pour la
bonne et simple raison que l’existant des données des entreprises est toujours sous la forme
relationnelle et qu’aucun principe formel de migration n’a été et ne sera probablement jamais
établi.
Alors que le modèle relationnel manipule des informations sous forme
tabulaire, l’une des principales extensions du modèle de données objet (reprise par le modèle
objet-relationnel) consiste à manipuler des structures de données complexes incluant des
pointeurs et des tables imbriquées (collections).
Les pointeurs facilitent la fonction de navigation dans le langage de requêtes en
réduisant considérablement le nombre de jointures. Les tables imbriquées permettent de
s’affranchir de la règle de la première forme normale, à savoir qu’un attribut peut être
composé d’une liste de valeurs. Le modèle de données est dit « NF2 » (Non First Normal
Form)22. Les liens entre objets se réalisent à l’aide d’O.I.D (Object Identifier), qui est des
pointeurs physiques.
Ce pendant ver la fin des années 60 où les bases de données sont apparues, à
une époque où la nécessité d'un système de gestion de l'information souple se faisait ressentir.
Il existe cinq modèles de S.G.B.D, différenciés selon la représentation des données qu'elle
contient :
Le modèle hiérarchique : les données sont classées hiérarchiquement, selon une
arborescence descendante. Ce modèle utilise des pointeurs entre les différents
enregistrements. Il s'agit du premier modèle de S.G.B.D.
Le modèle réseau : comme le modèle hiérarchique ce modèle utilise des
pointeurs vers des enregistrements. Toutefois la structure n'est plus forcément arborescente
dans le sens descendant
Le modèle relationnel (S.G.B.D.R, Système de gestion de bases de données
relationnelles) : les données sont enregistrées dans des tableaux à deux dimensions (lignes et
colonnes). La manipulation de ces données se fait selon la théorie mathématique des relations
le modèle déductif : les données sont représentées sous forme de table, mais leur manipulation
se fait par calcul de prédicats
Le modèle objet (S.G.B.D.O, Système de gestion de bases de données objet) :
les données sont stockées sous forme d'objets, c'est-à-dire de structures appelées classes
présentant des données membres. Les champs sont des instances de ces classes

22
A. MAKINOUCHI, Proceedings of the Conference Very Large DataBases, éd: 1977.
 ~ 19 ~

A la fin des années 90 les bases relationnelles sont les bases de données les plus répandues
(environ trois quarts des bases de données).

1.2.3.5 Langage de programmation

Nous assistons aujourd’hui à une intégration sans précédent de composants de

systèmes informatiques qui n’étaient jusqu’ici pas connectés. Il en résulte des systèmes
répartis, hétérogènes, très dynamiques et souvent critiques en matière de sécurité. Nous avons
besoin de maîtriser cette complexité et en même temps d’augmenter la productivité des
utilisateurs et la fiabilité de l’infrastructure.
Ainsi avec des nombreux langages de programmation, surtout de scripts pour le
développement web (JavaScript, V.B Script), rendent possible l’exécution de méthodes sur
des objets dont les classes préexistent au développement. Le programmeur ne crée jamais de
nouvelles classes mais se contente d’exécuter les méthodes de celles-ci sur des objets.
Supposons par exemple que vous vouliez agrandir un « font » particulier de votre page web.
Vous écrirez f.setSize(16) mais jamais dans votre code, vous n’aurez créé la classe Font (vous
utilisez l’objet « f » issu de cette classe) et sa méthode setSize (). Vous vous limitez à les
utiliser comme vous utilisez les bibliothèques d’un quelconque langage de programmation23.

1.2.3.5.1 JavaScript

JavaScript est un langage de programmation web, nous recourons au JavaScript

qui est un langage de programmation qui s’adapte facilement aux besoins et nécessites des
pages web en augmente l’interactivité de celles ci avec l’utilisateur. Le JavaScript est un
langage de script, différent du langage Html. Le JavaScript vient compléter les autres
langages, se sont de code qui s’ajoute au code. Ce langage, inspiré plus ou moins directement
du langage C, ne pose pas de problèmes de compréhension à ceux qui ont déjà touché à la
programmation. Par contre, les utilisateurs issus de la bureautique ou de l’infographie risquent
d’être un peu déroutés devant les éléments classiques de la programmation comme les
variables, les instructions conditionnelles, les boucles, les fonctions et autres méthodes 24.

1.2.3.5.2 P.H.P

P.H.P est devenu le langage le plus sollicité pour bon nombre de webmaster,
car il présente beaucoup des avantages pour la conception de sites web dynamique. P.H.P est

23
Hugues Bersini l’orienté objet cours et exercices en U.M.L2 avec java et P.H.P 5 Eyrolles
ème
3 Edition P 36
24
Luc VAN LANCKER Des CSS au JavaScript appliqué aux feuilles de style Edition ENI
P195
 ~ 20 ~

un langage d’écriture de script qui s’exécute sur un serveur web et permet de mêler assez
simplement les informations de structuration d’un site web (exprimé dans le langage
H.T.M.L) et les instructions de programmation permettant de rendre ce même site dynamique
et interactif. Créé en 1995.

CHAPTRE II : L’ANALYSE DE L’ARCHITECTURE METIER

II.1.INTRODUCTION

Dans ce chapitre nous allons devoir analyser le périmètre dans le lequel évolue le
système à informatiser .par la suite nous allons étudier les besoins des utilisateurs et
terminer par la modélisation du métier du système à l’aide d’UML .Ce chapitre est
 ~ 21 ~

subdivisé en deux grand points dont la présentation du domaine d’étude et l’analyse du

métier.

II.2. PRESENTATION DU DOMAINE

1. SIEGE SOCIAL

Notre étude a été effectuée à l'hôtel du golf sise sur l’avenue de Likasi N°25, dans
la commune de Likasi, dans le HAUT-KATANGA en République Démocratique du
CONGO.

2. HISTORIQUE

L’hôtel du golf a vu le jour vers les années 90, Elle est équipée des chambres, vestiaires,
des tables et des chaises et souvent d’une cuisine pour pouvoir organiser un repas, Elle peut
également être sonorisée. L’hôtel du golf est un établissement privé avec l’autonomie
financière, c’est un lieu prévu pour accueillir d’évènements divers comme des repas festifs
(famille, association), de réunions publiques etc.
L’hôtel du golf propose des formules « clé à main » afin de garantir l’accueille des
invités ainsi que des organisateurs de l’évènement en règle générale :

 La location des chambres;

 La restauration ;
 Le personnel de service ;…

3. ORGANIGRAMME HIERARCHIQUE

C’est une représentation schématique de la structure hiérarchique du système.

RESPONSABLE DE
L’HOTEL

DG
 ~ 22 ~

Figure 1 : organigramme
Source : Gérant de l’hôtel

II.3. Description textuelle du processus

Le métier est défini comme étant l’ensemble d’activités d’un système permettant de
répondre aux besoins des utilisateurs.25

Pour notre travail, Le processus de réservation de chambre s’initialise lorsque le client

fait la demande de L’allocation ou (réservation) auprès du réceptionniste, Et le réceptionniste
vérifie la disponibilité de la chambre, Si la chambre n’est pas disponible à la date demandée,
Il demande au client de projeter l’allocation de la chambre à la date qui lui sera proposée ; Et
si la chambre est disponible à la date demandée il lui demande de verser l’argent.
Ensuite le client verse l’argent auprès du réceptionniste, Après cela le réceptionniste
établit le bon d’allocation et le transmet au gérant et ce dernier met à jour le carnet et fait son
rapport.
II.3.0. Identification des acteurs
Acteurs Rôles
Client C’est la personne faisant la demande de la réservation de chambre
Gérant C’est une personne qui met à jour le carnet et consulte les allocations,
25
http ://fr.Wikipédia.org métier 02/09/2022, 14h
 ~ 23 ~

bref c’est une personne qui gère les chambres.

Réceptionniste C’est une personne qui gère les allocations des clients.

II.3.1. Diagramme de cas d’utilisation métier

Le diagramme des cas d'utilisation (Use Case Diagram) constitue la première étape de
l’analyse UML26 en :

 Modélisant les besoins des utilisateurs.

 Identifiant les grandes fonctionnalités et les limites du système.
 Représentant les interactions entre le système et ses utilisateurs.

Figure 2 : diagramme de cas d’utilisation métier

II.3.2. Diagramme du contexte

Dans ce point nous allons devoir présenter le système comme une boite noire et son
périmètre afin de voir clairement les acteurs qui interagissent avec lui.
Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif
matériel ou autre système qui interagit directement avec le système, en émettant et/ou en
recevant les messages susceptibles d’être porteur de données).27

26
Cours UML2 « livre de Langage de modélisation objet unifié » p1
27
Roque pascal, Op.cit., P41
 ~ 24 ~

Figure 3 : diagramme de contexte

II.3.3. Diagramme d’activité

Le diagramme d’activité permet de modéliser un processus Interactif, global ou partiel

pour un système donné (logiciel, système d'information).
Quelques Concepts de base du diagramme d’activité :
Transition : est déclenchée vers une action suivante
 nœud initial (état initial) : permet à partir d’un flot unique entrant, de créer
plusieurs flots concurrents en sortie de la barre de synchronisation.

 nœud final (état final) : permet de d’écrire ou démontrer la fin du processus,

 nœud de fin flot (état de sortie),

 nœud de décision (choix) : permet de faire un choix entre plusieurs flots

sortants en fonction des conditions de garde de chaque flot. Un nœud de test-décision
n’a qu’un seul flot en entrée. On peut aussi utiliser seulement deux flots de sortie : le
premier correspondant à la condition vérifiée et l’autre traitant le cas sinon.
 ~ 25 ~

Figure 4 : Diagramme d’activité système

II.3.4. Diagramme de cas d’utilisation système

Le diagramme de cas d’utilisation est utilisé dans l’activité de spécification de besoin,

c’est-à-dire il montre les interactions fonctionnelles entres les acteurs et le système sous
étudier.
 ~ 26 ~

Figure 5 : Diagramme de cas d’utilisation

II.4. Diagramme de séquence système

Le diagramme de séquence fait parties des diagrammes comportementaux

(dynamique) et plus précisément des diagrammes d’interactions28.
• Il permet de représenter des échanges entre les différents objets et acteurs du
système en fonction du temps.
• A moins que le système à modéliser soit extrêmement simple, nous ne pouvons pas
modéliser la dynamique globale du système dans un seul diagramme. Nous ferons donc appel

28
Cours UML5 « livre de Langage de modélisation objet unifié » p1
 ~ 27 ~

à un ensemble de diagrammes de séquences chacun correspondant à une sous fonction du

système, généralement d’ailleurs pour illustrer un cas d’utilisation.

II.4.1. Diagramme de séquence « C.U S’authentifier »

Acteur principal : utilisateur

Utilisateur
1. Demande formulaire authentification
3. Saisit login et mot de passe
4. Il valide l’envoi du formulaire
Système
2. Affichage du formulaire
5. Affichage du formulaire

Figure 6 : Diagramme de séquence système s’authentifier

II.4.2. Diagramme de séquence « C.U Demande allocation ou (réservation) »

Objectif : Permettre au client de demander allocation

Acteur principal : le client

Scénario nominal
Client Système
1. Demande formulaire demande allocation 2. Affichage du formulaire
3. Saisir les informations demande
4. Valider 5. Message de confirmation
 ~ 28 ~

Figure 7 : Diagramme de séquence système demande allocation

II.4.3. Diagramme de séquence « C.U Gérer allocation ou réservation)»

Objectif : Ce cas d’utilisation permet au réceptionniste de traiter la demande du client

Acteur principal : réceptionniste

 Pré condition : La demande de l’allocation doit être admise

 Scénario nominal

Réceptionniste
1. Demande formulaire gérer allocation
3. Demande du formulaire ajout
5. Saisir les informations allocation
6. Valider
8. Recherche allocation
10. Sélectionner les informations à modifier
11. Saisir la modification
12. Valider
14. Rechercher les informations à supprimer
16. Sélectionner les informations à supprimer
17. Valider
Système
2. Affichage du formulaire
4. Affichage du formulaire
7. Message de confirmation
9. Afficher les informations recherchées
13. Message de confirmation
15. Afficher les informations recherchées
18. Message de confirmation
 ~ 29 ~

Figure 8 : Diagramme de séquence système Gérer allocation

II.4.4. Diagramme de séquence « C.U Mettre à jour carnet allocation »

Objectif : Permettre au gérant de mettre les allocations à jour

Acteur principal : Gérant

 Pré condition : La demande de l’allocation doit être admise

 ~ 30 ~

 Scénario nominal

Réceptionniste
1. Demande formulaire mise à jour
3. Demande du formulaire ajout
5. Saisir les informations carnet
6. Valider
8. Recherche allocation
10. Sélectionner les informations à modifier
11. Saisir la modification
12. Valider
14. Rechercher les informations à supprimer
16. Sélectionner les informations à supprimer
17. Valider
Système
2. Affichage du formulaire
4. Affichage du formulaire
7. Message de confirmation
9. Afficher les informations recherchées
13. Message de confirmation
15. Afficher les informations recherchées
18. Message de confirmation
 ~ 31 ~

Figure 9 : Diagramme de séquence système mettre à jour carnet allocation

II.4.5. Diagramme de séquence « C.U Consulter allocation »

Objectif : Ce cas d’utilisation permet au Gérant de consulter les allocations des clients
Acteur principal : Gérant

 Pré condition : S’authentifier

 ~ 32 ~

 Scénario nominal

Réceptionniste Système
1. Demande formulaire consulté allocation 2. Affichage du formulaire
3. recherche allocation 4. Afficher allocation

Figure 10 : Diagramme de séquence système « C.U consulter allocation »

II.4.6. Diagramme de séquence « C.U Etablir Bon allocation »

Objectif : Ce cas d’utilisation permet au Réceptionniste d’établir le bon d’allocation

Acteur principal : Réceptionniste

 Pré condition : Gérer allocation

 Scénario nominal

Réceptionniste Système
1. Demande formulaire établir bon 2. Affichage du formulaire
3. Saisir les informations du bon d’allocation
5. Message de confirmation
4. Valider
 ~ 33 ~

Figure 11 : Diagramme de séquence système « C.U Etablir Bon allocation »

II.5. Diagramme de classe

Le diagramme de classe constitue l’un des pivots essentiels de la modélisation avec UML.
En effet, ce diagramme permet de donner la représentation statique du système à développer.
Cette représentation est centrée sur les concepts de classe et d’association. Chaque classe
décrite par les données et les traitements dont elle est responsable pour-elle-même et vis-à-vis
des autres classes. Les traitements sont matérialisés par des opérations.
La description du diagramme de classe est fondée sur :
 Le concept d’objet,
 Le concept de classe comprenant les attributs et les opérations,
 Les différents types d’association entre classes.

II.5.1. Diagramme de classe « C.U demander allocation »

 ~ 34 ~

Figure 12 : Diagramme de classe « C.U demande allocation »

II.5.2. Diagramme de classe « C.U Gérer allocation »

Figure 13 : Diagramme de classe « C.U Gérer allocation »

 ~ 35 ~

II.5.3. Diagramme de classe « C.U Mettre à jour carnet»

Figure 14 : Diagramme de classe « C.U Mettre à jour carnet »

II.5.4. Diagramme de classe « C.U Consulter allocation»

Figure 15 : Diagramme de classe « C.U consulter allocation »

 ~ 36 ~

II.5.4. Diagramme de classe « C.U Etablir Bon allocation»

Figure 16 : Diagramme de classe « C.U Etablir Bon allocation»

II.5.6. Diagramme de classe du domaine

Figure 17 : Diagramme de classe du domaine

 ~ 37 ~

CHAPITRE III : CONCEPTION DETAILLEE DU SYSTEME

INFORMATIQUE

III.1. INTRODUCTION

Ce chapitre nous permet de faire une étude de fonds en comble du projet qui a
été soumis à notre étude. Nous ne pouvons bien évidement pas revenir sur les détails de
l'étude complète d'un projet, mais nous travaillerons sur les parties fondamentales faisant
ressortir les points saillants du travail qui nous a été confié. Ce chapitre constitue pour nous
l’une des parties essentielles de notre étude. Elle se bornera essentiellement sur la conception
du système ainsi que le choix des matériels utilisés.

III.1.1. CONCEPTION PRELIMINAIRE

Les choix techniques pour ce projet stratégique sont principalement basés sur :
- La modélisation orientée objet avec UML
- L’utilisation de Pacestar pour générer les diagrammes UML
- Mise en place d’une plate –forme (avec PHP, JavaScrip et Boostrap )

III.2. CONCEPTION DETAILLEE

a) diagramme de séquence de conception « C.U s’authentifier »
 ~ 38 ~

b) diagramme de séquence de conception « C.U demande allocation»

 ~ 39 ~

c) diagramme de séquence de conception « C.U Gérer Allocation»

 ~ 40 ~

d) diagramme de séquence de conception « C.U mettre à jour carnet allocation»

e) diagramme de séquence de conception « C.U consulter allocation »

 ~ 41 ~

f) diagramme de séquence de conception « C.U Etablir bon »

 ~ 42 ~

III.2.1. Diagramme de classe de conception

Ce diagramme permet de préciser la structure de la classe de développement de notre

système informatique conçu en vue de remédier au problème soulevé dans la partie
précédente de notre travail.
Les dialogues permettent les interactions entre l’application et ses utilisateurs il s’agit
typiquement des écrans proposé à l’utilisateur les formulaires de saisie, les résultats de
recherche etc. il y a au moins un dialogue pour les paire d’acteur, cas d’utilisation, le dialogue
vont procéder des saisie ou des opérations, les attributs représenterons des champs des
résultats, les opérations seront déterminés au niveau de la conception bien attendu après
l’élaboration des interactions.
Les classes qui représentent les concepts du métier sont qualifiées d’entité, elles vont
survivre après l’exécution d’un cas d’utilisation particulier et qu’elles permettront à des
données nous allons également ajouter des associations entre les classe d’analyse, tout en
respectant certaines règles que voici :
- Le dialogue ne se relie qu’aux contrôles ou à d’autres dialogues, pas
directement aux entités
- Les entités ne peuvent être reliées qu’au contrôle ou à d’autres entités,
- Les contrôles ont accès à tous les types des classes, y compris d’autres
contrôles,
- Un acteur ne peut être lié qu’à un dialogue.
a) Diagramme de classe de conception « C.U S’authentifier »
 ~ 43 ~

b) Diagramme de classe de conception « C.U Consulter Allocation »

 ~ 44 ~

c) Diagramme de classe de conception « C.U Demande Allocation »

d) Diagramme de classe de conception « C.U Mise à jour carnet »

e) Diagramme de classe de conception « C.U Etablir bon »

 ~ 45 ~

f) Diagramme de classe de conception « C.U Gérer Allocation »

 ~ 46 ~

III.2.2. diagramme de classe de conception Globale

III.3. ARCHITECTURE ET DEPLOIEMENT

1. Architecture logique

L’architecture Client-serveur est un modèle de fonctionnement logiciel qui peut se

réaliser sur tout type d’architecture matérielle (petites ou grosses machines), à partir du
moment où ces architectures peuvent être interconnectées.
Dans la Base de données distribuée, le client aura l’interface et demande service au Serveur
pour manipuler les données de la BD et le serveur sera actif pour gérer la BD, les transactions,
les pannes, les droits d’accès et rendre service (requêtes) de clients. Le serveur peut avoir le
 ~ 47 ~

type Contrôleur de nom du domaine, de fichiers, de configuration, de passerelle,

d’impression, de diffusion, de sauvegarde, du Web, d’application, un de messagerie.
Nous avons opté pour l’architecture Client/serveur à 3-tiers. Dans cette architecture à 3
niveaux, les applications au niveau du serveur sont délocalisées, c’est-à-dire que chaque
serveur est spécialisé dans une tache (Serveur Web, Serveur de BD par exemple). Il permet :
 Une plus grande flexibilité/souplesse ;
 Une sécurité accrue car la sécurité peut être définie indépendamment pour chaque
service, et à chaque niveau ;
 Des meilleures performances, étant donné le partage des tâches entre les différents
Serveurs.
Cette architecture (appelée 3-tiers) fait intervenir 3 parties indépendantes les unes des autres :
 La couche des données liée au -Serveur de BD (SGBD) : stockage et accès aux
données. Le système de stockage a pour but de conserver une quantité plus ou moins
importante de données de façon structurée. Nous pouvons utiliser pour cette partie des
systèmes très variés qui peuvent être des systèmes de fichiers, des mainframes, des
systèmes des bases de données relationnelles, etc.
 La logique applicative : il se compose généralement d’un script ou d’un programme
qui constitue les traitements métier nécessaire sur l’information afin de le rendre
exploitable par chaque utilisateur.
 La couche présentation (ou affichage) associé au Client qui de fait est dit « léger ».
dans la mesure où il n’assume aucune fonction de traitement à la différence du modèle
2-tiers. C’est la partie la plus immédiatement visible pour l’utilisateur. Elle a donc une
importance primordiale pour rendre l’information lisible, compréhensible et
accessible.

2. Architecture physique

Cette architecture identifie les éléments du système informatique, la structure

d’appartenance ainsi que les liaisons entre ses structures. L’architecture physique est aussi
appelé architecture matériel. Le réseau constitue un nœud de liaison de tout le matériel de
notre système.
3. Généralités sur le Web

Le World-Wide Web (ou WWW, ou Web) est un grand – très grand – système
d’information réparti sur un ensemble de sites connectés par le réseau Internet. Ce système est
essentiellement constitué de documents hypertextes, ce terme pouvant être pris au sens large :
textes, images, sons, vidéos, etc. Chaque site propose un ensemble plus ou moins important de
documents, transmis sur le réseau par l’intermédiaire d’un programme serveur. Ce programme
serveur dialogue avec un programme client qui peut être situé n’importe où sur le réseau. Le
 ~ 48 ~

programme client prend le plus souvent la forme d’un navigateur, grâce auquel un utilisateur
du Web peut demander et consulter très simplement des documents. Le Web propose aussi
des services ou des modes de communication entre machines permettant d’effectuer des
calculs répartis ou des échanges d’information sans faire intervenir d’utilisateur. Fyama
Blaise, (2018-2019).

III.4.0. Diagramme de Composant

III.4.1. Diagramme de déploiement

Il permet de représenter l’architecture physique supportant l’exploitation du

système.
 ~ 49 ~

CHAPITRE IV : L’ARCHITECTURE TECHNIQUE ET

IMPLEMENTATION

IV.1. INTRODUCTION

Il est impérieux à toute application informatique d’être réalisée à l’aide d’un langage
au choix par le Concepteur, d’où c’est le cas de notre étude, le choix de la technologie n’est
pas un plaisir pour nous, mais plutôt on tient compte de la nature du travail à faire ou de
l’application à développer dans le domaine informatique.

IV.2. Etude de l’implémentation

Ainsi nous avons utilisé le langage de programmation PHP dans sa nouvelle version
(7) dédié à la création des applications Web dynamique, celui-ci nous l’avons manipulé dans
un éditeur de texte nommé SUBLIME TEXT 3. Par ailleurs, il faut noter que les pages écrites
en PHP sont à chaque fois testées grâce à une plateforme de développement spécifique. La
plateforme que nous avons utilisée est WAMPSERVER 3.1.3 qui inclut tous les outils
nécessaires pour le test d’un site Web dynamique à savoir le Serveur Web, le serveur des
Bases de données (MySQL 5.7.21) et son interface d’administration phpMyAdmin 4.7.9.
Nous avons aussi utilisé quelques fonctions à base du HTML et du Framework Bootstrap pour
la mise en forme des pages.

IV.3. choix du système de gestion des bases de données (SGBD)

WampServer est une plate-forme de développement Web sous Windows pour des
applications Web dynamiques à l’aide du serveur Apache, du langage PHP et d’une base
de données MySQL. Il possède également PhpMyAdmin pour gérer plus facilement les
bases de données.
 ~ 50 ~

IV.4. Programmation et Présentation des interfaces

~ 51 ~
 ~ 52 ~

CONCLUSION GENERALE

Nous voici à la fin de ce travail dont l’intitulé est « conception et réalisation

d’une application web de réservation de chambre ; « cas de l'hôtel du Golf ».

Nous avons subdivisé ce travail en quatre chapitres :

Dans le premier chapitre nous avons procédé aux définitions de concepts et
considération théorique qui consistent à la description de la méthode et des concepts liés au
système d’information ; dans le deuxième chapitre nous avons présenté l’organisation
« Hôtel du Golf » et d’analyser son système d’information ; dans le troisième chapitre nous
avons modélisé le nouveau système informatique à l’aide de la méthode UP.
Enfin au quatrième chapitre nous avons fait l’implémentation, une phase qui
consiste à mettre en pratique toutes les théories étant donné que la gestion fondamentale était
d’arriver à organiser les différentes informations concernant le contrôle de cette
problématique, que nous avons opté Pour MySQL comme gestionnaire de base de données et
à partir de PHP comme langage de programmation.
Ce travail n’est pas parfait car tout œuvre humaine est toujours entaché des
irrégularités. Ainsi nous prions à nos lecteurs et les utilisateurs de ne pas en tenir rigueur,
toutes les remarques qui seront formulées à l’endroit de notre travail seront les bienvenues.
 ~ 53 ~

BIBLIOGRAPHIE

1. OUVRAGES

- Collongues & all, ”cour de méthode de conception”, boras, paris, 1986

- Hugues Bersini l’orienté objet cours et exercices en U.M.L2 avec java et P.H.P 5
Eyrolles 3ème Edition P 36Luc VAN LANCKER Des CSS au JavaScript appliqué aux
feuilles de style Edition ENI P195
- GRAWITZ T. ; Méthode de science social, tome I ? éd.Dalloz,Paris,1994.dictionnaire
la rousse
édition 2013,page247

2. NOTE DE COURS
- Theodore MWANZA, cour de labo 2

- RAMAZANI, cours de question spécial de conception de système d’information, unic-

likasi,
2021-2022, inédit

- MARC TSHAMBI, cours de conception de système d’information, unic-likasi,l1

INFO, 2021-
2022, inédit

3. MEMOIRE ET TFC
- Gabriel Donia, de l’université protestant dans son mémoire intitulé « mise en place
d’une application web pour la réservation des billets d’avion à une agence »,
- Gracia KABULU de l’université de KINSHASA dans son mémoire
intitulé « conception et réalisation d’une application web pour la réservation en
ligne des chambres »
4. SITE WEB

- Https //fr.m.Wikipédia.org,
- Https //fr.m.Wikipédia.org,
- Https //fr.m.Wikipédia.org,
- ame-nature.com/index.php/savoir écrire
- Dictionnaires et recueils de correspondence
- A. collongues & all, ”cour de méthode de conception”, boras, paris, 1986
- Https //fr.m.Wikipédia.org, vendredi 06/07/2023
 ~ 54 ~

TABLE DES MATIERES

EPIGRAPHE...............................................................................................................................I
DEDICACE................................................................................................................................II
REMERCIEMENTS.................................................................................................................III
LISTE DES ABREVIATIONS...............................................................................................IV
I.0 PRESENTATION DU SUJET.........................................................................................1
I.1 PROBLEMATIQUE.........................................................................................................1
I.3 ETAT DE LA QUESTION...............................................................................................3
I.IV. CHOIX ET INTERET DU SUJET................................................................................4
I.VI DELIMINATION DU SUJET.....................................................................................7
I.VII. SUBDISION DU TRAVAIL.......................................................................................7
1.1 DEFINITIONS DES CONCEPTS (CONCEPTS DE L’INFORMATION ET DU
DOMAINE D’APPLICATION..............................................................................................9
I.1.1 Théories de l’information.......................................................................................10
1.1.2 Théories en système d’information......................................................................11
1.1.3 Théorie des systèmes.............................................................................................11
1.1.4 Théories de l’interaction homme–machine..........................................................12
1.2 CONSIDÉRATION THÉORIQUE (MÉTHODE + NOTATION, LANGAGE DE
PROGRAMMATION ET S.G.B.D).....................................................................................13
1.2.1 La méthode MERISE.............................................................................................14
1.2.2 U.M.L......................................................................................................................14
1.2.3 La méthode U.P......................................................................................................16
1.2.4 S.G.B.D...................................................................................................................17
CHAPTRE II : L’ANALYSE DE L’ARCHITECTURE METIER..........................................21
II.1.INTRODUCTION..........................................................................................................21
II.2. PRESENTATION DU DOMAINE............................................................................21
II.3. Description textuelle du processus............................................................................22
II.3.1. Diagramme de cas d’utilisation métier.......................................................................23
II.3.2. Diagramme du contexte.............................................................................................24
II.3.3. Diagramme d’activité.................................................................................................24
II.3.4. Diagramme de cas d’utilisation système....................................................................25
II.4. Diagramme de séquence système..............................................................................26
II.4.1. Diagramme de séquence « C.U S’authentifier ».......................................................27
II.4.2. Diagramme de séquence « C.U Demande allocation ou (réservation) »...................27
II.4.3. Diagramme de séquence « C.U Gérer allocation ou réservation)»...........................28
II.4.4. Diagramme de séquence « C.U Mettre à jour carnet allocation ».............................29
II.4.5. Diagramme de séquence « C.U Consulter allocation ».............................................31
 ~ 55 ~

II.4.6. Diagramme de séquence « C.U Etablir Bon allocation »..........................................32

II.5. Diagramme de classe.................................................................................................33
II.5.1. Diagramme de classe « C.U demander allocation »..................................................33
II.5.2. Diagramme de classe « C.U Gérer allocation »........................................................34
II.5.3. Diagramme de classe « C.U Mettre à jour carnet»....................................................35
II.5.4. Diagramme de classe « C.U Consulter allocation»....................................................35
II.5.4. Diagramme de classe « C.U Etablir Bon allocation»...............................................36
II.5.6. Diagramme de classe du domaine..............................................................................36
CHAPITRE III : CONCEPTION DETAILLEE DU SYSTEME INFORMATIQUE.............37
III.1. INTRODUCTION.......................................................................................................37
III.1.1. CONCEPTION PRELIMINAIRE............................................................................37
III.2. CONCEPTION DETAILLEE.....................................................................................37
III.2.1. Diagramme de classe de conception.........................................................................42
b) Diagramme de classe de conception « C.U Consulter Allocation »..........................43
III.3. ARCHITECTURE ET DEPLOIEMENT....................................................................46
3. Généralités sur le Web......................................................................................................47
III.4.0. Diagramme de Composant............................................................................................48
CHAPITRE IV : L’ARCHITECTURE TECHNIQUE ET IMPLEMENTATION..................49
IV.1. INTRODUCTION.......................................................................................................49
IV.3. choix du système de gestion des bases de données (SGBD).......................................49
IV.4. Programmation et Présentation des interfaces.............................................................50
CONCLUSION GENERALE...................................................................................................52
BIBLIOGRAPHIE....................................................................................................................53