Rapport Licence Fabrice Gestion Des Des Hopitaux

MISE SUR PIED D’UN SYSTEME D’INFORMATION HOSPITALIER (SIH) D’AUTOMATISATION DU
PROCESSUS D’ADMISSION ET DE SUIVI DES PATIENTS DANS UN ETABLISSEMENT DE SANTE :

CAS DU CENTRE MEDICO-CHIRURGICALE (CMR) REAVEN
DEDICACE
Je dédie ce rapport à ma chère tante,

Jeanne JUESSI KOUEBOU
Rédigé Par Fabrice KEGOUM KOUEMO, Elève Ingénieur des Travaux Informatiques, IAI- ii
Cameroun
REMERCIEMENTS
L’écriture d’un rapport est une tâche trépidante, qui n’a rien d’un exercice solitaire.
Ces quelques mots me permettront de remercier les personnes sans lesquelles je n’aurais pu
mener à bien ce projet.
Nous remercions de ce fait :
Les membres du jury, qui nous ont honorés en acceptant de juger ce modeste travail ;
Le représentant résident de l’IAI-Cameroun M. Armand Claude ABANDA pour son
engagement à nous fournir une formation de qualité et pour ses précieux conseils ;
Le président directeur général d’UNIVERS BINAIRE SARL M. Martial GAPIAPSI
NGUETO qui nous a permis d’effectuer ce stage dans sa structure et nous a suivi avec
beaucoup de professionnalisme ;
Notre encadreur académique Mme Maeva BELINGA AKONO pour le temps qu’elle
nous a consacré, pour toute son aide et son appui durant le stage, pour avoir suivi ce
projet avec intérêt, pour ses relectures et conseils éclairés ;
Tous les enseignants de l’IAI-Cameroun pour la formation et l’encadrement qu’ils
nous ont donné ;
Tous nos camarades de promotion avec qui nous nous sommes liés d’amitié ;
Tous nos camarades stagiaires d’Univers Binaire Sarl pour leur aide et leur
disponibilité ;
Mes oncles et tantes pour leur soutien de toute nature ;
Mes frères pour leur accompagnement ;
Ma chère et tendre, pour n’avoir cessé de me redonner confiance durant les moments
difficile de ce travail.
Rédigé Par Fabrice KEGOUM KOUEMO, Elève Ingénieur des Travaux Informatiques, IAI- ii
Cameroun i
SOMMAIRE
DEDICACE................................................................................................................................ii
REMERCIEMENTS.................................................................................................................iii
SOMMAIRE..............................................................................................................................iv
LISTE DES FIGURES...............................................................................................................v
LISTE DES TABLEAUX........................................................................................................vii
RESUME.................................................................................................................................viii
ABSTRACT...............................................................................................................................ix
INTRODUCTION GENERALE................................................................................................1
PARTIE I : PHASE D’INSERTION..........................................................................................2
DOSSIER I : DOSSIER D’INSERTION...................................................................................3
PARTIE II : PHASE TECHNIQUE.........................................................................................10
DOSSIER II : CAHIER DES CHARGES................................................................................12
DOSSIER III : DOSSIER D’ANALYSE.................................................................................30
DOSSIER IV : DOSSIER DE CONCEPTION........................................................................67
DOSSIER V : DOSSIER DE REALISATION........................................................................78
DOSSIER V : GUIDE D’UTILISATION................................................................................88
CONCLUSION.........................................................................................................................99
REFERENCES BIBLIOGRAPHIQUES....................................................................................x
WEBOGRAPHIE......................................................................................................................xi
GLOSSAIRE............................................................................................................................xii
ANNEXES...............................................................................................................................xiii
TABLE DES MATIERES.......................................................................................................xiv
Rédigé Par Fabrice KEGOUM KOUEMO, Elève Ingénieur des Travaux Informatiques, IAI- i
Cameroun v
LISTE DES FIGURES
Figure 1 : organigramme Univers Binaire Sarl..........................................................................7

Figure 2 : diagramme de planification (GANTT).....................................................................27
Figure 3 : diagramme UML version 2.4..................................................................................37
Figure 4 : représentation du processus 2TUP...........................................................................40
Figure 5 : diagramme de cas d’utilisation global du système...................................................43
Figure 6 : diagramme de cas d'utilisation gérer patient............................................................44
Figure 7 : effectuer une consultation........................................................................................45
Figure 8 : gérer les patients hospitalisés...................................................................................46
Figure 9 : diagramme de cas du package gestion financière....................................................47
Figure 10 : diagramme de cas d'utilisation "gérer les produit "................................................48
Figure 11 : diagramme de cas d'utilisation "gérer personnel"..................................................49
Figure 12 : diagramme d'activité "authentification".................................................................53
Figure 13 : diagramme d'activité "ajout d’un patient"..............................................................54
Figure 14 : diagramme de séquence "authentification"............................................................59
Figure 15 : diagramme de séquence "ajouter patient"..............................................................60
Figure 16 : diagramme de séquence "payer facture"...............................................................61
Figure 17 : diagramme de communication authentification.....................................................63
Figure 18: diagramme de communication "payer facture".......................................................64
Figure 19 : diagramme d'activité de la solution........................................................................66
Figure 20 : diagramme de classe...............................................................................................71
Figure 21 : diagramme d'objet de la solution............................................................................73
Figure 22 : diagramme de paquetage de la solution.................................................................75
Figure 23 : digramme de composant de la solution..................................................................77
Figure 24 : page de téléchargement de xampp.........................................................................79
Figure 25 : etape1 installation xampp.......................................................................................80
Figure 26 : panneau de contrôle de xampp...............................................................................80
Figure 27 : technologies et langages de programmation utilisés..............................................81
Figure 28 : représentation de l'architecture MVC.....................................................................82
Rédigé Par Fabrice KEGOUM KOUEMO, Elève Ingénieur des Travaux Informatiques, IAI- v
Cameroun
Figure 29 : Présentation de l'architecture 3-tiers.......................................................................83

Figure 30 : éléments d'un diagramme de déploiement..............................................................84
Figure 31 : diagramme de déploiement de la solution..............................................................86
Figure 32 : interface de connexion............................................................................................89
Figure 33 : interface d'accueil propriétaire...............................................................................90
Figure 34 : interface d'accueil personnel..................................................................................91
Figure 35 : menu paramétrage..................................................................................................92
Figure 36 : formulaire d'ajout d'un patient................................................................................93
Figure 37 : interface de l'accueil...............................................................................................94
Figure 38 : formulaire d'ajout d'un patient................................................................................95
Figure 39 : affichage de la liste des patients.............................................................................96
Figure 40 : visualisation de l'état financier...............................................................................97
Figure 41: fichier PDF généré...................................................................................................98
Cameroun i
LISTE DES TABLEAUX
Tableau 1 : ressources matérielles d'Univers Binaire Sarl..........................................................8

Tableau 2 : ressources humaines (source : mercuriale des prix 2022).....................................23
Tableau 3 : ressources matérielles (source : mercuriale des prix 2022)...................................24
Tableau 4 : Ressources logicielles (source : mercuriale des prix 2022)...................................25
Tableau 5 : Ressources diverses...............................................................................................26
Tableau 6 : Estimation globale du projet..................................................................................26
Tableau 7 : liste des intervenants..............................................................................................29
Tableau 8 : Etude comparative UML MERISE........................................................................35
Tableau 9 : éléments d'un diagramme de cas d'utilisation.......................................................41
Tableau 10 : description textuelle du cas d'utilisation s'authentifier........................................50
Tableau 11 : description textuelle du cas d'utilisation effectuer consultation..........................51
Tableau 12 : Eléments d'un diagramme d'activité....................................................................52
Tableau 13 : effectuer consultation...........................................................................................55
Tableau 14 : effectuer consultation...........................................................................................56
Tableau 15 : Eléments d'un diagramme de séquence................................................................57
Tableau 16 : formalisme du diagramme de communication.....................................................62
Tableau 17 : Eléments d'un diagramme d’état transition..........................................................65
Tableau 18 : éléments d'un diagramme de classe.....................................................................69
Tableau 19 : formalisme du diagramme d'objet........................................................................72
Tableau 20 : éléments d'un diagramme de cas d'utilisation.....................................................74
Tableau 21 : éléments d'un diagramme de composants............................................................76
Cameroun ii
RESUME
Afin d’automatiser le processus d’admission et de suivi des patients dans les

établissements de santé, nous avons mis sur pied un système d’information hospitalier qui
devra désormais permettre aux hôpitaux et centres de santé d’admettre et de suivre de manière
automatique les patients. Nous avons effectué ce travail sous le thème de : « Mise sur pied
d’un système d’information hospitalier (SIH) d’automatisation du processus
d’admission et de suivi des patients dans un établissement de santé ». Cette solution vise à
améliorer la qualité des soins du système sanitaire camerounais par le bais de l’informatique.
Il sera désormais possible, grâce à ce logiciel, de conserver numériquement les informations
relatives au passage d’un patient dans un établissement de santé afin de pérenniser les
antécédents médicaux de ce dernier et de pouvoir y faire recours en cas de besoin pour
poursuivre son traitement. Ainsi nous expérimentons le dossier médical électronique.
Mots clés : système d’information hospitalier, automatisation, processus d’admission, suivi,

patient, établissement de santé.
Cameroun ii
i
ABSTRACT
In order to automate the process of admission and follow-up of patients in health

establishments, we have set up a hospital information system which will now allow hospitals
and health centers to automatically admit and follow up the patients. We carried out this work
under the theme of: "Setting-up a hospital information system (HIS) for the automation
of the process of admission and follow-up of patients in health establishment". This
solution aims to improve the quality of care in the Cameroonian health system through IT. It
will now be possible, thanks to this software, to digitally store the information relating to the
passage of a patient in a health establishment in order to perpetuate the medical history of the
latter and to be able to use it if necessary to continue his treatment. So, we are experimenting
with electronic medical records.
Keywords: hospital information system, automation, admission process, follow-up, patient,

health establishment.
Rédigé Par Fabrice KEGOUM KOUEMO, Elève Ingénieur des Travaux Informatiques, IAI- i
Cameroun x
INTRODUCTION GENERALE
L'informatique ne cesse d'envahir les différents domaines des activités humaines. Cela
s'explique par son apport incontestable pour ceux qui l'utilisent. En effet, cet outil permet
entre autres l'automatisation des traitements, l'échange d'information soit en temps réel, soit
en différé, la conservation des données, l'exécution rapide des tâches, etc. Suite à tous ces
avantages, le domaine médical a jeté son dévolu sur ce puissant outil de traitement de
l’information afin de faciliter l’analyse des résultats et d’optimiser le processus de prise en
charge des patients. C'est ainsi que les systèmes d'information hospitaliers (SIH) ont
commencé à voir le jour. Au cours de notre stage chez Univers binaire Sarl, il nous a été
confié la tâche de réaliser un système d’information hospitalier, qui nous permis de mettre en
pratique nos connaissances académiques. Ce stage a été une opportunité pour nous
d’appréhender le fonctionnement d’une entreprise informatique et de nous familiariser avec le
monde professionnel. Nous avons effectué ce stage sous le thème de : « Mise sur pied d’un
système d’information hospitalier (SIH) d’automatisation du processus d’admission et
de suivi des patients dans un établissement de santé ». Le présent document permet
d’appréhender et de mieux cerner ce sujet. Nous allons présenter à travers le dossier
d’insertion la structure d’accueil où notre stage a été effectué, ensuite nous présenterons les
différents documents projets intervenant, à savoir le cahier de charge, le dossier d’analyse et
de conception, le dossier de réalisation et enfin le guide d’utilisation de notre solution.
Rédigé Par Fabrice KEGOUM KOUEMO, Elève Ingénieur des Travaux Informatiques, IAI- 1
Cameroun
PARTIE I : PHASE D’INSERTION
La phase d’insertion est la partie du rapport de stage qui présente la structure

d’accueil, son fonctionnement et les conditions dans lesquelles nous avons été accueillis.
C’est également la phase où le stagiaire se familiarise avec les locaux de la structure dans
laquelle il effectue le stage jusqu’au choix du thème de stage.
Cameroun
DOSSIER I : DOSSIER D’INSERTION
Aperçu
INTRODUCTION
I. ACCUEIL EN ENTREPRISE
II. PRESENTATION DE L’ENTREPRISE
CONCLUSION
Cameroun
INTRODUCTION
Une fois que notre demande de stage académique ait été agréée, nous sommes amenés
à nous présenter à l’entreprise d’accueil afin de prendre connaissance des conditions
auxquelles nous serons soumis durant le déroulement de notre stage. Le dossier d’insertion
nous permet donc, dans un premier temps, de vous raconter notre accueil en entreprise et dans
un second temps de vous présenter l’entreprise d’accueil, qui pour nous est Univers Binaire
SARL.
I. ACCEUL EN ENTREPRISE
C’est en date du 05 Juillet 2022 que nous sommes arrivés dans les locaux de Univers
Binaire. Nous avons été accueillis par le directeur de la structure, M. GAPIAPSI NGUETO
Martial, qui après un bref entretien, nous a fait visiter la structure et nous a donné les horaires
pour effectuer le stage. Le lendemain, dès notre arrivée à 8h 00, nous avons été présentés aux
différents membres du personnel et confiés au responsable du service de développement qui
s’est assuré de notre intégration dans la structure. Aussitôt nous avons commencé avec
l’apprentissage des langages de programmation tels que le SQL, le PHP, etc. A l’issu de cet
apprentissage, il nous a été confié la tâche de développer une application de gestion de centre
de santé, d’où le choix du thème : « Mise sur pied d’un système d’information hospitalier
d’automatisation du processus d’admission et du suivi des patients dans un
établissement de santé ».
II. PRESENTATION D’UNIVERS BINAIRE SARL

II.1. Historique
C’est pendant son cycle au collège que le fondateur, M. GAPIAPSI NGUETO Martial,
Ingénieur informaticien en Systèmes et Réseaux a eu la vision et l’initiative de mettre en place
une entreprise. Ce rêve qu’il entretient depuis si longtemps ne deviendra réalité que le 7
décembre 2014 avec la naissance d’UNIVERS BINAIRE SARL.
Cameroun
II.2. Situation géographique

Univers Binaire Sarl est située à Awae Escalier plus précisément à l’entré IFTIC-SUP
juste avant l’IAI-Cameroun. Elle est plus facilement localisée avec le schéma ci-dessous.
Figure 1 : plan de localisation d'UNIVERS BINAIRE SARL
Source : Archive de l’entreprise
II.3. Mission
UNIVERS BINAIRE SARL est une société qui s’est donnée pour mission de résoudre
au quotidien les problèmes que rencontrent les différentes entreprises liées à l’informatique ou
quel que soit le domaine d’activité. Elle assure et délivre des attestations de formation et/ou
de certification des personnes désirant améliorer leur savoir en informatique.
Cameroun
II.4. Activités et réalisations

UNIVERS BINAIRE SARL a pour but principal innover, afin d’apporter de nouvelles
solutions tout en garantissant la satisfaction de sa clientèle. Ceci se matérialise sur le terrain
par :
 Le développement des applications,

 L’hébergement des sites web,
 Les formations certifiées (CISCO, JAVA, LPI,…),
 La réalisation des taches réseau (services réseaux, installation et configuration
des services réseau)
 La vente du matériel informatique
 La maintenance informatique.
Comme exemple de tâches accomplies, nous pouvons mettre en exergue :
 L’application UB BOOKING pour la gestion des agences de voyage fonctionnant

déjà en ligne
 L’application UB SCHOOL pour la gestion des lycées et collèges fonctionnant déjà
en ligne
 L’application UB STOCK pour la gestion des stocks ;
 L’application UB HOTEL pour la gestion hôtelière ;
 L’application UB RESTO pour la gestion du restaurant ;
 L’application PROTEX pour la gestion du budget communale ;
 Badge des taximen et ceux du personnel et des stagiaires ;
 Sites web tels que www.sotcocogsa.com, cam3a.org… ;
 Application de gestion des droits Universitaires.
Cameroun
II.5. Organisation et fonctionnement de la structure

II.5.1. Organigramme
Figure 1 : organigramme Univers Binaire Sarl
II.5.2. Présentation de la division de développement

C’est en quelques sortes le cœur de l’entreprise car presque tous les projets y passent
pour la réalisation. Cependant il est chargé :
 De La conception et de la réalisation des cahiers de charges techniques ;

 De la veille au respect des applications des normes dans l’entreprise ;
 De la conception et de la validation des produits crées par les équipes sous-
jacentes ;
 De la rédaction des contenus de formations et du don des enseignements dans
le centre de formation.
Cameroun
II.6. Les partenaires

Jeune structure de son état, UNIVERS BINAIRE SARL afin de mieux satisfaire sa
clientèle s’accroche à plusieurs partenaires tels que :
 MAMESCAM SERVICE : imprimerie,

 WEBCOM SERVICE : prestation de services web,
 KEMBUY : E-Commerce,
 KILOS EXPRESS : envoi et réception des colis.
II.7. Ressources matérielles et logicielles

Univers Binaire Sarl dispose pour son fonctionnement de nombreux équipements pour un
service fiable, rapide et efficace.
II.7.1. Ressources matérielles
Tableau 1 : ressources matérielles d'Univers Binaire Sarl
Equipements Marque Quantité

Ordinateur de bureau HP, DELL, IBM 13
Ordinateurs portables Acer, Lenovo, HP, DELL 7
Routeurs D-Link 2
Switch D-Link 1
Onduleurs Dac 6
Caisse de matériel 3
dialectique de maintenance
Scanner LG 1
Imprimantes HP 4
Projecteurs vidéo HP 2
Cameroun
II.7.1. Ressources logicielles

UNIVERS BINAIRE SARL dispose de plusieurs ressources logicielles lui permettant
d’effectuer ses différentes tâches quotidiennes. Il s’agit notamment de :
 Les systèmes d’exploitation tels que Debian 6.0 et Windows 10

 Les logiciels d’application tels que Microsoft 2013 pour le traitement de texte
 Les IDE pour le développement logiciel tels que NetBeans
 Le SGBD MySQL
CONCLUSION
La période d’insertion nous a permis de nous accommoder à l’environnement

professionnel de cette entreprise. La disponibilité du maitre de stage et l’accueil chaleureux
nous ont permis une facilité d’adaptation dans ladite entreprise.
Cameroun
PARTIE II : PHASE TECHNIQUE
Apres la prise de connaissance du thème, cette partie a pour but principal la

description des besoins d’utilisateurs ainsi que des conditions nécessaires à la réussite de notre
projet. C’est pour cette raison que cette partie est considérée comme outil de description du
projet pour éviter la production des résultats inadéquats.
Aperçu
INTRODUCTION
I. DOSSIER I : CAHIER DES CHARGES

II. DOSSIER II : DOSSIER D’ANALSE
III. DOSSIER III : DOSSIER DE CONCEPTION
IV. DOSSIER IV : DOSSIER DE REALISATION
V. DOSSIER V : GUIDE D’UTILISATION
CONCLUSION
Cameroun 0
INTRODUCTION
La phase technique est la partie du rapport de stage ayant pour but principal la
description des besoins d’utilisateurs ainsi que des conditions nécessaires à la réussite du
projet acquis par l’étudiant après son insertion au sein de son entreprise d’accueil. C’est pour
cette raison que cette partie est considérée comme outil de description du projet pour éviter la
production des résultats inadéquats. Une fois installé au sein d’univers binaire et ayant déjà
des projets à notre disposition, nous avions pour devoir d’apporter des solutions de réalisation
à ces projets. Pour une bonne présentation de notre travail nous avons articulé comme suit :
nous aurons en premier la phase d’analyse, par la suite les phases de conception, de
réalisation, le guide d’utilisation et en fin les difficultés rencontrées.
Cameroun 1
DOSSIER II : CAHIER DES CHARGES
Apres la prise de connaissance du thème, cette partie a pour but principal la

description des besoins d’utilisateurs ainsi que des conditions nécessaires à la réussite de notre
projet. C’est pour cette raison que cette partie est considérée comme outil de description du
projet pour éviter la production des résultats inadéquats.
Aperçu
INTRODUCTION
I. CONTEXTE ET JUSTIFICATION DU PROJET

II. LES OBJECTIFS DE PROJET
III. SPECIFICATION DES BESOINS
IV. ESTIMATION DU COUT DU PROJET
V. PLANIFICATION DU PROJET
VI. LES CONTRAINTES DU PROJET
VII. LES LIVRABLES
CONCLUSION
Cameroun 2
INTRODUCTION
Document contractuel préalablement établit de commun accord entre le maitre
d’œuvre et le maitre d’ouvrage, le cahier de charge doit être scrupuleusement respecté lors de
la réalisation d’un projet. En effet, la réussite d’un projet passera impérativement par la
définition écrite, détaillée, précise, exhaustive et évaluable du besoin, d’où l’importance
majeur du cahier de charges. D’une manière générale, il permet de formaliser les besoins et de
les expliciter aux différents acteurs afin de s’assurer que tout le monde est d’accord. Il
regroupe donc le contexte et la justification du projet, les objectifs, l’expression des besoins
de l’utilisateur, l’estimation du cout, la planification, les contraintes et les livrables.
I. CONTEXTE ET JUSTIFICATION DU PROJET

La population camerounaise est en constante augmentation depuis plusieurs décennies.
Ce qui incombe à des structures telles que les centres de santé de stocker et de traiter de
grandes quantités d’informations. Malgré les avancées technologiques et l’avènement de
l’informatique qui offre un excellent moyen de stockage et de pérennisation de l’information,
ces derniers n’en demeurent pas moins réfractaires face à cet outil. C’est ainsi qu’il est
difficile, voire impossible pour un centre de santé de recouvrer les antécédents médicaux d’un
patient après que celui-ci ait perdu son carnet médical. Cette carence informatique dans le
système sanitaire camerounais est l’un des facteurs entrainants la détérioration de la qualité
des soins.
II. LES OBJECTIFS DU PROJET

II.1. Objectif global
Cette étude s’inscrit dans la volonté de conduire un travail pour contribuer à améliorer
la qualité des processus de soins et des prestations hospitalières. Cette amélioration devra
bénéficier des moyens modernes de traitement de l’information, du management éclairé et de
la synergie de tous les acteurs. Dans ce cadre, l’informatisation des processus est un facteur de
qualité et doit apporter sa contribution à cette amélioration. Ainsi, améliorer la qualité des
soins et des prestations hospitalières est notre but principal.
Cameroun 3
II.2. Objectifs spécifiques

D’une façon plus directe à travers notre plateforme plusieurs opérations sont
susceptibles d’être effectués telles que :
 Mettre en place un outil SIH culturellement et économiquement supportable.

 Stimuler la culture informatique en santé au Cameroun.
 Réduire le flux du papier et expérimenter le dossier patient électronique.
 Améliorer la gestion médico-économique et la rendre plus efficace.
 Rendre disponible des statistiques hospitalières fiables.
 Développer un module de facturation, adapté pour le contexte du Cameroun, qui
pourrait être intégré au système d’information hospitalier cible.
 Stimuler l’introduction de la codification médicale conforme aux référentiels
internationaux et pouvant déboucher sur un programme de médicalisation type PMSI
(Programme de Médicalisation des Systèmes d’Information). Par ailleurs, cette
démarche permet de développer la culture de la codification uniforme, en utilisant des
référentiels utilisés dans d’autres systèmes à visée épidémiologique notamment.
III. SPECIFICATION DES BESOINS

III.1. Besoins fonctionnels
Il s’agit d’un ensemble de fonctionnalités capitales pour le système à considérer pour
la bonne marche de ce dernier. Dans notre contexte, la plateforme que nous mettrons en place
devra comporter les fonctionnalités et modules suivants :
III.1.1. Module « PATIENT »

Au moyen de ce module, il sera possible de mémoriser et disposer à tout moment de la
liste des patients de l’hôpital. Cette liste figurera au nombre des indicateurs qui permettent
aux responsables de l’hôpital d'estimer l'intérêt que les populations camerounaises accordent
aux services offerts par l’établissement hospitalier.
En effet, ce module permettra :
 D’enregistrer un patient ;
 De rechercher un patient ;
Cameroun 4
 De modifier les données administratives (identité + contacts) d'un patient ;

 De consulter la liste des patients ;
 De transmettre les informations administratives du patient au module « Admissions ».
III.1.2. Module « ADMISSIONS »

C'est grâce à ce module que la gestion automatisée des différentes admissions devient
effective. En effet, il sera chargé de gérer :
 L’inscription des patients aux différentes consultations externes ;
 L’hospitalisation des patients.
Il identifiera de façon unique chaque admission : tous les services (consultations,
examens, hospitalisations, transferts) offerts au patient sont liés à une admission.
Il est subdivisé en sous-modules :
 Soins ambulatoires ;
 Hospitalisations ;
 Infirmerie.
 Sous-module « Soins ambulatoires »
Il permet le suivi des inscriptions des patients aux différentes consultations externes.
Notons qu'un patient dont l'état de santé ne nécessite pas qu'il soit hospitalisé est appelé
« Patient ambulatoire ou externe ». La gestion des admissions des patients ambulatoires est
effectuée par ce sous-module du module « Admissions ».
Ses fonctions principales sont les suivantes :
• admettre un patient ambulatoire ;
• enregistrer les données médicales (diagnostics, examens, etc.) d'un patient
ambulatoire
• consulter les éventuelles anciennes admissions en soins ambulatoires du patient ;
• connaître les éventuels antécédents médicaux du patient ambulatoire ;
• transférer le patient ambulatoire d'un département (domaine de consultation) à l'autre
: par exemple, transférer un patient, préalablement admis en cardiologie, en neurologie
• consulter la liste des patients ambulatoires ;

• soumettre les demandes d'examen éventuelles du patient ambulatoire au module
« LABORATOIRE » ;
• disposer des résultats des éventuels examens du patient hospitalisé ;
Cameroun 5
• libérer un patient ambulatoire : l'admission en cours est alors archivée.
 Sous-module « Hospitalisation »
Il consiste en la gestion des hospitalisations. Son objectif global est le bon suivi des
épisodes des hospitalisations des patients depuis leur arrivée à l'hôpital jusqu'à leur sortie.
Dans le cas des hospitalisations, le patient est qualifié de « patient hospitalisé ou
interne ».
Ce sous-module permet :
• d'admettre un patient en hospitalisation ;
• de rechercher un patient hospitalisé ;
• de connaître la période d'hospitalisation d'un patient donné ;
• d'enregistrer les données médicales du patient hospitalisé ;
• de consulter les éventuelles anciennes hospitalisations d'un patient donné ;
• de connaître l'historique médicale du patient hospitalisé ;
• de consulter la liste des patients hospitalisés ;
• de soumettre les demandes d'examen éventuelles du patient hospitalisé au module
« LABORATOIRE » ;
• de disposer des résultats des éventuels examens du patient hospitalisé ;
• de libérer un patient hospitalisé.
 Sous-module « Infirmerie »
Ce sous-module et le sous-module « Hospitalisations » sont d'une manière ou d'une

autre interdépendants. En effet, la gestion des infrastructures dédiées aux hospitalisations
incombe au sous-module « Infirmerie ». Ceci étant, son rôle consiste à :
• créer une salle d'hospitalisation ;
• enregistrer les informations relatives aux lits se trouvant dans une salle
d'hospitalisation ;
• rechercher une salle d'hospitalisation ;
• consulter la liste des salles d'hospitalisation ;
• affecter un patient hospitalisé à un lit d'une salle d'hospitalisation donnée ;
• transférer un patient hospitalisé d'une salle à une autre ;
• transférer un patient hospitalisé d'un lit à un autre ;
Cameroun 6
• savoir exactement où (salle et lit) est hospitalisé un patient donné ;

• connaître pour chaque salle, le nombre de :
- Lits ;
- Lits occupés ;
- Lits libres.
• mettre un lit hors usage ;
• fermer temporellement une salle d'hospitalisations ;
• fermer définitivement une salle d'hospitalisations.
III.1.3. Module « Facturation »

Les fonctionnalités de ce module sont les suivantes :
 Créer automatiquement la facture du patient dès son admission ;
 Enregistrer les prix des différents consultations et examens ;
 Enregistrer le loyer journalier d'une salle d'hospitalisation ;
 Facturer de façon automatique chaque prestation (consultation, examen,
hospitalisation) dont a bénéficié le patient ;
 Consulter le prix d'une consultation ou d'un examen ;
 Modifier le prix d'une consultation ou d'un examen ;
 Consulter le loyer journalier d'une salle d'hospitalisation donnée ;
 Modifier le loyer journalier d'une salle d'hospitalisation donnée ;
 Visualiser les prix de tous les consultations et examens ;
 Visualiser les loyers de toutes les salles d’hospitalisation ;
 Rechercher la facture d'un patient donné ;
 Consulter la liste de toutes les factures ;
 Obtenir les détails sur une facture donnée ;
 Régler une facture donnée.
Cameroun 7
III.1.4. Module « Gestion automatisée des rendez-vous »

Le bon suivi des rendez-vous pris par les patients constitue la tâche principale de ce
module. Il permet plus précisément :
 D’enregistrer les rendez-vous d'un patient ;
 De visualiser les rendez-vous d'un patient donné ;
 De modifier un rendez-vous donné ;
 De consulter les rendez-vous pris pour une date donnée ;
 De connaître les rendez-vous pris dans un département (cardiologie, gynécologie,
etc.);
 De connaître les rendez-vous pris avec un médecin donné ;
 D’obtenir l'historique des rendez-vous.
III.1.5. Module « Calendrier de consultation des médecins »

Il permet une bonne gestion des planifications des consultations des médecins
intervenant à l’hôpital. Ses fonctions essentielles consistent à :
 Programmer un médecin ;
 Modifier une programmation ;
 Rechercher les jours de consultation pour un type de consultation donné (cardiologie,
pneumologie, médecine générale, etc.) ;
 Rechercher les jours de consultation d'un médecin donné ;
 Savoir quel médecin consulte dans un domaine (dermatologie, ORL, etc.) identifié ;
 Visualiser tout le calendrier des consultations.
III.1.6. Module « Système d'alerte »

A travers ce module, il est possible de :
 Connaître de façon automatique les différents risques encourus par le patient :
Surcharge pondérale (obésité), diabète, hypertension artérielle, hypercholestérolémie,
insuffisance calorifique, etc. L'évaluation de ces risques s'effectue sur la base des facteurs de
risque : âge, sexe, poids, taille, taux de glycémie, pression artérielle, rythme cardiaque, etc.
(m)
 Connaître de façon automatique le calendrier vaccinal d'un patient (quand un vaccin

donné doit-il être administré au patient ?) ;
Cameroun 8
 Savoir si un traitement donné n'est plus efficace ;

 Prévoir une épidémie.
III.1.7. Module « LABORATOIRE »
Il constitue l'interface entre le système et les automates biomédicaux (appareils des
laboratoires) de l’hôpital, dont la connexion à un système informatique est possible. En effet,
c'est lui qui est à mesure, au moyen d'un protocole, de communiquer avec les automates : il
comprend les messages qu'il reçoit de l'automate et ses requêtes sont également comprises par
l'automate.
Le protocole est l'ensemble des conventions nécessaires pour établir et entretenir des
échanges d'informations entre ces deux entités (LABORATOIRE et automates).
L'objectif principal du module « LABORATOIRE » est de permettre un suivi efficient
des examens réalisés dans les laboratoires (Biochimie, Hématologie, etc.) de l’hôpital. C'est
ce module qui est chargé de la gestion de l'activité du plateau technique. En effet, il consiste
à:
 Transmettre les demandes d'examen, provenant du module « Admissions », aux
automates concernés ;
 Permettre la réception automatique des résultats d'un examen provenant d'un
automate donné ;
 Autoriser une éventuelle acquisition manuelle (saisie) des résultats d'un examen
dans le cas où la communication directe avec l'automate rencontrerait des
problèmes (pour une raison ou une autre) ;
 Mettre ces résultats à la disposition du médecin de laboratoire pour validation ;
 Traiter ces résultats, après leur acquisition et validation (après cette étape, les
résultats sont exploitables par un spécialiste : médecin) ;
 Transmettre les résultats traités au module « Admission » (module demandeur).
III.1.8. Module « Administration du système »

L'administration de l’hôpital incombe à ce module. Ce module est constitué de deux
sous-modules :
 Sous module gestion des utilisateurs
Ce sous-module permet de :
• de créer un utilisateur ;
Cameroun 9
• d'accorder des droits d'accès à un utilisateur ;

• de rechercher un utilisateur ;
• de consulter les droits d'accès d'un utilisateur ;
• de modifier les droits d'accès d'un utilisateur ;
• de verrouiller les droits d'accès d'un utilisateur : dans ce cas l'utilisateur ne pourra
accéder au système que lorsque ses droits seront déverrouillés ;
• de supprimer un utilisateur du système ;
• d'administrer la base de données de l’hôpital ou clinique ;
• de paramétrer le système.
 Sous module gestion des accès au système »
Il utilise certaines informations du module « Administration du système ». C'est ainsi
qu'il se base sur ces informations pour :
• vérifier si l'utilisateur qui cherche à accéder au système, a été préalablement créé ;
• offrir à l'utilisateur, au cas où il est identifié, les modules et/ou opérations
auxquels il peut accéder (en fonction des droits d’accès).
En outre, ce module est chargé :
• de garder les traces des différentes connexions (Journal des connexions) au système ;
• de déconnecter de façon automatique (pour des raisons de sécurité) l'utilisateur
lorsqu'une longue période d'inactivité (le délai minimum est fixé au niveau du
paramétrage du système) ;
• de permettre à l'utilisateur de se déconnecter, de façon volontaire, du système.
Rappelons que ce module joue un rôle non négligeable dans la sécurisation du
système.
III.1.9. Module « Accessoires »

Il constitue l'ensemble des services transversaux du système. Ce module est composé
essentiellement du sous-module « Messagerie Intranet ». Cependant, il pourra intégrer par la
suite d'autres sous-modules.
« Messagerie Intranet » offrira un service de messagerie électronique limité au réseau de

l’hôpital. En effet, il permettra :
• seulement à ceux qui ont accès au réseau de l’hôpital, de communiquer entre eux via
des messages électroniques ;
Cameroun 0
• aux employés d'un département donné (cardiologie, radiologie, comptabilité, etc.) de

s'échanger des messages électroniques.
Modules restants : Comptabilité (entrées et sorties de l’hôpital), Pharmacie, Accueil.
III.1.10. Module « PHARMACIE »
Ce module devra être constitué des sous-modules et fonctionnalités suivants :
 Gestion des officines :

 Créer, mettre à jour le statut ou de supprimer une officine ;
 Lister les produits d’une officine donnée ou filtrer un produit dans cette
dernière.
 Gestion des produits et des ventes :

 Enregistrer, modifier et supprimer un produit ;
 Lister les produits en fonction des critères bien déterminés ;
 Permettre la recherche et présenter la fiche de stock d’un produit
quelconque ;
 Etablir et permettre l’impression des factures des ventes de produits ;
 Produire des statistiques sur l’évolution des ventes et de la
consommation des produits.
III.1.11. Module « Comptabilité »

 Etablir les bons de commande et des bons de réclamations ;
 L’état de chaque bon de commande et le personnel l’ayant établi ;
 Gérer le matériel de l’hôpital et de la pharmacie.
Cameroun 1
III.2. Besoins non fonctionnels

Les besoins non fonctionnels représentent les contraintes qui n’agissent pas sur le
comportement du système, mais qui touche sa forme. Ces besoins sont les suivants :
 La fiabilité : l’application doit fonctionner de façon cohérente sans erreurs et doit être
satisfaisante ;
 Sécurité et confidentialité : Dans le souci de garantir la sécurité de notre application
chacun des services de la structure devra faire enregistrer son login et son mot de
passe dans l’application de telle sorte qu’ils n’ont accès qu’à leurs propres interfaces et
pas celui d’un autre membre ;
 La disponibilité : L’application devra être accessible à tout moment selon les besoins
des utilisateurs ;
 La portabilité : C’est la capacité de l’application à exercer sur des plateformes et
environnements divers ;
 Aptitude à la maintenance et la réalisation : Le système doit être conforme à une

architecture standard et claire permettant sa maintenance et sa réalisation ;
 L’extensibilité : Dans le cadre de notre projet, notre application devra être extensible
c’est-à-dire avoir la possibilité d’ajouter ou de modifier les nouvelles fonctionnalités ;
 Ergonomie (convivialité) et interface : L’application sera conçue de façon à donner

du bien-être à l’utilisateur tant sur le plan de la forme que sur le plan du fond, ceci
avec la représentation des interfaces claires et soignées, la cohérence dans l’appel de
ces interfaces en fonction des besoins qui les nécessitent ;
 La fluidité de traitement : Il sera important que le système soit en mesure de traiter

les flux d’informations en toute souplesse et vitesse. Ceci pour avoir un rendement en
temps réels ;
 Le temps réel : Permettre à l’utilisateur de voir instantanément les résultats en

fonction des manipulations effectuées ;
 Simplicité d’utilisation.
Cameroun 2
IV. ESTIMATION DU COÛT DU PROJET

IV.1. Ressources humaines
La réalisation d’une telle application nécessite l’intervention d’un analyste concepteur
pour penser comment le système doit fonctionner, présenter les fonctionnalités possibles à
développer. De deux (2) designers pour concevoir un bon design des différentes interfaces de
l’application, de deux (2) développeurs (front end et back end) pour le développement de la
solution, d’un chef projet pour Contrôler l’avancement du projet.
Tableau 2 : ressources humaines
Rôle Nombre Durée de travail Montant par jour Montant total

(jours) de travail
Analyste concepteur 1 14 150 000 FCFA 2 100 000 FCFA
Chef de projet 1 35 250 000 FCFA 8 750 000 FCFA
Développeur 2 21 150 000 FCFA 6 300 000 FCFA
TOTAL 4 70 jours 17 150 000 FCFA
source : mercuriale des prix 2022
Cameroun 3
IV.2. Ressources matérielles
Tableau 3 : ressources matérielles
Matériels Quantité Prix unitaire Utilité Montant total
Laptop Core i5 5iem 6 600 000 FCFA Utilisé pour 3 600 000 FCFA
generation minimum développer
8Gb RAM l’application et
300GO SSD pour effectuer les

tests en locale
CLE USB 16GB 2 10 000 FCFA Utiliser pour le 20 000 FCFA
partage de fichier
DVD CDROM 1 600 FCFA Utilisé pour graver 600 FCFA
Disque Dur 1Tb 1 40 000 FCFA Utiliser pour les 40 000 FCFA
sauvegardes du
projet
TOTAL 3 660 600 FCFA
Source : mercuriale des prix 2022
Cameroun 4
IV.3. Ressources logicielles

Tableau 4 : Ressources logicielles
Logiciels Description Prix
Windows 10 version Système d’exploitation développé par Microsoft 100 000 FCFA
Permet d’héberger son application en locale Gratuit

Xampp
Chrome, Firefox Navigateur utilisé pour tester l’application Gratuit
Netbeans Project Interface de développement intégrée
Gratuit
Power AMC version 15 Logiciel d’atelier de génie logiciel dédié à la 20 000 FCFA
modélisation
GANTT Project Utilisé pour planifier les taches Gratuit
Microsoft Office 16 Suite Microsoft pour la bureautique 287 500 FCFA
Cameroun 5
TOTAL 407 500 FCFA
IV.4. Divers
Tableau 5 : Ressources diverses
Désignation Utilité Prix
Nom de domaine Permet d’avoir un espace chez un hébergeur afin de 100 000 /mois
déployer son application en ligne
Accès internet Pour faire des recherches et télécharger les logiciels 180 000 FCFA
Total 280 000 FCFA
V. ESTIMATION GLOBALE DU PROJET

Tableau 6 : Estimation globale du projet
RESSOURCES COUT
HUMAINES 17 150 000 FCFA
MATERIELLES 3 660 600 FCFA
LOGICIELLES 407 500 FCFA
DIVERS 280 000 FCFA
MARGE D’ERREUR (10%) 2 139 660 FCFA
Cameroun 6
VI. PLANIFICATION DU PROJET

La planification d'un projet est l'activité qui consiste à ordonnancer les tâches à
réaliser, qui ont été formalisées lors de la structuration du projet, estimer les charges
associées, déterminer les profils nécessaires à leur réalisation. La figure ci-dessous représente
la planification de notre projet selon le diagramme de GANTT.
Figure 2 : diagramme de planification (GANTT)
VII. LES CONTRAINTES DU PROJET

VII.1. Les contraintes de coût
Pour mener à terme la réalisation de notre projet, il sera indispensable de dépenser une
somme totale de 23 637 760 FCFA correspondant aux différentes ressources y intervenant.
VII.2. Les contraintes de délais

La réalisation de notre projet devra être effectuée sur une période s’étalant sur 10
semaines de travail allant du 15 juillet 2021 au 30 Septembre 2021.
Cameroun 7
VII.3. Les contraintes de qualités

L’application à réaliser devra respecter les caractéristiques suivantes :
 Ergonomique : c’est-à-dire que l’application à développer doit être intuitive, facile à

utiliser et avoir un bon visuel.
 Evolutive : des fonctionnalités doivent pouvoir être ajoutées à l’application sans qu’il
y ait forcément modification de chaque nœud de l’application.
 Sécurisée : Toutes les transactions effectuées sur l’application devront être protégées
le plus possible contre toute attaque extérieure.
 Multiplateforme : l’application à réaliser doit pouvoir être utilisée sur mobile,
tablette et sur pc.
VIII. LES LIVRABLES

A la fin de ce projet, nous devons fournir :
➢ Un document comprenant les dossiers suivants :
• Un dossier d’insertion,
• Un dossier d’analyse,
• Un dossier de conception,
• Un dossier de Réalisation,
• Un guide d’installation et d’utilisation de l’application

➢ Un DVD comportant :
• Le rapport de stage
• Le PowerPoint
• Le setup de l’application
Cameroun 8
IX. LES PRINCIPAUX INTERVENANTS DU PROJET

Tableau 7 : liste des intervenants
NOM ET PRENOM FONCTION RÔLE
Mme Maëva BELINGA Ingénieur des Travaux Conseillé technique

AKONO Informatiques
M. Martial GAPIAPSI Développeur d’application Maître d’ouvrage
NGUETO
M. Fabrice KEGOUM Etudiant Maître d’ouvre
KOUEMO
CONCLUSION
La rédaction d’un cahier de charge est une étape importante dans la conception d’un
projet informatique. Elle permet d’avoir un plan de travail pour le projet, de savoir les
différentes tâches à réaliser et de savoir exactement les modules à développer.
Cameroun 9
DOSSIER III : DOSSIER D’ANALYSE
L’analyse est primordiale dans tout projet informatique. Ici, nous allons décrire le
problème posé, présenter les limites et proposer des solutions, faire une étude comparative des
différentes méthodes d’analyse, présenter notre méthode d’analyse ainsi que tous les
diagrammes représentant les différentes fonctionnalités de notre solution
Aperçu
INTRODUCTION
I. RECEUIL DE L’EXISTANT
II. ETUDE COMPARATIVE DES METHODES ET LANGAGES DE
MODELISATION
III. PRESENTATION DE LA METHODE D’ANALYSE
IV. DIAGRAMMES D’ANALYSE
CONCLUSION
Cameroun 0
INTRODUCTION
L’analyse est la décomposition d’un problème en ses différentes composantes en vue

d’un traitement informatique. De ce fait, la réussite d’un projet dépend de son analyse car un
projet mal analysé ne saurait produire un bon résultat. L’analyse de notre projet sera
essentiellement basée sur la méthodologie UML. Les diagrammes intervenants dans cette
phase seront les diagrammes de cas d’utilisation, de séquence, d’activité, de communication et
d’état transition.
I. RECEUIL DE L’EXISTANT
I.1. Description de l’existant
Plusieurs descentes sur le terrain au Centre Médico-Chirurgicale REAVEN, qui a fait
l’objet de cette étude, nous ont permis de comprendre comment fonctionne un centre de santé
sans un logiciel de gestion hospitalière. D’abord les patients sont enregistrés dans des
registres et les informations relatives à l’état de santé de ces derniers sont enregistrées dans
des dossiers et des carnets qui sont détenus respectivement par l’hôpital et les patients. Les
résultats des examens sont remis au patient qui devra le présenter au médecin. Les médecins
doivent faire des rondes dans les salles afin de s’assurer que les soins ont été administrés. Le
stock de la pharmacie est géré manuellement. Aussi, la planification des soins et des rendez-
vous est faite manuellement et la comptabilité est tenue dans des registres, au mieux dans des
fichiers Excel.
Toutefois, Un logiciel de gestion hospitalière est le logiciel utilisé dans les hôpitaux
pour automatiser les processus, y compris la facturation, les rendez-vous, la planification, la
conformité réglementaire et les audits financiers au sein des hôpitaux. Il existe actuellement
dans le monde plusieurs logiciels capables d’effectuer ces tâches. Il s’agit notamment de :
Cameroun 1
I.1.1. eHospital Systems
eHospital Systems est un système de dossiers médicaux partagés (DSE) conçu

pour gérer tous les aspects des opérations d'un hôpital.
 Fonctionnalités :
 Planification des rendez-vous ;
 Gestion des réclamations ;
 Gestion des médecins ;
 Gestion des dossiers patients ;
 Gestion des patients hospitalisés ;
 Gestion des soins ambulatoire.
I.1.2. Smartsheet
Smartsheet est une plateforme d'exécution du travail en ligne qui permet aux
organisations de soins de santé de suivre, de gérer et de rendre compte des
informations en améliorant la collaboration, en assurant la sécurité des
données et en augmentant la visibilité.
 Fonctionnalités :
 Gestion des réclamations ;
 Gestion des médecins ;
 Gestion des dossiers patients.
I.1.3. athenaOne
Cameroun 2
athenaOne aide les médecins à prodiguer des soins de haute qualité en

organisant leur emploi du temps de soins pour une productivité clinique optimisée ; le logiciel
se charge des services administratifs et de qualité pour le médecin afin d'assurer un paiement
intégral, tout en faisant suivre toutes les ordonnances des médecins pour traiter l'ensemble du
processus, des résultats et des soins de suivi.
I.2. Critique de l’existant

La gestion manuelle des centres de santé entraine de nombreux problèmes tels que :
 La présence de grands volumes de papier qui rend la consultation des données

difficile. Ainsi il n’est pas évident de retrouver les antécédents médicaux d’un
patient après un certain nombre de temps ;
 Le manque de communication directe entre le personnel médicale (tout passe par
le patient) ;
 La difficulté de planifier des soins ainsi que les rendez-vous ;
 La pharmacie est souvent à court de produits nécessaires pour administrer un
soin ;
 La difficulté de suivre les patients hospitalisés et leur administrer des soins ;
 La détérioration de la qualité des soins
De plus, de tous les logiciels cités plus haut, il n’en existe aucun qui soit « made in
Cameroun ». Aussi, ce sont des logiciels dont l’acquisition entraine d’énormes coûts
financiers et ils ne sont pas très adaptés pour le contexte Camerounais. Ce qui justifie que nos
établissements de santé continuent de se gérer manuellement malgré la multitude de solutions
qui existe.
I.3. Problématique
L’un des gros avantages de l’informatique est la pérennisation de l’information. Offrant
de grands moyens de stockage, tout en facilitant le traitement, il devient le moyen le plus
indispensable pour stocker des informations sans courir le risque de perte. Du fait que la
gestion manuelle des établissements de santé ne soit pas évidente et que les logiciels
susmentionnés soient très couteux et pas très adaptés pour notre contexte, ne pouvons-nous
pas mettre sur pied un logiciel de gestion hospitalière accessible en coût et adapter à notre
Cameroun 3
contexte, devant permettre à nos établissements de santé d’automatiser la gestion de leur tâche
quotidienne ?
I.4. Proposition de la solution

Pour répondre à cette question, nous avons opté pour la « mise sur pied d’un système
d’information hospitalier (SIH) d’automatisation du processus d’admission et de suivi
des patients dans un établissement de santé ».
II. ETUDE COMPARATIVE DES METHODES ET LANGUAGES

DE MODELISATION
II.1. Généralité sur les méthodes d’analyses UML et MERISE
Une méthode définit une démarche reproductible qui produit des résultats fiables. Une
méthode d’élaboration d’application décrit comment modéliser et construire les systèmes
logiciels de manière fiable et reproductible. De manière générale, une méthode définie :
 Des éléments de modélisation ;
 Une représentation graphique ;
 Du savoir-faire et des règles.
Il existe plusieurs méthodes d’analyse, mais les plus utilisées sont MERISE et UML :
 MERISE (Méthode d’Etude et de Réalisation Informatique pour les Systèmes

d’Entreprise) est une méthode d'analyse, de conception structurelle et de
réalisation des systèmes d'information qui est élaborée en plusieurs étapes :
schéma directeur, étude préalable, étude détaillée et la réalisation.
 UML (Unified Modeling Language), est un langage de modélisation des systèmes

standards, qui utilise des diagrammes pour représenter chaque aspect d'un
système : statique, dynamique … en s'appuyant sur la notion d'orienté objet qui est
un véritable atout pour ce langage.
Cameroun 4
II.2. Etude comparative entre MERISE et UML

Tableau 8 : Etude comparative UML MERISE
MERISE UML
Méthode systématique d’analyse et de Langage de représentation d’un système

conception des systèmes d’information : d’information
Représentation sous forme de model Représentation sous forme de diagrammes
Approche systématique Approche Objet
Franco-Français Internationale
Propose de considérer le système réel selon Propose une approche différente en ce sens
deux aspects : qu’elle associe les données et les traitements.
Une vue statique (données) Avec UML, les données d’un type et les
Une vue dynamique traitements associés
Avec MERISE, nous avons une étude UML permet de limiter les points de
séparée des données et des traitements maintenances dans le code et facilite l’accès à
l’information en cas d’évolution
Cameroun 5
Schéma directeur, étude préalable, Etude Langage de modélisation des systèmes

détaillée et la réalisation standards, qui utilise des diagrammes pour
représenter chaque aspect d’un système :
statique, dynamique… en s’appuyant sur la
notion d’orienté objet
III. PRESENTATION DE LA METHODE D’ANALYSE

III.1. Choix de la méthode d’analyse
Au regard de la complexité croissante des systèmes d’informations et de cette étude
comparative, UML est le mieux adapté dans le cadre de notre projet. UML est un langage
unifié de modélisation qui permet de spécifier, visualiser, construire et documenter de
manière précise un système d’information. UML grâce à ses langages offre une description
statique, dynamique et fonctionnelle du système à réaliser en plus il est idéal pour :
 Concevoir et déployer une architecture logicielle développée dans un langage

objet. Certes UML, dans sa volonté "unificatrice" a proposé des formalismes ;
 Pour modéliser les données (le modèle de classe réduit sans méthodes et stéréotypé
en entités), mais avec des lacunes que ne présentait pas l'entité relation de Merise ;
 Pour modéliser le fonctionnement métier (le diagramme de cas d'utilisation) qui est
un formalisme très ancien.
III.2. Présentation de UML

La principale avancée des 15 dernières années réside dans la POO (programmation
orientée objet). Face à ce nouveau mode de programmation, les méthodes de modélisation
classiques tel que MERISE ont rapidement montré certaines limites et ont dû s’adapter. Dans
ce contexte, l’Object management group (OMG) a eu pour objectif de définir une notation
standard utilisable dans le développement informatique basé sur l’objet. C’est ainsi que nait
UML qui est issue de la fusion des langages BOOCH, OMT et OOSE.
III.2.1 Version
La version d’UML que nous allons utiliser dans notre projet est la version 2.4 qui
présente 14 diagrammes.
Cameroun 6
Figure 3 : diagramme UML version 2.5
Source : www.umlchanel.com
III.2.2. Les diagrammes d’UML

La modélisation d’un projet informatique effectué à l’aide d’UML version 2.5 présente
14 diagrammes. Ces diagrammes sont regroupés de la manière suivante :
 Diagrammes comportementaux : Diagramme de cas d’utilisation, d’activité,

diagramme d’état transition et des diagrammes d’interactions (diagramme de
séquence, de communication, le diagramme global d’interaction, le diagramme de
temps).
 Diagrammes structurels : Diagramme de classe, diagramme de composants,
diagramme d’objets, diagramme de profils, diagramme de structure composite,
diagramme de déploiement et le diagramme de paquetages.
Cameroun 7
III.2.3. Formalisme
UML se décompose en plusieurs sous-ensembles :
 Les vues : Les vues sont les observables du système. Elles décrivent le système
d’un point de vue donné, qui peut être organisationnel, dynamique, temporel,
architectural, géographique, logique. En combinant toutes ces vues, il est
possible de définir (ou retrouver) le système complet.
 Les diagrammes : Les diagrammes sont des éléments graphiques. Ceux-ci
décrivent le contenu des vues, qui sont des notions abstraites. Les diagrammes
peuvent faire partie de plusieurs vues.
 Les modèles d’élément : Les modèles d’élément sont les briques des
diagrammes
UML, ces modèles sont utilisés dans plusieurs types de diagrammes à l’exemple des
cas d’utilisation, des classes, des associations.
III.2.4. Les vues

Les différentes vues d’UML sont les suivantes :
 Vue des cas d’utilisation : C’est la description du modèle vu par les

acteurs du système. Elle correspond aux besoins attendus par chaque acteur
(c’est le QUOI et le QUI).
 Vue logique : C’est la définition du système vu de l’intérieur. Elle explique
comment peuvent être satisfaits les besoins des acteurs (c’est le
COMMENT).
 Vue d’implémentation : Cette vue définit les dépendances entre les
modules.
 Vue des processus : C’est la vue temporelle et technique, qui met en œuvre
les notions de tâches concurrentes, stimuli, contrôle, synchronisation, etc.
 Vue de déploiement : Cette vue décrit la position géographique et

l’architecture physique de chaque élément du système (c’est le OÙ).
Cameroun 8
III.2.5. Présentation du processus 2TUP

Un processus définit une séquence d’étapes ordonnées qui concours à l’obtention d’un
système logiciel ou à l’évolution d’un système existant. L’objet d’un processus de
développement est de produire des logiciels de qualité qui répondent aux besoins de leurs
utilisateurs dans des temps et des coûts prévisibles. Le 2TUP (Two Track Unified Process) est
un processus de développement logiciel qui implémente le processus unifié. Il propose un
cycle de développement qui dissocie les aspects techniques des aspects fonctionnels. Il s’agit
de l’étude de l’application et de son implémentation. Le processus 2TUP s’articule autour de
trois branches à savoir :
 Une branche fonctionnelle : Elle produit le modèle des besoins focalisés sur le métier
des utilisateurs. Elle permet de visualiser au plus tôt le risque de produire un système
inadapté aux utilisateurs.
 Une branche Technique : Elle Recense toutes les contraintes sur les choix de
dimensionnement et la conception du système, les outils et le matériel sélectionné
ainsi que la prise en compte des contraintes d’intégration avec l’existant. Cette étape
permet de définir le modèle d’analyse technique.
 Une branche de réalisation : La phase de réalisation consiste à réunir les deux
branches, permettant de mener une conception applicative et enfin la livraison d’une
solution adaptée aux besoins.
Ceci illustré à travers la figure suivante :
Cameroun 9
Figure 4 : représentation du processus 2TUP
Source : www.umlchanel.com/image/2TUP
Cameroun 0
IV. DIAGRAMMES D’ANALYSE

IV.1. Diagrammes de cas d’utilisation
IV.1.1. Définition
Le diagramme de cas d’utilisation identifie les fonctionnalités fournies par le
système, les utilisateurs qui interagissent avec le système, et les interactions entre ces
derniers. Les cas d’utilisations sont utilisés dans la phase d’analyse pour définir les acteurs de
haut niveau du système. Les principaux objectifs d’un diagramme de cas d’utilisation sont les
suivants :
 Fournir une vue de haut niveau de ce que fait le système ;
 Identifier les utilisateurs (acteurs) du système ;
 Déterminer des secteurs nécessitants des interfaces homme-machine.
IV.1.2. Formalisme
Dans un diagramme de cas d’utilisation on retrouve les éléments suivants :
Tableau 9 : éléments d'un diagramme de cas d'utilisation
REPRESENTATION NOM DESCRIPTION
Utilisateurs qui interagissent avec un système.

Un acteur peut être une personne, une
organisation ou un système externe qui interagi
Acteur avec votre application ou votre système. Il s'agit
nécessairement d'objets externes qui produisent
ou consomment des données.
Cas d’utilisation Représente les différentes applications possibles
pour un utilisateur.
Cameroun 1
Séquence spécifique d'actions et d'interactions

entre les acteurs et le système. Un système peut
également être appelé scénario.
Système
Lignes reliant les acteurs aux cas d'utilisation.

Dans les diagrammes complexes, il est
Association
important de pouvoir identifier les acteurs
associés à chaque cas d'utilisation.
Les relations sont utilisées pour lier les cas

d’utilisation entre eux. Elles permettent de
Relation
définir quel cas d’utilisation dépend de l’autre
(relation
<<include>> ou d’inclusion) ou encore quel
cas d’utilisation est une possibilité étendue d’un
autre (relation <<extend>> ou d’extension).
Les relations sont représentées par une flèche à
trait interrompu allant d’un cas d’utilisation à un
autre.
Les généralisations sont utilisées pour lier les
acteurs entre eux. Elles permettent de dire qu’un
Généralisation
acteur effectue tous les cas d’utilisation d’un
autre en plus de ce qu’il peut faire. Cette
relation est aussi appelée relation d’héritage.
Les généralisations sont représentées par une
flèche allant d’un acteur (celui qui hérite) à un
autre.
Cameroun 2
IV.1.3. Diagrammes de cas d’utilisation de la solution

IV.1.3.1. Diagramme de cas d’utilisation global du système
Figure 5 : diagramme de cas d’utilisation global du système
use case global <<include>>

gérer les patients
<<include>>
Gérer les factures
receptionniste
<<include>>
gérer les décaissements
caissier
<<include>>
gérer les produits
pharrmacien <<include>>
gérer les patient hospitalisés
infirmier
voir la liste des examens

<<include>>
<<include>>
laborentin renseigner resultat des examens Authentificarion
voir resultat des examens

<<include>>
médecin <<extend>>
effectuer une prescription
effectuer une consultation <<include>>
consulter les
<<include>>
transactions
Administrateur
gérer le personnel
<<include>>
Cameroun 3
Figure 6 : diagramme de cas d'utilisation gérer patient
IV.1.3.2. Diagramme de cas d’utilisation « gérer patient »
ajouter un patient
lister les patients
<<include>>
authentification
<<extend>>
gestion des patients <<include>>

receptioniste
gérer le dossier du
patient
<<extend>>
<<extend>>
modifier les
informations d'un
patient
ajouter les paramètres
du patient
Cameroun 4
IV.1.3.3. Diagramme de cas d’utilisation « effectuer une consultation »
Figure 7 : effectuer une consultation
<<extend>>
choisir une salle
prescrire une
hospitalisation
<<extend>>
<<extend>> choisir un lit
effectuer une consultation effectuer une

prescription
médecin
<<extend>>
<<extend>>
prescrire des
prescrire une examens
ordonnance
Authentification
Cameroun 5
IV.1.3.4. Diagramme de cas d’utilisation « gérer les patients hospitalisés »
Figure 8 : gérer les patients hospitalisés
<<extend>>
voir liste des patients hospitalisés
<<include>>
s'authentification
gérer les patients
hospitalisés
infirmier
marquer l'administration
<<extend>>
d'un soin
<<extend>> voir les paramètres d'un patient

hospitalisé
IV.1.3.5. Diagramme de cas « gérer les facture »
Cameroun 6
Figure 9 : diagramme de cas « gérer facture »
Systèm
payer un
facture
<<entend>>
lister les factures
impayées
<<entend>>
lister les reçus
d'une facture
Gérer les factures <<include>>
lister toutes
les factures
Caisse
Authentifier
Ajouter un
<<entend>> décaissement
Gérer les
<<include>>
décaissement
<<entend>> Modifier un
décaissement
Cameroun 7
IV.1.3.6. Diagramme de cas d’utilisation « gérer les produit »
Figure 10 : diagramme de cas d'utilisation "gérer les produit "
System
<<extend>>
modifier un produit
<<include>>
Authentification
gérer les produits
<<extend>>
Pharmacien
<<extend>>
supprimer produit
Ajouter
produit
Cameroun 8
Figure 11 : diagramme de cas d'utilisation "gérer personnel"

IV.1.3.7. Diagramme de cas d’utilisation « gérer personnel »
use case pesonnel

créer un compte
personnel
lister pesonnels
Ajouter
personnels
<extend>
Gérer Authentification
personnels
<include>
Chef du centre
<extend>
<extend>
Modifier
personnel
Activé /
Désactivé.
Cameroun 9
IV.1.3.8. Description textuelle de quelques cas d’utilisation
Tableau 10 : description textuelle du cas d'utilisation s'authentifier
Description du cas « s’authentifier »
Cas d’utilisation S’authentifier
Acteur Réceptionniste, caissier, pharmacien, infirmier, laborantin,

médecin, administrateur
Evènement déclencheur Clic sur le bouton de connexion
Intérêt Ce cas d’utilisation permet à un acteur du système qui n’est pas

connecter au système de s’authentifier à travers un formulaire de
connexion
Précondition La connexion à la base de données doit être opérationnelle
Scénario nominal : 1. L’utilisateur demande à se connecter

2. L’application renvois l’interface de connexion
3. L’utilisateur inscrit son identifiant et son mot de passe et
soumet le formulaire.
4. L’application vérifie que les données renseignées sont
correctes
5. Une vérification coté serveur est effectuée pour savoir si
l’utilisateur a un compte de connexion dans la base de
données
6. L’application renvoi l’utilisateur à sa page selon son rôle
Cameroun 0
Tableau 11 : description textuelle du cas d'utilisation effectuer consultation
Description du cas « effectuer consultation »
Cas d’utilisation Effectuer consultation
Acteur Médecin
Evènement déclencheur Ouvrir le dossier d’un patient
Intérêt Ce cas d’utilisation permet au médecin d’auditionner le patient et

d’indiquer les informations dans un formulaire afin d’effectué un
rendez-vous
Précondition Le patient doit avoir au préalable payer ses frais de consultation.
Scénario nominal : 1. Le médecin affiche la liste des patients ;

2. Le médecin clic sur le bouton « ouvrir le dossier du patient »
3. Le médecin cliquer sur le bouton « effectuer cette
consultation »
4. Le médecin remplir le formulaire
5. Les informations sont envoyées dans la base de données
Scénario alternatif : 3.a Le patient n’a pas de paramètre

3.b Le médecin ajoute les paramètres du patient
IV.2. Diagrammes d’activité

IV.2.1. Définition
Un diagramme d'activité s’accentue sur les traitements. Il est particulièrement adapté à
la modélisation du cheminement de flots de contrôle et de flots de données. Il permet ainsi de
représenter graphiquement le comportement d'une méthode ou le déroulement d'un cas
d'utilisation.
IV.2.1 Formalisme
Tableau 12 : Eléments d'un diagramme d'activité
Cameroun 1
Un nœud initial est un nœud de

contrôle à partir duquel le flot débute
lorsque l’activité enveloppante est
Début ou état initial invoquée.
Marque la fin de toutes les activités
Fin ou état final
Un Flux de Contrôle montre le flux de

contrôle d’une action au prochain
Flux ou transition
Une activité est la spécification d’une
séquence paramétrée de comportement.
Activité
Un nœud de décision est un nœud de

contrôle qui permet de faire un choix
Décision
entre plusieurs flots sortants.
Le diagramme d’activité fait intervenir

les acteurs et les objets de chaque
Couloir
activité. Ici, on place chaque activité
dans une colonne qui correspond à
l’acteur/objet : c’est le couloir.
Permet d’inscrire des notes de précision
Note
Cameroun 2
IV.2.3. Diagrammes d’activité de la solution

IV.2.3.1. Diagramme d’activité « Authentification »
Figure 12 : diagramme d'activité "authentification"
Utilisateur Système SGBD
afficher la formulaire
d'authentification
cliquer sur le bouton conexion exécution de la

requête
saisie identifiant et mot de passe
vérification de la saisie
[Succès]
envoie du resultat
envoie de la requête de vérifiaction

dans le SGBD
message d'erreur
avalyse du resultat
[Succès]
afficher da la page d'accueil
Cameroun 3
Figure 13 : diagramme d'activité "ajout d’un patient"
Utilisateur Système Base de donées
click sur le bouton ajouter
Afficahge du formulaire d'ajout

exécution de la requête
Saisie des données
verification
[Succès]
envoie de la requête d'ajout
Retour du resultat
Affichage du méssage d'érreur
Analyse resultat
[Succès]
Message de succès
IV.2.3.2. Diagramme d’activité d’ajout d’un patient
Cameroun 4
IV.2.3.3 Diagramme d’activité « effectuer consultation »

Tableau 13 : effectuer consultation
médecin système SGBD
cliquer sur le bouton "effectuer une executer la

consultaion" requête
Affichage du formumaire de consultation
remplissage du formulaire
envoies de la requête dans le SGBD
retour du resultat
[Succès]
analyse du resulat
<echec>
message d'erreur
afficher détait de la consultaion
Cameroun 5
IV.2.3.3 Diagramme d’activité « effectuer consultation »
Tableau 14 : effectuer consultation
caissier système SGBD
affichage de la liste des factures

impayés
cliquer sur le bouton "liste des

factures impayés"
exécution de la requête
choix de la facture à payer
affichage du formulaire de paiement
remplissage du formeulaire
<échec> envoie du résultat

vérifiaction du montant
[Succès]
envoie de la requête d'enregidtrement

du paiement
<échec>
analyse du resultat
[Succès]
cliquer sur le bouton "imprimer reçu"
affiche message succès
Cameroun 6
IV.3. Diagrammes de séquence

IV.3.1. Définition
Vue de l’extérieur du système, Les Diagrammes de séquence permettent de montrer
les interactions entre les utilisateurs et le système à travers une représentation linéaire et
chronologique des cas d’utilisations du système. Chaque colonne correspond à un objet ou
éventuellement à un acteur, introduit dans le diagramme des cas d’utilisation. La ligne de vie
de l’objet représente la durée de son interaction avec les autres objets du diagramme.
IV.3.2. Formalisme
Tableau 15 : Eléments d'un diagramme de séquence
Ligne de vie Acteur La ligne de vie représente l’ensemble

d’activité effectué par l’acteur
La ligne de vie représente l’ensemble

d’activité effectué par un objet de
Ligne de vie Objet
l’application
Activation Indique qu’une action est lancée
Alternatif Condition à l’envoi d’un message
Message asynchrone Message ou l’émetteur n’est pas bloqué

lors de l’envoi et peux continuer son
exécution
Cameroun 7
Réponse d’un message synchrone
Message de retour
Message d’appel Lorsqu’un acteur ou un Objet s’auto

Réflexif envoie un message
Message d’appel de
procédure ou
Message synchrone ou l’émetteur est
Message synchrone
bloqué en attente de retour
IV.3.3. Diagrammes de séquence de la solution

IV.3.3.1. Diagramme de séquence « authentification »
Cameroun 8
DiagrammeSequence authentifiaction
Système SGBD
Utilisateur
1. clic sur le boutton s'authentifier
2. affichage du formulaire d'

authentifiaction
3. remplissage du formulaire
4. envoie de la reqiuête
5. traitement de la requête
6. envoie reponse
7. analyse resultat
alt [compte indentifié]
affichage page d'accueil
[compte nom indentifié]

message d'erreur, retour au formulaire de
connexion
Figure 14 : diagramme de séquence "authentification"
Cameroun 9
IV.3.3.2. Diagramme de séquence « ajouter patient »
Figure 15 : diagramme de séquence "ajouter patient"
DiagrammeSequence ajout
Système SGBD
Utilisateur
ref DS_authentification()
1 Demande liste des patients

2 Afficher liste des patients
3 Demande d'ajout d'un patient

4 Formulaire d"ajout d'un patient
5 Remplir formulaire d'ajout
6 vérifiaction de la saisie
alt [saisie non valide]

7 message erreur, retour au formulaire
[saisie valide]
8. envoie de la requête
9. traitement de la requiête
10 reponse requête ajout
11 Vérification et validation
alt [Si insertion]
12 massage de succès, liste des patients
[Sinon]
13 Message erreur, formulaire d'ajout
Cameroun 0
Figure 16 : diagramme de séquence "payer facture"

IV.3.3.3. Diagramme de séquence « payer facture »
DiagrammeSequence "payer facture"
Système SGBD
caissier
1. clic sur le bouton facture impayés
2. affichage de la liste des factures

impayés
3. choix de la facture à payer
4. affichage du formulaire de paie
5. rensigner le montant à payer
6. vérifiaction du montant
alt [montant invalid]

7. message d'erreur retour au formulaire
de paie
[montant valide]
8. envoie de la requête
9. traitement de la requête
10. reponse de la requête
11. analyse du resultat
alt [si ok]

12. message de succès
Condition
message d'erreur
Cameroun 1
IV.4. Diagramme de communication

IV.4.1. Définition
Le diagramme de communication constitue une autre représentation des interactions
que celle du diagramme de séquence. En effet, le diagramme de communication met plus
l’accent sur l’aspect spatial des échanges que l’aspect temporel.
IV.4.2. Formalisme :
Tableau 16 : formalisme du diagramme de communication
Cameroun 2
Chaque participant à un échange de

message correspondant à une ligne de
vie dans le diagramme de séquence se
RÔLE
représente sous forme d’un rôle dans le
diagramme de communication. Un rôle
est identifié par : <nom de rôle> :
<nom du type>
Un message correspond à un appel

d’opération effectué par un rôle
émetteur vers un rôle récepteur. Le
MESSAGE sens du message est donné par une
flèche portée au-dessus du lien reliant
les participants au message (origine et
destinataire).
IV.4.3. Diagrammes de communication de la solution

IV.4.3.1. Digramme de communication « authentification »
Figure 17 : diagramme de communication authentification
Cameroun 3
13: 13 Message erreur, formulaire d'ajout 6: 6 vérifiaction de la saisie

11: 11 Vérification et validation
12: 12 massage de succès, liste des
patients
7: 7 message erreur, retour au formulaire
2: 2 Afficher liste des patients Système

4: 4 Formulaire d"ajout d'un patient
5: 5 Remplir formulaire d'ajout

Utilisateur
3: 3 Demande d'ajout d'un patient
1: 1 Demande liste des patients
10: 10 reponse requête ajout
8: 8. envoie de la requête
9: 9. traitement de la requiête
SGBD
IV.4.3.2. Digramme de communication « payer facture »
Figure 18: diagramme de communication "payer facture"
Cameroun 4
13: message d'erreur

6: 6. vérifiaction du montant
12: 12. message de succès
11: 11. analyse du resultat
7: 7. message d'erreur retour au
formulaire de paie
4: 4. affichage du formulaire de paie
2: 2. affichage de la liste des factures Système
impayés
personnel:caissier 5: 5. rensigner le montant à payer

3: 3. choix de la facture à payer
1: 1. clic sur le bouton facture impayés
10: 10. reponse de la requête
8: 8. envoie de la requête
9: 9. traitement de la requête
SGBD
IV.5. Diagrammes d’état transition

IV.5.1. Définition
En analyse UML, Le diagramme d’état transition décrit le comportement interne d’un
objet. Il présente les séquences possibles d'états et d'actions qu'une instance de classe peut
traiter au cours de son cycle de vie en réaction à des événements. L’état représente
Cameroun 5
l’abstraction d’un moment de la vie d’une entité pendant laquelle elle satisfait un ensemble de
conditions. Une transition représente le changement d’un état.
IV.5.2. Formalisme
Tableau 17 : Eléments d'un diagramme d’état transition
Initialisation du système, exécution du

constructeur de l'objet
Pseudo Etat initial
ou Début
Pseudo état final ou Fin de vie du système, destruction de

Fin l'objet
Abstraction d'un moment de la vie

d'une entité pendant lequel elle satisfait
ETAT
un ensemble de conditions
Elle lit généralement deux états E1 et
TRANSITION E2 et indique qu’un objet dans E1 peut

entrer dans l’état E2 et exécuté
certaines activités.
Cameroun 6
IV.5.3. Diagramme d’état transition de la solution
Figure 19 : diagramme d'activité de la solution
patient ambulatoire
<<patient enregisré>>
<<demande de consultation>>
<<demande d'acheter un produit>>

patient comptoire
patient consulté
<<prescription hospitalisation>>
patient hospitalisé
CONCLUSION
L’analyse d’un projet est une étape cruciale qui doit être effectuée avant de concevoir
son application car elle nous permet de cerner les différentes fonctionnalités de notre
application. Dans la suite nous allons ressortir le dossier de conception de notre projet.
Cameroun 7
DOSSIER IV : DOSSIER DE CONCEPTION
Le dossier de conception vient concrétiser les résultats obtenus lors de l’analyse. Dans
cette section nous parlerons des objectifs de ce document, et des diagrammes y intervenant.
Aperçu
INTRODUCTION
I. DIAGRAMME DE CLASSE
II. DIAGRAMME D’OBJET
III. DIAGRAMME DE PAQUETAGE
IV. DIAGRAMME DE COMPOSANT
CONCLUSION
Cameroun 8
INTRODUCTION
Dans la réalisation d’un projet informatique, le dossier de conception est celui qui
présente l’architecture du système étudié. L’analyse UML nous permet à travers ses
diagrammes structurels de représenter la structure de notre application ainsi que les différents
composants matériels et logiciels. Dans cette partie, nous vous présenterons le diagramme de
classe, son model physique de données associé, ainsi que le diagramme de composant.
I. DIAGRAMME DE CLASSE
I.1. Définition
Le diagramme de classe est l'un des types de diagrammes les plus utiles dans une
modélisation UML, car il décrit clairement la structure d’un système particulier en modélisant
ses classes, ses attributs, ses opérations et les relations entre ses objets. Une classe défini un
type d’objet et possède un nom des attributs et opérations. Le nom d’une classe commence par
une majuscule, le nom d’une propriété commence par une minuscule, les types de base (Int,
long, double, boolean) sont en minuscules, il n’y a pas d’espace dans les noms des classes ou
de propriétés.
Cameroun 9
I.2. Formalisme
Tableau 18 : éléments d'un diagramme de classe
Une classe est une représentation

abstraite d’un ensemble d’objets, elle
Classe
contient les informations nécessaires à
la construction de l’objet (c'est-à-dire la
définition des attributs et des
méthodes).
Elle se représente sous forme d’un

rectangle divisé en trois sections. La
première contient le nom de la classe, la
seconde partie contient les attributs de
la classe et leur type, et la troisième
partie contient les opérations (méthodes
ou comportements).
L'énumération UML est

ENUMERATION particulièrement adaptée pour modéliser
un ensemble fini de valeurs possibles
que peut recevoir l'attribut d'une
classe.
nomAttribut : Type ATTRIBUT Fin de vie du système, destruction de
l'objet
nomMéthode () : Type Abstraction d'un moment de la vie d'une

entité pendant laquelle elle satisfait un
METHODE
ensemble de conditions
L’association est représentée par un
Cameroun 0
ASSOCIATION simple trait continu, reliant deux

classes. Le fait que deux instances
soient ainsi liées permet la navigation
d’une instance vers l’autre, et vice versa
(en générale une classe possède un
attribut qui fait référence à l’autre
classe)
C'est une relation particulière qui
attribue à l'une des classes le rôle
AGREGATION
d'agrégat et à l'autre classe le rôle
d'agrégé. L'agrégation peut être
assimilée à une appartenance faible.
Il s'agit d'une appartenance forte. La vie

de l'objet composant est liée à celle de
son composé.
COMPOSITION
Cameroun 1
I.3. Représentation du diagramme de classe de la solution

Figure 20 : diagramme de classe
HP Proprietaire HP Patient
- idProprietaire : int - idPatient : int
- nomProprietaire : String - codePatient : String HP Dossier HP Salle
HP Administrateur - nomPatient : String - idSalle : int
- telephoneProprietaire : String - idDossier : int
- IdAdministrateur : int - emailProprietaire : String - prenomPatient : String - codeDossier : String - codeSalle : String
- nomsAdministrateur : String - telephonePatient : String 1..1
- siteProprietaire : String 1..1 - etatDossier : boolean + creerSalle () : void
- prenomAdministrateur : String - bpProprietaire : String - telephonePACPatient : String - dateDossier : Date + supprimer () : void
- loginAdministrateur : String - hopitalProprietaire : String - sexePatient : String - archiveDossier : boolean ...
- motdepasseAdministrateur : String - logoProprietaire : String - dateNaissancePatient : Date 1..1
+ créer () : void
+ modifier () : void - dateCreationProprietaire : Date - lieuNaissancePatient : String
... - typeProprietaire : String - situationMatrimonialePatient : String
1..1 - sloganProprietaire : String - professionPatient : String 1..1
- noContribuableProprietaire : String - residencePatient : String
- etatProprietaire : boolean - datePatient : Date
+ modifier () : void + ajouter () : void
+ rechercher () : void
...
1..*
0..* HP Lit
- IdLit : int
HP Consultation 1..1 HP Sous Dossier - codeLit : String
- idConsultation : int 0..* + ajouter () : void
- idSousDossier : int
- codeConsultation : String + supprimer () : void
- codeSousDossier : String
- temperatureConsultation : String ...
- etatSousDossier : boolean
- poidsConsultation : float 1..1
- dateSousDossier : Date
- tensionConsultation : float
- pouConsultation : float + créer () : void
- prixConsultation : float
- butConsultation : String 1..1
- signeConsultation : text 1..1 1..1
- symptomeConsultation : text HP Hospitalisation
- diagnostiqueConsultation : text - IdHospitalisation : int
- resultatConsultation : text 0..1 0..* - codeHospitalisation : String
0..*
- traitementConsultation : text 0..* - montantHospitalisation : int
- etatConsultation : boolean - datedebutHospitalisation : Date
HP Compte Personnel HP Examen Patient
- dateConsultation : Date - datefinHospitalisation : Date
- idComptePersonnel : int - idExamenPatient : int - regleHospitalisation : String
+ ajouter () : void
- loginComptePersonnel : String - butExamenPatient : String - dateHospitalisation : Date
+ modifier () : void
- motdepasseComptePersonnel : String 0..* - montantExamenPatient : float
+ Ajouter ()
- roleComptePersonnel : String - resultatExamenPatient : String
0..1 ...
- etatComptePersonnel : boolean - valeurExamenPatient : float
0..1
- etatExamenPatient : boolean 0..*
+ créer () : void 0..* - dateExamenPatient : Date
+ supprimer () : void
+ activer () : void 0..* + ajouter () : void
... ...
0..1 0..1 1..1
0..* 0..*
HP Personnel 0..*
- idPersonnel : int HP Facture
- codePersonnel : String HP Resultat Examen
- idFacture : int
- nomPersonnel : String - idResultatExamen : int
HP Service - codeFacture : String
- prenomPersonnel : String - interpretationResultatExamen : text
- montantFacture : float
- idService : int - telephonePersonnel : String - conclusionResultatExamen : text
- avanceFacture : float
- codeService : String 1..1 - rolePersonnel : String - dateResultatExamen : Date
- etatFacture : boolean
- nomService : String - etatPersonnel : boolean + ajouter () : void
- dateFacture : Date
- telephoneService : String - datePersonnel : Date + modifier () : void
1..1 + créer () : void
- domaineService : String + ajouter () : void
+ payer () : void
- localService : boolean + modifier () : void
0..*
- etatService : boolean + supprimer () : void
- dateService : Date
0..*
1..1
1..1
0..* 0..*
HP Examen
- idExamen : int
HP Produit HP Caisse - codeExamen : String
1..1
- idProduit : int - idCaisse : int - nomExamen : String
- codeProduit : String 0..1 - nomCaisse : String - typeExamen : String
HP Medecin - butCaisse : String
- libelleProduit : String - prixExamen : float
- idMedecin : int - etatCaisse : boolean - resultatExamen : String
- imageProduit : String
- typeMedecin : String + créer () : void - valeurMinExamen : float
- typeProduit : String
- etatMedecin : boolean + supprimer () : void - valeurMaxExamen : float
- stockProduit : float
- stockMinProduit : float - etatExamen : boolean
- stockMaxProduit : float - dateExamen : Date
- prixAchatProduit : float + ajouter () : void
0..1
- prixVenteProduit : float
- dateFabricationProduit : Date
HP Ordonnance 0..*
- datePeremptionProduit : Date
- etatProduit : boolean - idOrdonnance : int
1..1
- dateProduit : Date 0..* - codeOrdonnance : String
- montantOrdonnance : float HP Ligne Caisse
+ ajouter () : void HP Laboratoire
- etatOrdonnance : String - idLigneCaisse : int
+ modifier () : void
- dateOrdonnance : Date - montantLigneCaisse : float - idLaboratoire : int
+ supprimer () : void
+ créer () : void - dateLigneCaisse : Date - codeLaboratoire : String
0..* - nomLaboratoire : String
+ ajouter () : void
- butLaboratoire : String
- etatLaboratoire : boolean
Cameroun 2
II. Diagramme d’objet

II.1. Définition
Le diagramme d’objets permet de mettre en évidence des liens entre les objets. Les
objets, instances de classes, sont reliés par des liens, instances d’associations. A l’exception
de la multiplicité, qui est explicitement indiquée, le diagramme d’objets utilise les mêmes
concepts que le diagramme de classes. Ils sont essentiellement utilisés pour comprendre ou
illustrer des parties complexes d’un diagramme de classes.
II.2. Formalisme
Tableau 19 : formalisme du diagramme d'objet
OBJET Représente l’instance d’une classe
Lignes reliant les objet
Lien entre les

objets
II.3. Diagramme d’objet de la solution
Figure 21 : diagramme d'objet de la solution
Cameroun 3
patient:PA134 dossie:DS112
sous dossier:SD123
hospitalistion:HP456
lit:LT789
medecin:MD134 consultation:CO123
facture:FA456
salle:SA954
ordonnance:OR123
examen:EX852
reçu:C789
personnel:PN555
III. Diagramme de package

III.1. Définition
Le diagramme de paquetages permet de décomposer le système en catégories ou
parties plus facilement observables, appelés « packages ». Cela permet également d’indiquer
les acteurs qui interviennent dans chacun des packages.
Cameroun 4
III.2. Formalisme
Dans un diagramme de packages on retrouve les éléments suivants :
Tableau 20 : éléments d'un diagramme de cas d'utilisation
Package Représente les différentes familles de

fonctionnalités du système.
Séquence spécifique d'actions et d'interactions

entre les acteurs et le système. Un système peut
Système
également être appelé scénario.
Lignes reliant les différents paquages.
Association
III.3. Diagramme de paquetage de la solution
Figure 22 : diagramme de paquetage de la solution
Cameroun 5
gestion des stock

<<import>> gestion financière
<<access>>
gestion de la pharmacie administration
<<access>>
<<access>>
gestion des admissions gestion des patients
<<access>>
<<import>>
patients ambulatoires patients hospitalisés
IV. DIAGRAMME DE COMPOSANT

IV.1. Définition
Un diagramme de composant permet de représenter les composants logiciels d’un
système ainsi que les liens existants entre ces composants. Un composant est un élément
logiciel autonome, remplaçable et réutilisable qui fournit ou reçoit un service bien précis :
fichier sources, librairie, exécutable… Les composants fournissent des services via des
Cameroun 6
interfaces. Un composant peut être remplacé par n’importe quel autre composant compatible
c’est-à-dire ayant les mêmes interfaces. Un composant peut évoluer indépendamment des
applications ou des autres composants qui l’utilise à partir du moment où les interfaces sont
respectées.
IV.2. Formalisme
Tableau 21 : éléments d'un diagramme de composants
Composant Élément logiciel autonome,

remplaçable et réutilisable qui fournit
ou reçoit un service
Interface Permet d’établir la connexion entre 2

composants
Lien de prérequis ou Ce lien indique qu’un composant

connecteur utilise une interface pour effectuer une
action définie sur un autre composant
(Interface requise)
IV.3. Diagramme de composant de la solution

La représentation de notre diagramme de composant peut se faire soit avec des
classificateurs séparés, soit à l’aide de connecteurs d’assemblage. Pour notre cas nous avons
opté pour les connecteurs d’assemblage à fin d’avoir une représentation plus simplifiée.
Cameroun 7
Figure 23 : digramme de composant de la solution
CONCLUSION
La phase de conception est une étape primordiale dans la conception logicielle, car elle
nous donne une vue globale de la structure de notre application. Après cette étape nous
pouvons passer à la réalisation de notre projet.
DOSSIER V : DOSSIER DE REALISATION
Cameroun 8
Cette partie présente les différentes technologies, langages de programmation,

architectures utilisées nécessaires pour la réalisation de notre application ainsi que son
déploiement.
Aperçu
INTRODUCTION
I. PRESENTATION DE L’ENVIRONEMENT LOGICIEL ET

TECHNOLOGIES UTILISEES
II. PRESENTATION DE L’ARCHITECTURE UTILISEE
III. DIAGRAMME DE DEPLOIEMENT
IV. ASPECT DE SECURITE
CONCLUSION
INTRODUCTION
Le dossier de réalisation permet de représenter l’environnement logiciel utilisé, les

différentes technologies utilisées pour la réalisation de notre projet ainsi que son déploiement.
Dans cette partie, nous présenterons les différentes technologies et environnement logiciel
utilisé ainsi que l’architecture de notre application.
Cameroun 9
I. PRESENTATION DE L’ENVIRONEMENT LOGICIEL ET

TECHNOLOGIES UTILISEES
I.1. XAMPP
I.1.1. Présentation de xampp
XAMPP est une distribution Apache entièrement gratuite contenant
MySQL, PHP et Perl. Il se compose d’un SGBD MySQL, prend en
charge le langage server PHP, d’un serveur web Apache et d’autres
utilitaires. Ce Paquetage nous est utile pour déployer notre application en locale afin
d’effectuer nos tests.
I.1.2. Installation de xampp

Pour utiliser la distribution Xampp, il faut se rendre à l’adresse
https://www.apachefriends.org/fr/index.html et en suite télécharger une version de xampp de
notre choix. Nous avons téléchargé la version 7.4 qui prend en charge PHP 5 ou plus.
Figure 24 : page de téléchargement de xampp
Après avoir téléchargé Xampp, l’exécuté et suivre l’installation
Figure 25 : étape de 1’installation xampp
Cameroun 0
Figure 26 : panneau de contrôle de xampp
Après avoir suivi toutes les étapes, on lance xampp afin d’accéder à son panneau de
contrôle où on pourra activer les services nécessaires pour travailler en local.
Cameroun 1
I.2. Langages de programmation et technologies utilisées

Dans le cadre de notre projet et parmi le grand nombre de technologies existantes nous
avons opté pour les technologies suivantes :
Figure 27 : technologies et langages de programmation utilisés
TECHNOLOGIE et ROLE
LANGAGES
HyperText Preprocessor langage serveur utilisé pour traiter du

contenu dynamique
JQuery est ce qu’on appelle une « librairie » ou une « bibliothèque »
JavaScript. Le rôle d’une librairie, en informatique, est de simplifier

l’utilisation d’un certain langage de programmation en fournissant
un ensemble de codes déjà prêt à l’emploi. Nous l’utilisons pour
effectuer des requêtes de type Ajax qui s’exécute de façon
asynchrone grâce aux callbacks, et aussi pour manipuler facilement
un tableau HTML à l’aide de son plugin DataTables
Html est un langage de programmation utilisé pour gérer contenu de

notre application
Le CSS est utilisé pour gérer la forme
Bootstrap est une collection d’outils utiles à la création du design

(graphisme, animation et interactions avec la page dans le
navigateur, etc.) de site et application web. C'est un ensemble qui
contient des codes HTML et CSS, des formulaires, boutons, outils
Version4 de navigation et autres éléments interactifs, ainsi que des extensions

JavaScripts en option.
Cameroun 2
II. PRESENTATION DE L’ARCHITECTURE DE

L’APPLICATION
II.1. Architecture logique
Notre projet suit une logique applicative standardisé et utilisée dans la plupart des
entreprises de nos jours. Cette logique est le MVC (Modèle-Vue-Contrôleur) qui est un
design pattern permettant de mieux organiser son code.
 Le model contient les données à afficher
 La vue contient la présentation de l’interface graphique
 Le contrôleur contient la logique concernant les actions effectuées par l’utilisateur.

Dans ce motif d’architecture logicielle, le code est organisé de manière à faciliter la détection
des erreurs, facilité la collaboration et la réutilisabilité du code.
Figure 28 : représentation de l'architecture MVC
Source : www.architecturel.com 28/08/2022, 14 :45
Cameroun 3
II.2. Architecture physique

Notre application a été implémentée suivant le modèle d’architecture 3-tiers encore
appelée Architecture à 3 niveaux. Cette architecture est l'application du modèle plus général
qu'est le multi-tiers. L'architecture logique du système est divisée en trois niveaux ou
couches :
 Une couche présentation qui correspond à l’affichage, la restitution des données sur
le poste de travail, le dialogue avec un utilisateur.
 Une couche de traitement qui correspond à la logique métier des données, la mise en
œuvre de l’ensemble des règles de gestion et de la logique applicative.
 Une couche d’accès aux données qui correspond aux données qui sont destinées à
être conservées de manière persistante.
Figure 29 : Présentation de l'architecture 3-tiers
Source : www.architecturel.com 28/08/2022, 14 :45
Cameroun 4
III. DIAGRAMME DE DEPLOIEMENT

III.1. Définition
Le diagramme de déploiement permet de représenter d’une part la disposition
physique des ressources matérielles qui constituent le système et montre la répartition des
composants (éléments logiciels) qui s’exécutent sur ces matériels et d’autres parts les chemins
de communication entre les différentes ressources matérielles.
III.2. Formalisme
Figure 30 : éléments d'un diagramme de déploiement
Présente les différents composants

Nœud
d’un système matériel
Élément logiciel autonome,

remplaçable et réutilisable qui fournit
Composant ou reçoit un service
Association
Liens entre 2 nœuds
Une dépendance est utilisée pour

modéliser ou matérialiser la relation
Dépendance entre deux composants. La notation

utilisée pour matérialiser la notation
Cameroun 5
de dépendance est la flèche en

pointillée, se dirigeant d’un
composant donné vers le composant
dont il dépend.
Cameroun 6
III.3. Diagramme de déploiement de la solution

Figure 31 : diagramme de déploiement de la solution
Cameroun 7
IV. ASPECT DE SECURITE

IV.1. Connexion sécurisée
La confidentialité des données requiert la définition des droits d’accès. Ceci se traduit
par l’utilisation des mots de passe et login pour l’accès à la base de données en relation avec
la plateforme. De cette façon, l’accès sera restreint en fonction du spécialiste de la santé,
patient ou de l’administrateur.
IV.2. Sécurisation des mots de passes utilisateurs

Le compte spécialiste de la santé est créé par l’administrateur. Le patient s’inscrit sur
la plateforme et peut aussi être inscrit par l’administrateur. Ainsi, dans l’option d’avoir une
confidentialité accrue des informations, tous les mots de passe de la plateforme ont été
cryptés, de telle sorte que même l’administrateur n’a pas accès aux mots de passes des
utilisateurs. En effet, bien que le compte spécialiste de la santé (docteur) soit créé par
l’administrateur, il est possible que l’administrateur changer son mot de passe et les autres
éléments de son profil. L’administrateur peut réduire les dégâts par l’activation ou la
désactivation.
IV.3. Contrôle des formulaires et de sessions

Avant de récupérer des informations importantes dans la base de données, un contrôle
s’effectue au niveau du formulaire avant la validation de la requête SQL. Toute modification
apportée à la base de données est susceptible d’être retracé et l’auteur de la modification est
identifié en peu de temps.
CONCLUSION
La phase de réalisation est une étape très importante où nous nous concentrons sur
l’aspect technique de notre application, des différentes technologies qui sont utilisées pour un
résultat optimal. Le choix de ces technologies nécessite une bonne étude car toute application
mal réalisée conduit à la production d’une mauvaise application.
Cameroun 8
DOSSIER V : GUIDE D’UTILISATION
Cette partie présente notre application ainsi que quelques fonctionnalités qu’elle
regorge. Elle vous présentera un aperçu de notre travaille ainsi que quelques indications pour
l’utiliser.
Aperçu
INTRODUCTION
I. PRESENTATION DE NOTRE APPLICATION
II. PRESENTATION DE QUELQUES FONCTIONNALITES
CONCLUSION
Cameroun 9
INTRODUCTION
Le Guide d’utilisation est ce document permettant de présenter les différentes

fonctionnalités de notre application. Dans cette partie, nous allons présenter notre
application et ensuite étaler quelques fonctionnalités disponibles sur notre application.
I. PRESENTATION DE NOTRE APPLICATION

Une démo de notre application est disponible en ligne à l’adresse
http://sante.universbinaire.com
I.1. Présentation des interfaces

I.1.1. Interface de connexion
Pour utiliser notre application, chaque utilisateur devra se connecter via cette interface en
fournissant son identifiant (login) et son mot de passe.
Figure 32 : interface de connexion
Cameroun 0
I.1.2. Interface d’accueil propriétaire

Cette interface est réservée au propriétaire du centre de santé. C’est ici qu’il
paramétrer le centre.
Figure 33 : interface d'accueil propriétaire
I.1.3. Interface d’accueil personnel

C’est dans cette interface qu’est redirigé le personnel soignant en cas d’identification.
Les menus ici sont disponibles en fonction des rôles. L’illustration ci-dessous correspond à
l’aperçu de cette interface lorsque le personnel connecté est le caissier.
Cameroun 1
Figure 34 : interface d'accueil personnel
I.2. Les fonctionnalités

Notre application regorge d’une multitude de fonctionnalités dont la liste non-
exhaustive est fournie ci-dessous :
 Gestion des patients
 Gestion des dossiers patients
 Gestion des patients hospitalisés
 Gestion des médecins
 Gestion des soins ambulatoires
 Intégration comptable
 Gestion de la pharmacie
 Gestion du stock
Cameroun 2
II. UTILISATION SOMMAIRE DE NOTRE APPLICATION

Notre application est une application web, c’est-à-dire accessible uniquement via un
navigateur. Elle n’a par conséquent pas d’exigence particulières en ce qui concerne les
caractéristiques des équipements sur lesquelles elle tourne. Elle peut être déployée en ligne
ou en local. Toutefois, la fonctionnalité Javascript du navigateur devra être activée afin de
ne pas rencontrer de problème lors de l’utilisation.
II.1. Paramétrage de l’application.

Avant de commencer son utilisation, le système doit être paramétrer au préalable par
le propriétaire du centre. Ce sont les informations rentrées ici qui permettrons l’utilisation
ultérieure de l’application.
II.1.1. Interface propriétaire avec menu de paramétrage

Ici, l’utilisateur click sur le « menu burger » pour qu’apparait le menu paramétrage.
Il parcourra ensuite chaque onglet du menu afin de paramétrer l’application. Un ensemble
de fonctionnalités sont également présentes au niveau de la barre de menu.
Figure 35 : menu paramétrage
Menu burger Barre de

Menu de Menu
paramétrage
Cameroun 3
I.1.2. Formulaire de d’identification du centre de santé

C’est dans ce formulaire que le propriétaire devra renseigner les informations relatives
à sa structure. Celles-ci seront utilisées à plusieurs niveaux dans l’application en fonction du
besoin.
Figure 36 : formulaire de modification du propriétaire
Cameroun 4
I.1.3. Interface d’enregistrement d’un patient

C’est cette interface qui correspond à l’abstraction du service d’accueil d’un centre de
santé. C’est donc qu’ici qu’est reçu le patient quand il ne s’agit pas d’une urgence. A partir du
bouton « enregistrer un patient », le personnel de l’accueil accède au formulaire permettant
d’ajouter un patient. Il peut également par la même interface, voir la liste des patients
hospitalisés.
Figure 37 : interface de l'accueil
Bouton d’ajout d’un patient
Cameroun 5
I.1.4. Formulaire d’ajout d’un patient

Le remplissage correct de ce formulaire donne lieu à l’enregistrement d’un patient
dans le système. A chaque enregistrement, un code est généré et permettra d’identifier de
façon unique le patient. Celui-ci est également utiliser au repassage du patient dans le centre
pour retrouver ses informations. A noter que dès son enregistrement, un dossier est créé pour
le patient dans lequel seront stockés tous les acte dont il fera l’objet.
Figure 38 : formulaire d'ajout d'un patient
Cameroun 6
I.1.5. La liste des patients

En déroulant le menu patient au niveau de la barre de menu, nous avons l’option « liste
des patient ». En choisissant cette option, on voit apparaître la liste des patients enregistrés
dans notre système. Il apparaît également sur cette liste le bouton permettant d’ajouter un
nouveau patient.
Figure 39 : affichage de la liste des patients

Bouton
d’ajout d’un
nouveau
Bouton
d’ouverture du Bouton
dossier patient
modifier
Cameroun 7
I.1.6. Page de présentation de l’état financier.

Dans cette page le propriétaire du centre peut consulter toutes les traces financières
effectuées dans l’application, à savoir : paiement d’une facture, décaissement, etc. Cette page
présente également un « bouton imprimé » permettant de générer cette fiche au format PDF.
Figure 40 : visualisation de l'état financier
Cameroun 8
I.1.7. Aperçu du fichier PDF de l’état financier.
Figure 41: fichier PDF généré
CONCLUSION
Le but de ce dossier était de mieux étayer les futurs utilisateurs de notre solution, sur
son utilisation. Ayant présenté quelques fonctionnalités de notre application, Ce dossier est
donc apte à remplir sa mission et pourra permettre à n’importe qui d’utiliser l’application.
Cameroun 9
CONCLUSION
L’objectif de ce stage effectué à Univers Binaire Sarl a été pour nous de se

familiariser avec le milieu professionnel et nous permettre de mettre en pratique notre savoir-
faire obtenu au cours de notre formation. Au vu de l’évolution constante des nouvelles
technologies visant à faciliter notre mode de vie au quotidien et de l’informatisation des
structures, nous avons pu réaliser à l’aide de nos encadreurs une application de gestion des
centres de santé durant cette période de trois (03) mois de stage tout en tenant compte des
réalités du terrain. En somme, la réalisation de notre projet s’est faite grâce au processus
2TUP appuyé sur le langage UML, grâce à l’utilisation au langage de programmation PHP et
bien d’autres outils. Toutefois la réalisation d’un projet de telle envergure a nécessité des
ressources matérielles, logicielles, humaines. Néanmoins, cette production est un grand pas
pour le monde professionnel car elle nous a permis de mieux jauger notre niveau de
compétence.
Cameroun 0
0
REFERENCES BIBLIOGRAPHIQUES
 Livre PDF
 Administrer vos bases données avec MySQL Par Chantal Gribaumont (Taguan)
 Concevez votre site web avec PHP et MySQL de Mathieu nebra4
 Conduire un projet informatique, Philippe taché
 CSS avancé vers HTML 5 et CSS3, Raphael Goetter
 Javascript, l’essentiel des commandes de Christian Wenz
 PHP & MySQL de Cyril Pierre de Geyer et Guillaume Ponçon
 PHP 7 cours et exercices de Jean Engels
 Pratique de MySQL et PHP : conception et réalisation des sites web dynamique de
Philippe Rigaux
 Programmer avec MySQL de Christian Soutou
 UML 2 analyse et conception de Joseph Gabay et David Gabay
 Autres documents
 CAMEROUN, IAI. (2020/2021). Cahier de charge. Yaoundé : IAI Cameroun.
 Cameroun, M. d. (s.d.). Mercurial des prix 2022. Yaoundé, Cameroun.
 IAI, KADJI NGAMATAM Becker. (2020-2021). Rapport de stage : conception d’une
application de gestion des livraisons et commande en ligne dans des restaurant :
FoodManager. Yaoundé.
Rédigé Par Fabrice KEGOUM KOUEMO, Elève Ingénieur des Travaux Informatiques, IAI- x
Cameroun
WEBOGRAPHIE
 Site web
 http://www.codes-sources.com/ juin-juillet 2022
 http://www.siteduzero.com/ juin-juillet 2022
 http://www.developpez.net/ juin-juillet 2022
 http://www.commentçamarche.com/ juin-juillet 2022
 http://www.openclassroom.com/ juin-juillet 2022
 http://www.flexboxfroggy.com/ juin-juillet 2022
 http://www.getboostrap.com/ juin-juillet 2022
 http//www.lucid.app.com/ juin-juillet 2022
 https://fr.wikipedia.org/wiki/Two_Tracks_Unified_Process juin-juillet 2022
 https://mesomb.hachther.com/fr/api/schema/ juin-juillet 2022 ;
 https://laurent-audibert.developpez.com/Cours-UML/ juin-juillet 2022 ;
 https://codeigniter.com/userguide3/index.html juin-juillet 2022 ;
 https://www.php.net/ juin-juillet 2022 ;
 https://api.jquery.com/ juin-juillet 2022 ;
 https://stackoverflow.com/ juin-juillet 2022 ;
 https://fontawesome.com/ juin-juillet 2022
 Chaine YouTube
 Pierre Giraud
 Graven – Développement
Cameroun i
GLOSSAIRE
 OMT (Object Modeling Technique) : technique de modélisation orientée objet,

conçue par James Rumbaugh ;
 OOD (Object oriented design) : méthode d’analyse et de conception orientée objet,
conçue par Grady Booch ;
 OOSE (Object-oriented software engineering) : langage de modélisation objet et
méthode d’analyse conçue par Ivar Jacobson ;
 OMG (Object management group) ;
 SI (système d’information) : élément central d’une entreprise ou d’une organisation ;
 SIH (système d’information hospitalier) logiciel d’automatisation des processus des
centre de santé.
 UML (Unified Modeling Language) langage de modélisation oriente objet issue de la
fusion d’OMT, OOD, OOSE.
 RDV : Rendez-vous ;
 2TUP (2 Tracks Unified Process) : processus de développement d’application prônant
une approche itérative et incrémentale en dissociant l’aspect fonctionnel de l’aspect
technique.
Cameroun ii
ANNEXES
A1. Fiche d’accord du centre d’accueil ;

A2. Planning prévisionnel ;
A3. Compte rendu bimensuel ;
A4. Fiche d’évaluation ;
A5. Normes des rédactions.
Cameroun ii
i
TABLE DES MATIERES

DEDICACE..............................................................................................................................................ii
REMERCIEMENTS...............................................................................................................................iii
SOMMAIRE............................................................................................................................................iv
LISTE DES FIGURES.............................................................................................................................v
LISTE DES TABLEAUX......................................................................................................................vii
RESUME...............................................................................................................................................viii
ABSTRACT............................................................................................................................................ix
INTRODUCTION GENERALE..............................................................................................................1
PARTIE I : PHASE D’INSERTION........................................................................................................2
DOSSIER I : DOSSIER D’INSERTION.................................................................................................3
I. ACCEUL EN ENTREPRISE...........................................................................................................4
II. PRESENTATION D’UNIVERS BINAIRE SARL........................................................................4
II.1. Historique.................................................................................................................................4
II.2. Situation géographique............................................................................................................5
II.3. Mission......................................................................................................................................5
II.4. Activités et réalisations.............................................................................................................6
II.5. Organisation et fonctionnement de la structure........................................................................7
II.5.1. Organigramme.................................................................................................................7
II.5.2. Présentation de la division de développement..................................................................7
II.6. Les partenaires.........................................................................................................................8
II.7. Ressources matérielles et logicielles........................................................................................8
II.7.1. Ressources matérielles.....................................................................................................8
II.7.1. Ressources logicielles.......................................................................................................9
PARTIE II : PHASE TECHNIQUE.......................................................................................................10
DOSSIER II : CAHIER DES CHARGES..............................................................................................12
I. CONTEXTE ET JUSTIFICATION DU PROJET.........................................................................13
II. LES OBJECTIFS DU PROJET....................................................................................................13
II.1. Objectif global.......................................................................................................................13
II.2. Objectifs spécifiques..............................................................................................................14
III. SPECIFICATION DES BESOINS.............................................................................................14
III.1. Besoins fonctionnels.............................................................................................................14
III.1.1. Module « PATIENT »..................................................................................................14
III.1.2. Module « ADMISSIONS »..........................................................................................15
III.1.3. Module « Facturation ».................................................................................................17
III.1.4. Module « Gestion automatisée des rendez-vous ».......................................................18
Cameroun i
v
III.1.5. Module « Calendrier de consultation des médecins »..................................................18

III.1.6. Module « Système d'alerte ».........................................................................................18
III.1.7. Module « LABORATOIRE ».......................................................................................19
III.1.8. Module « Administration du système »........................................................................19
III.1.9. Module « Accessoires ».................................................................................................20
III.1.10. Module « PHARMACIE »..........................................................................................21
III.1.11. Module « Comptabilité »............................................................................................21
III.2. Besoins non fonctionnels......................................................................................................22
IV. ESTIMATION DU COÛT DU PROJET....................................................................................23
IV.1. Ressources humaines............................................................................................................23
IV.2. Ressources matérielles.........................................................................................................24
IV.3. Ressources logicielles...........................................................................................................25
IV.4. Divers...................................................................................................................................26
V. ESTIMATION GLOBALE DU PROJET.....................................................................................26
VI. PLANIFICATION DU PROJET.................................................................................................27
VII. LES CONTRAINTES DU PROJET...........................................................................................27
VII.1. Les contraintes de coût........................................................................................................27
VII.2. Les contraintes de délais.....................................................................................................27
VII.3. Les contraintes de qualités..................................................................................................28
VIII. LES LIVRABLES.....................................................................................................................28
IX. LES PRINCIPAUX INTERVENANTS DU PROJET................................................................29
DOSSIER III : DOSSIER D’ANALYSE...............................................................................................30
I. RECEUIL DE L’EXISTANT........................................................................................................31
I.1. Description de l’existant...........................................................................................................31
I.2. Critique de l’existant................................................................................................................33
I.3. Problématique...........................................................................................................................33
I.4. Proposition de la solution........................................................................................................33
II. ETUDE COMPARATIVE DES METHODES ET LANGUAGES DE MODELISATION........34
II.1. Généralité sur les méthodes d’analyses UML et MERISE.....................................................34
II.2. Etude comparative entre MERISE et UML............................................................................35
III. PRESENTATION DE LA METHODE D’ANALYSE..............................................................36
III.1. Choix de la méthode d’analyse.............................................................................................36
III.2. Présentation de UML............................................................................................................36
III.2.1 Version............................................................................................................................36
III.2.2. Les diagrammes d’UML................................................................................................37
III.2.3. Formalisme....................................................................................................................38
Cameroun v
III.2.4. Les vues.........................................................................................................................38

III.2.5. Présentation du processus 2TUP........................................................................................39
IV. DIAGRAMMES D’ANALYSE..................................................................................................41
IV.1. Diagrammes de cas d’utilisation...........................................................................................41
IV.1.1. Définition.......................................................................................................................41
IV.1.2. Formalisme....................................................................................................................41
IV.1.3. Diagrammes de cas d’utilisation de la solution.............................................................43
IV.1.3.1. diagramme de cas d’utilisation global du système................................................43
IV.1.3.2. Diagramme de cas d’utilisation « gérer patient »..................................................44
IV.1.3.3. Diagramme de cas d’utilisation « effectuer une consultation ».............................45
IV.1.3.4. Diagramme de cas d’utilisation « gérer les patients hospitalisés »........................46
IV.1.3.5. Diagramme de cas d’utilisation « gérer facture »..................................................47
IV.1.3.6. Diagramme de cas d’utilisation « gérer les produit »............................................48
IV.1.3.7. Diagramme de cas d’utilisation « gérer personnel »..............................................49
IV.1.3.8. Description textuelle de quelques cas d’utilisation................................................50
IV.2. Diagrammes d’activité...........................................................................................................51
IV.2.1. Définition.......................................................................................................................51
IV.2.1 Formalisme.....................................................................................................................52
IV.2.3. Diagrammes d’activité de la solution............................................................................53
IV.2.3.1. Diagramme d’activité « Authentification »...........................................................53
IV.2.3.2. Diagramme d’activité « ajout un patient »......................................................54
IV.2.3.3 Diagramme d’activité « effectuer consultation »....................................................55
IV.2.3.3 Diagramme d’activité « effectuer consultation »....................................................56
IV.3. Diagrammes de séquence......................................................................................................57
IV.3.1. Définition.......................................................................................................................57
IV.3.2. Formalisme....................................................................................................................57
IV.3.3. Diagrammes de séquence de la solution........................................................................59
IV.3.3.1. Diagramme de séquence « authentification ».............................................................59
IV.3.3.2. Diagramme de séquence « ajouter patient »..........................................................60
IV.3.3.3. Diagramme de séquence « payer facture »...........................................................61
IV.4. Diagramme de communication....................................................................................62
IV.4.1. Définition..................................................................................................................62
IV.4.2. Formalisme :.............................................................................................................62
IV.4.3. Diagrammes de communication de la solution.........................................................63
IV.4.3.1. Digramme de communication « authentification »................................................63
IV.4.3.2. Digramme de communication « payer facture »....................................................64
Cameroun v
i
IV.5. Diagrammes d’état transition................................................................................................65

IV.5.1. Définition.......................................................................................................................65
IV.5.2. Formalisme....................................................................................................................65
IV.5.3. Diagramme d’état transition de la solution...................................................................66
DOSSIER IV : DOSSIER DE CONCEPTION......................................................................................67
I. DIAGRAMME DE CLASSE..........................................................................................................68
I.1. Définition.................................................................................................................................68
I.2. Formalisme..............................................................................................................................69
I.3. Représentation du diagramme de classe de la solution...........................................................71
II. Diagramme d’objet........................................................................................................................72
II.1. Définition................................................................................................................................72
II.2. Formalisme.............................................................................................................................72
II.3. Diagramme d’objet de la solution...........................................................................................73
III. Diagramme de package............................................................................................................74
III.1. Définition..........................................................................................................................74
III.2. Formalisme.......................................................................................................................74
III.3. Diagramme de paquetage de la solution................................................................................75
IV. DIAGRAMME DE COMPOSANT.............................................................................................76
IV.1. Définition...............................................................................................................................76
IV.2. Formalisme............................................................................................................................76
IV.3. Diagramme de composant de la solution..............................................................................77
DOSSIER V : DOSSIER DE REALISATION......................................................................................78
I. PRESENTATION DE L’ENVIRONEMENT LOGICIEL ET TECHNOLOGIES UTILISEES...79
I.1. XAMPP....................................................................................................................................79
I.1.1. Présentation de xampp....................................................................................................79
I.1.2. Installation de xampp......................................................................................................79
I.2. Langages de programmation et technologies utilisées.............................................................81
II. PRESENTATION DE L’ARCHITECTURE DE L’APPLICATION...........................................82
II.1. Architecture logique................................................................................................................82
II.2. Architecture physique.............................................................................................................83
III. DIAGRAMME DE DEPLOIEMENT.........................................................................................84
III.1. Définition...............................................................................................................................84
III.2. Formalisme............................................................................................................................84
III.3. Diagramme de déploiement de la solution............................................................................86
IV. ASPECT DE SECURITE............................................................................................................87
IV.1. Connexion sécurisée..............................................................................................................87
Cameroun v
ii
IV.2. Sécurisation des mots de passes utilisateurs..........................................................................87

IV.3. Contrôle des formulaires et de sessions................................................................................87
DOSSIER V : GUIDE D’UTILISATION..............................................................................................88
I. PRESENTATION DE NOTRE APPLICATION..........................................................................89
I.1. Présentation des interfaces.......................................................................................................89
I.1.1. Interface de connexion.....................................................................................................89
I.1.2. Interface d’accueil propriétaire........................................................................................90
I.1.3. Interface d’accueil personnel...........................................................................................90
I.2. Les fonctionnalités...................................................................................................................91
II. UTILISATION SOMMAIRE DE NOTRE APPLICATION.......................................................92
II.1. Paramétrage de l’application...................................................................................................92
II.1.1. Interface propriétaire avec menu de paramétrage...........................................................92
I.1.2. Formulaire de d’identification du centre de santé............................................................93
I.1.3. Interface d’enregistrement d’un patient...........................................................................94
I.1.4. Formulaire d’ajout d’un patient........................................................................................95
I.1.5. La liste des patients.........................................................................................................96
I.1.6. Page de présentation de l’état financier............................................................................97
I.1.7. Aperçu du fichier PDF de l’état financier........................................................................98
CONCLUSION......................................................................................................................................99
REFERENCES BIBLIOGRAPHIQUES..................................................................................................x
WEBOGRAPHIE....................................................................................................................................xi
GLOSSAIRE..........................................................................................................................................xii
ANNEXES............................................................................................................................................xiii
TABLE DES MATIERES.....................................................................................................................xiv
Cameroun v
ii
i

Rapport Licence Fabrice Gestion Des Des Hopitaux

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Licence Fabrice Gestion Des Des Hopitaux

Transféré par

Droits d'auteur :

Formats disponibles

MISE SUR PIED D’UN SYSTEME D’INFORMATION HOSPITALIER (SIH) D’AUTOMATISATION DU

PROCESSUS D’ADMISSION ET DE SUIVI DES PATIENTS DANS UN ETABLISSEMENT DE SANTE :

Je dédie ce rapport à ma chère tante,

Nous remercions de ce fait :

LISTE DES FIGURES

Figure 1 : organigramme Univers Binaire Sarl..........................................................................7

Figure 29 : Présentation de l'architecture 3-tiers.......................................................................83

LISTE DES TABLEAUX

Tableau 1 : ressources matérielles d'Univers Binaire Sarl..........................................................8

Afin d’automatiser le processus d’admission et de suivi des patients dans les

Mots clés : système d’information hospitalier, automatisation, processus d’admission, suivi,

In order to automate the process of admission and follow-up of patients in health

Keywords: hospital information system, automation, admission process, follow-up, patient,

PARTIE I : PHASE D’INSERTION

La phase d’insertion est la partie du rapport de stage qui présente la structure

DOSSIER I : DOSSIER D’INSERTION

II. PRESENTATION D’UNIVERS BINAIRE SARL

II.2. Situation géographique

Figure 1 : plan de localisation d'UNIVERS BINAIRE SARL

Source : Archive de l’entreprise

II.4. Activités et réalisations

 Le développement des applications,

Comme exemple de tâches accomplies, nous pouvons mettre en exergue :

 L’application UB BOOKING pour la gestion des agences de voyage fonctionnant

II.5. Organisation et fonctionnement de la structure

Source : Archive de l’entreprise

II.5.2. Présentation de la division de développement

 De La conception et de la réalisation des cahiers de charges techniques ;

II.6. Les partenaires

 MAMESCAM SERVICE : imprimerie,

II.7. Ressources matérielles et logicielles

II.7.1. Ressources matérielles

Tableau 1 : ressources matérielles d'Univers Binaire Sarl

Equipements Marque Quantité

Source : Archive de l’entreprise

II.7.1. Ressources logicielles

 Les systèmes d’exploitation tels que Debian 6.0 et Windows 10

La période d’insertion nous a permis de nous accommoder à l’environnement

PARTIE II : PHASE TECHNIQUE

Apres la prise de connaissance du thème, cette partie a pour but principal la

I. DOSSIER I : CAHIER DES CHARGES

DOSSIER II : CAHIER DES CHARGES

Apres la prise de connaissance du thème, cette partie a pour but principal la

I. CONTEXTE ET JUSTIFICATION DU PROJET

I. CONTEXTE ET JUSTIFICATION DU PROJET

II. LES OBJECTIFS DU PROJET

II.2. Objectifs spécifiques

 Mettre en place un outil SIH culturellement et économiquement supportable.

III. SPECIFICATION DES BESOINS

III.1.1. Module « PATIENT »

 De modifier les données administratives (identité + contacts) d'un patient ;

III.1.2. Module « ADMISSIONS »

• consulter la liste des patients ambulatoires ;

• libérer un patient ambulatoire : l'admission en cours est alors archivée.

Ce sous-module et le sous-module « Hospitalisations » sont d'une manière ou d'une

• savoir exactement où (salle et lit) est hospitalisé un patient donné ;

III.1.3. Module « Facturation »

III.1.4. Module « Gestion automatisée des rendez-vous »

III.1.5. Module « Calendrier de consultation des médecins »

III.1.6. Module « Système d'alerte »

 Connaître de façon automatique le calendrier vaccinal d'un patient (quand un vaccin

 Savoir si un traitement donné n'est plus efficace ;

III.1.8. Module « Administration du système »