Memoirengagnethiamfinal 160927130825

REPUBLIQUE DU SENEGAL
***** * * ********
UNIVERSITE CHEIKH ANTA DIOP DE DAKAR
ECOLE SUPERIEURE POLYTECHNIQUE

DEPARTEMENT GENIE INFORMATIQUE
MEMOIRE DE FIN DE CYCLE
Pour l’obtention du :
DIPLOME D’INGENIEUR DE CONCEPTION (DIC)
SUJET : Etude et mise en place d’un système d’information

hospitalier (SIH) basé sur le cloud
Lieu de stage : Période stage : 03/2016 – 07/2016
Présenté et soutenu par Professeur encadreur Maitres de stage
Ngagne THIAM Dr Ibrahima FALL Mme Seynabou Sy DIARRA
Mme Dior Fall Lo
Année universitaire : 2015 – 2016

Etude et mise en place d’un Système d’Information Hospitalier (SIH) basé sur le cloud
1
REPUBLIQUE DU SENEGAL
***** * * ********
UNIVERSITE CHEIKH ANTA DIOP DE DAKAR
Chapitres II :
Analyse
ECOLE SUPERIEURE et
POLYTECHNIQUE
spécification
DEPARTEMENT GENIE INFORMATIQUE
des besoins
MEMOIRE DE FIN DE CYCLE
Pour l’obtention du :
DIPLOME D’INGENIEUR DE CONCEPTION (DIC)
SUJET : Etude et mise en place d’un Système d’Information

Hospitalier (SIH) basé sur le cloud
Lieu de stage : Période stage : 03/2016 – 07/2016
Présenté et soutenu par Professeur encadreur Maitres de stage
Ngagne THIAM Dr. Ibrahima FALL Mme Seynabou Sy DIARRA
Mme Dior Fall LO
Année universitaire : 2015 – 2016
2
Dedicaces
Au nom d’ALLAH (SWT) le tout miséricordieux, à son messager Mohammed (SWT) le parfait
et ses compagnons et à notre guide Cheikh Ahmadou Bamba MBACKE.
Je dédie ce mémoire à :
 Ma grand-mère Ndeye Fatma NDIAYE ôtée de ce monde en Janvier 2011. Nous
n’oublierons jamais vos conseils. Que DIEU lui épargne de souffrance et l’élève
au rang des graciés ;
 Mes parents Bounama et Fatou LO qui nous ont toujours encouragé dans la quête
du savoir et qui continuent à nous soutenir dans les bons comme dans les
mauvais moments;
 Mon père Aliou THIAM, ainé et référence de toute la famille, ainsi qu’à ses
femmes ;
 Serigne Abdoul Khadim MBACKE pour ses prières, conseils et
encouragements ;
 Mes grands frères et sœurs qui n’ont jamais cessé de nous aider, nous encourager
dans le travail, nous encadrer durant les études et nous montrer les voies de
partage des biens communs à toute la famille ;
 Mon oncle Ali LO ainsi qu’à sa famille ;
 Toutes les femmes qui vivent sous le couvert de notre père Aliou THIAM à
Mboro ou ailleurs ;
 Tous les membres de notre famille vivant à Dakar ;
 Tous mes amis ;
 Tous les membres du Dahira Mafaatihul Bichri UGB Saint Louis ;
 Tous les membres du Dahira Neytoul Maram Castors ;
 Tous les membres de la cellule ESP du Dahira Madjmahou Noreyni UCAD en
particulier Bamba MBOUP ;
 Tous les locataires du G3 Village E de l’UGB ;
 Tous mes fielleux en particulier Dienaba BA, Mame Diarra Bousso DJITTE,
Abdoulaye SENE et Abdoul NDIAYE ;
3
Remerciements
J’adresse mes remerciements les plus sincères à :
 Dr Gervais MENDY, Chef du département Génie Informatique, pour
l’enseignement de qualité dont nous bénéficions ;
 Dr Ibrahima FALL pour avoir accepté de nous encadrer et pour sa disponibilité,
ses remarques et suggestions tout au long de la rédaction de ce présent
mémoire ;
 Dr Mandicou BA pour sa disponibilité et ses conseils ;
 Tout le personnel de l’entreprise FINETECH en particulier Madame Seynabou
Sy DIARRA et Madame Dior Fall LO pour l’encadrement à entreprise ;
 Monsieur Ahmadou Bamba NDIAYE, contrôleur des impôts et des domaines
en service au Centre des Moyennes Entreprises pour sa contribution à la
rédaction de ce document ;
 Tout le personnel enseignant et administratif du département Génie
Informatique et de l’Ecole Supérieure Polytechnique de Dakar ;
 Toute la promotion DIC 2013/2016 en particulier Khadim DIOP, Mamadou
KHOUSSA (Co Master), Latyr NDIAYE, Assiétou NDIAYE et Ibrahima
KANE ;
 Tous mes parrains de la promotion 2012/2015 en particulier Serigne Modou
GUEYE et Coumba Dior DIENG ;
 Tous les stagiaires de finapps (filiale de FINETECH) ;
 Toutes les personnes qui ont, de près ou de loin, contribuées à mes études.
4
5
Avant-propos
L’Ecole Supérieure Polytechnique de Dakar (ESP) est un établissement public de

formation professionnelle doté d’une personnalité juridique et d’une autonomie financière. Elle
fait partie intégrante de l’Université Cheikh Anta Diop de Dakar(UCAD).
Elle a été créée en 1994 et a pour mission de former tant sur le plan théorique que pratique des
techniciens supérieurs, des ingénieurs technologues, des ingénieurs de conception, des
managers en gestion d’entreprise et des docteurs ; de dispenser un enseignement supérieur en
vue de préparer aux fonctions d’encadrement dans divers domaines tels que la production, la
recherche appliquée, etc.
L’ESP compte (6) départements et dans le cadre de leur formation les étudiants qui sont en fin
de cycle sont tenus d’effectuer un stage pratique au sein d’une entreprise ou d’un service
informatique.
Ce stage permet à l’étudiant :
 de renforcer son savoir et surtout d’acquérir un savoir-faire, tout en essayant d’adapter
ses connaissances aux cadres de la vie professionnelle.
 de travailler sur un projet de fin d’études et de mener à bien l’élaboration de celui-ci
depuis l’étude préalable jusqu’à sa mise en œuvre.
A l’issue de ce stage, on procède à la rédaction d'un mémoire présentant les tâches accomplies.
C'est ainsi que nous avons effectué un stage de cinq mois au cours duquel nous avons travaillé
sur le sujet suivant : Etude et mise en place d’un Système d’Information Hospitalier (SIH) basé
sur le cloud.
6
Résumé
Le secteur de la santé fait partie des secteurs qui traitent beaucoup d’information à travers les
nombreuses structures médicales existant dans le monde. Ce mémoire porte sur l’étude et la
mise en œuvre d’un système d’information pour ces structures sanitaires sous forme de services
basés sur le cloud et pour le compte de l’entreprise FINETECH. Ce système d’information est
composé de plusieurs modules intégrés et où l’information sur le patient représente la base de
données centrale. Ce document comporte en premier lieu, une présentation de FINETECH et
du sujet suivi d’une définition de la méthode de développement utilisée qui est mixte car
composée de pratiques issues de Scrum et de XP. En deuxième lieu, il comprend les éléments
d'analyse et de spécification des besoins en utilisant le formalisme d’UML. Il présente, en
troisième lieu, la conception de la solution proposée. Enfin, la dernière partie du document est
dédiée à la mise en œuvre de la solution basée sur un ensemble d’outils et technologies identifiés
depuis la conception.
7
Abstract
The health sector is one of sectors which process a lot of information through the many existing
medical structures in the world. This memory focuses on the study and implementation of an
information system for these health facilities in the form of cloud-based services and on behalf
of the company FINETECH. This information system consists of several integrated modules
and where patient information is the central database. This document includes first, a
presentation of FINETECH and the subject followed by a definition of the development method
used which is mixed as composed practices from Scrum and XP. Secondly, it includes the
elements of analysis and specification of requirements using the UML notation. It presents,
third, the design of the proposed solution. The last part of the document is dedicated to the
implementation of the solution based on a set of tools and technologies identified from design.
8
Table des matières
Sigles et Significations ______________________________________________________ 11

Table des figures ___________________________________________________________ 12
Table des tableaux _________________________________________________________ 14
Introduction ______________________________________________________________ 15
Chapitre I : Présentations générales ___________________________________________ 17
I.1 Présentation de la structure d’accueil ___________________________________________ 17
I.1.1 Pôle audit & conseils _____________________________________________________________ 17
I.1.2 Pôle support technique et formation _________________________________________________ 17
I.1.3 Pôle technologies & monétique _____________________________________________________ 18
I.1.4 Pôle business solutions ___________________________________________________________ 18
I.2 Présentation du sujet ________________________________________________________ 19

I.2.1 Définitions de concepts et contexte du sujet ____________________________________________ 19
I.2.1.1 La notion de système d’information hospitalier (SIH) __________________________________ 19
I.2.1.2 Définition des concepts métiers ___________________________________________________ 20
I.2.1.3 Les objectif d’un SIH ____________________________________________________________ 21
I.2.1.4 Les modules du SIH _____________________________________________________________ 21
I.2.1.5 Le Cloud ______________________________________________________________________ 23
I.2.1.6 SaaS _________________________________________________________________________ 23
I.2.1.7 Le contexte du sujet : ___________________________________________________________ 23
I.2.2 Problématique ____________________________________________________________________ 23
I.2.3 les objectifs _______________________________________________________________________ 24
I.3 Définition de la méthode de développement _____________________________________ 25

I.3.1 L'approche agile ___________________________________________________________________ 26
I.3.2 La méthode Scrum _________________________________________________________________ 27
I.3.3 La méthode XP ____________________________________________________________________ 28
I.3.4 Définition de notre méthode de développement _________________________________________ 28
Chapitres II : Analyse et spécification des besoins ________________________________ 32

II.1 Analyse des besoins non fonctionnels ___________________________________________ 32
II.2 Analyse des besoins fonctionnels ______________________________________________ 33
II.2.1 Analyse globale du SIH _____________________________________________________________ 33
II.2.3 Analyse fonctionnelle par module ____________________________________________________ 35
II.2.3.1 Analyse fonctionnelle du module "Référentiel" ______________________________________ 35
II.2.3.2 Analyse fonctionnelle du module "Gestion des patients" ______________________________ 48
Chapitre III : Conception _____________________________________________________ 58

III.1 Définition et analyse d'une architecture du système d'information___________________ 58
III.1.1 Définition d’une architecture du système d’information __________________________________ 58
III.1.2 L’utilité d’une architecture structurée et planifiée _______________________________________ 58
III.1.3 L’apport d’une architecture orientée service ___________________________________________ 59
III.1.4 Architecture Modèle-Vue-Contrôleur (MVC) ___________________________________________ 60
III.1.5 Style architectural REST ____________________________________________________________ 61
9
III.1.6 Architecture Logicielle Distribuée basée sur les Micro services (ALDM) ______________________ 62
III.1.6 Architecture du SIH________________________________________________________________ 63
III.2 Présentation des outils et technologies utilisés ___________________________________ 64

III.2.1 La plate-forme de développement d’application web Java EE ______________________________ 64
III.2.2 Le Framework Spring ______________________________________________________________ 65
III.2.3 Le Framework AngularJS ___________________________________________________________ 69
III.2.4 Serveur de base de données PostgreSQL ______________________________________________ 70
III.2.5 Postman ________________________________________________________________________ 70
III.2.6 Log4J ___________________________________________________________________________ 71
III.2.7 Maven __________________________________________________________________________ 71
III.2.8 Tomcat _________________________________________________________________________ 72
III.3 Implémentation de l’architecture ______________________________________________ 72

III.3.1 Architecture par modules___________________________________________________________ 72
III.3.2 Architecture du SIH________________________________________________________________ 73
III.3.3 Architecture globale de la solution ___________________________________________________ 74
III.4 Conception d’un cas d’utilisation ______________________________________________ 75

III.4.1 Modèle dynamique du cas d’utilisation "Ajouter/structure" _______________________________ 75
III.4.1.1 Par le moyen d’un diagramme de séquence de conception ____________________________ 75
II.4.1.2 Par le moyen d’un diagramme de classe de conception _______________________________ 77
III.5 La gestion des erreurs et de la traçabilité________________________________________ 78

Chapitres IV : Mise en œuvre de la solution _____________________________________ 80
IV.1 Environnement de développement ____________________________________________ 80
IV.1.1 Eclipse __________________________________________________________________________ 80
IV.1.2 PhpStorm _______________________________________________________________________ 80
IV.1.3 JUnit ___________________________________________________________________________ 81
IV.1.5 Git _____________________________________________________________________________ 81
IV.1.6 WAMPServer ____________________________________________________________________ 81
IV.1.7 Visual Paradigm __________________________________________________________________ 81
IV.2 Présentation de la solution ___________________________________________________ 82

V.3 Déploiement de la solution ___________________________________________________ 86
Conclusion générale ________________________________________________________ 87
Référence ________________________________________________________________ 87
10
Sigles et Significations
Sigles Significations
ALDM Architecture Logicielle Distribuée basée sur les Micro services
API Application Programming Interface
ATIH Agence Technique de l'Information sur l'Hospitalisation
AuthN Authentification
AuthZ Autorisation
CSRF Cross-Site Request Forgery
DAO Data Access Object
DNS Domain Name System
DMA Dossier Médico-Administratif
DM Dossier Médical
DPI Dossier médical de Patient Informatisé
EJB Entreprise Java Bean
ESB Entreprise Service Bus
FINETECH FINance Expertise & TECHnologies
HAL Hypertext Application Language
HTML HypertText Markup Language
HTTP HyperText Transport Protocol
HTTPS HyperText Transport Protocol Secure
EDI Environnement de Développement Intégré
IoC Injection of Controller
JCP Java Community Process
Java EE Java Edition Entreprise
JDBC Java DataBase Connectivity
JSP Java Servlet Page
JSON JavaScript Object Notation
LDAP Lightweight Directory Access Protocol
MVC Modele View Controller
OMG Object Management Group
OMS Organisation Mondial de la Santé
OWASP Open Web Application Security Project
PGI Progiciel de Gestion Intégré
REST REpresentational State Transfer
SaaS Software as a Service
SDK Software Development Kit
SI Système d’Information
SIH Système d’Information Hospitalier
SOA Service Oriented Architecture
SSI Sécurité Système Information
SSO Single Sign-On
UX User eXperience
UML Unified Modeling Language
XP eXtreme Programming
XSS Cross-Site Scripting
11
Table des figures
Figure 1 : Les différents modules du SIH ............................................................................................... 21

Figure 2 : Vue globale de la méthode Scrum (NEUMANN, 2016) ......................................................... 27
Figure 3 : Cycle de XP – Wikipédia ........................................................................................................ 28
Figure 4 : Les diagrammes d'UML ......................................................................................................... 30
Figure 5 : Fonctionnalités globale du système ...................................................................................... 34
Figure 6 : Découpage des modules du SIH en package et les relations entre eux ................................ 34
Figure 7: Les fonctionnalités du module "Référentiel" ......................................................................... 36
Figure 8 : Interactions entre un utilisateur et le SIH pour la réalisation de la fonctionnalité
"S'authentifier" ...................................................................................................................................... 38
Figure 9 : Interactions entre le super administrateur et le SIH pour la réalisation de la fonctionnalité
"Ajouter une structure"......................................................................................................................... 40
"consulter/supprimer une structure" ................................................................................................... 42
"Consulter/Modifier une structure" ...................................................................................................... 44
Figure 12 : Interactions entre le super administrateur et SIH pour consulter la liste des structures ... 45
Figure 13 : Liste des entités métiers du module "Référentiel" ............................................................ 46
Figure 14 : Les activités dans le module "Gestion des patients" .......................................................... 49
Figure 15 : Les fonctionnalités du module "Gestion des patients" ....................................................... 50
Figure 16 : Interactions entre un personnel de soin et le SIH pour "Effectuer une demande" ........... 53
Figure 17 : Interactions entre personnel de soin et SIH pour "Produire un document" ...................... 55
Figure 18 : Liste des entités du module "Gestion des patients" ........................................................... 56
Figure 19 : Autres avantages d'une architecture en SOA ..................................................................... 60
Figure 20 : Exemple d'architecture en SOA d’un SIH ............................................................................ 60
Figure 21 : Les différentes composantes de l'architecture du modèle-vue-contrôleur ....................... 61
Figure 22 : L’architecture d’un micro service (Youssfi, 2015) ............................................................... 63
Figure 23 : Architecture du SIH ............................................................................................................. 63
Figure 24 : L'architecture globale de spring Framework (Pivotal Software, 2016) ............................... 66
Figure 25 : Fonctionnement de Spring .................................................................................................. 67
Figure 26 : Architecture d’AngularJS ..................................................................................................... 69
Figure 27 : Implémentation de l'architecture pour chaque module..................................................... 72
Figure 28 : Implémentation de l'architecture du SIH ............................................................................ 73
Figure 29 : Architecture globale de la solution proposée ..................................................................... 74
Figure 30 : Différentes étapes traversées par un message émis par un acteur.................................... 76
Figure 31 : Modèle dynamique pour le cas "ajouter une structure" : Diagramme de classe de
conception ............................................................................................................................................. 77
Figure 32 : Les classes utilisées dans la gestion des erreurs ................................................................. 78
Figure 33 : Classe abstraite de base ...................................................................................................... 79
Figure 34 : Formulaire d'authentification ............................................................................................. 82
Figure 35 : Formulaire d'authentification avec une violation des règles .............................................. 83
Figure 36 : Vue du super administrateur .............................................................................................. 83
Figure 37 : Vue d'un médecin traitant de la structure HFDK ................................................................ 84
12
Figure 38 : Vue de l'administrateur créateur de la structure HFDK ...................................................... 84
Figure 39 : Vue de l'administrateur validateur de la structure HFDK ................................................... 84
Figure 40 : Vue Ajouter Structure ......................................................................................................... 85
Figure 41 : Vue lister les structures abonnées ...................................................................................... 85
Figure 42 : Les micro services clients au serveur Eureka déployés ....................................................... 86
Figure 43 : Tentative d'authentification d'un utilisateur ...................................................................... 86
Figure 44 : Le déploiement de la solution ............................................................................................. 87
13
Table des tableaux
Tableau 1 : Scénario nominal de la description textuelle de la fonctionnalité "S'authentifier"........... 37

Tableau 2 : Premier scénario alternatif de la description textuelle de la fonctionnalité "S'authentifier"
............................................................................................................................................................... 37
Tableau 3 : Deuxième scénario alternatif de la description textuelle de la fonctionnalité
"S'authentifier" ...................................................................................................................................... 38
Tableau 4 : Scénario d'erreur de la description textuelle de la fonctionnalité "S'authentifier"........... 38
Tableau 5 : Scénario nominal de la description textuelle de la fonctionnalité "Ajouter une structure"
............................................................................................................................................................... 39
Tableau 6 : Scénario alternatif de la description textuelle de la fonctionnalité " Ajouter une structure"
............................................................................................................................................................... 39
Tableau 7 : Scénario nominal de la description textuelle de la fonctionnalité "Consulter/Supprimer
une structure" ....................................................................................................................................... 41
Tableau 8 : Scénario alternatif de la description textuelle de la fonctionnalité "Consulter/Supprimer
une structure" ....................................................................................................................................... 41
Tableau 9 : Scénario nominal de la description textuelle de la fonctionnalité "Consulter/Modifier une
structure" .............................................................................................................................................. 43
Tableau 10 : Scénario alternatif de la description textuelle de la fonctionnalité "Consulter/Modifier
une structure" ....................................................................................................................................... 43
Tableau 11 : Scénario nominal de la description textuelle de la fonctionnalité "Consulter les
structures" ............................................................................................................................................. 45
Tableau 12 : Scénario nominal de la description textuelle de la fonctionnalité "Effectuer une
demander"............................................................................................................................................. 52
Tableau 13 : Scénario alternatif de la description textuelle de la fonctionnalité "Effectuer une
demander"............................................................................................................................................. 52
Tableau 14 : Scénario nominal de la description textuelle de la fonctionnalité "Produire un
document" ............................................................................................................................................. 54
Tableau 15 : Scénario alternatif de la description textuelle de la fonctionnalité "Produire un
document" ............................................................................................................................................. 54
14
Introduction
Actuellement, le monde connaît des avancées technologiques importantes dans tous les
secteurs et cela grâce à l’informatique qui "est un domaine d'activité scientifique, technique et
industriel concernant le traitement automatique de l'information" (Wikipédia, 2016). Le secteur
sanitaire n’est pas laissé en rade. Pour les établissements sanitaires, la cohérence, la fiabilité et
la précision de l’information sont des éléments déterminants dans le fonctionnement de tous
les jours. En effet, chaque acteur du domaine de la santé est amené à collecter, traiter et restituer
de l’information. Tout le processus du métier est centralisé sur l’information. L’homme
commet naturellement des erreurs. C’est donc un impératif de trouver un moyen permettant de
collecter, traiter, restituer et sauvegarder automatiques de l’information et cela de manière sûre.
Pour ce faire, un système d’information s’avère une solution nécessaire afin de permettre la
gestion de toutes les informations qui gravitent autour du patient mais aussi des informations
administratives et financières. La vocation d’une structure sanitaire n’est pas de gérer un
système d’information et toutes les ressources matérielles et humaines nécessaires à son bon
fonctionnement. Avec l’évolution des technologies, il est actuellement possible d’avoir un
système d’information sans avoir un serveur physique et localisé dans les locaux de la structure
en utilisant le cloud.
C’est dans ce contexte que s’insère le travail présenté dans ce document qui porte sur l’étude et
la mise en place d’un système d’information hospitalier fonctionnel pour toute structure
sanitaire sollicitant le service auprès de l’entreprise propriétaire. Ce système d’information est
un progiciel de gestion intégré (PGI) composé de plusieurs modules : référentiel, gestion des
patients, des hospitalisations, des rendez-vous, des stocks pharmaceutiques, des consultations
externes, des factures des prestations et du plateau technique.
Le reste du document est organisé en quatre (4) chapitres :
 le premier chapitre, intitulé "Présentations générales", fait une description de la structure

d’accueil en l’occurrence FINETECH de même qu’une présentation de notre sujet
suivie d'une définition de la méthode de développement utilisée ;
 le deuxième chapitre quant à lui s'intitule "Analyse et spécification des besoins". Nous
y procédons à l’analyse et à la spécification des besoins non fonctionnels et
fonctionnels ;
15
 le troisième chapitre intitulé "Conception de la solution" présente les différentes
architectures de la solution, les outils et technologies utilisés et, enfin, la
conception d’un cas d’utilisation;
 le quatrième et dernier chapitre porte sur la "Mise en œuvre de la solution". Il présente
l’environnement de développement et une synthèse illustrée des résultats obtenus.
16
Chapitre I : Présentations générales
Ce chapitre présente en premier lieu la structure au sein de laquelle le stage a été

effectué, en deuxième lieu le sujet sur lequel se porte le travail présenté dans ce document et,
en dernier lieu, la méthode de développement utilisée pour mener le projet.
I.1 Présentation de la structure d’accueil

FINETECH (FINance Expertise & TECHnologies) est un cabinet de conseil en organisation et
transformation d’entreprises, d’audit et de prestations en systèmes d’information. Il exerce
dans plusieurs pôles.
I.1.1 Pôle audit & conseils

 Accompagnement : FINETECH accompagne ses clients dans la conduite de
leurs projets de mise en place ou d’évolution de systèmes d’information par une
offre d’assistance à la maîtrise d’ouvrage qui va de l’élaboration du cahier des
charges au suivi postproduction ;
 Organisation : FINETECH assiste ses clients dans la conception et la mise en
œuvre de leurs stratégies de transformation d’entreprise par une offre de refonte
et d’optimisation de leurs processus métiers, d’élaboration de procédures et de
schémas directeurs ;
 Audit : FINETECH assiste ses clients dans la sécurisation de leurs activités par
l’établissement de plans d’audit pluriannuels, la conception de recueils de
sécurisation des processus opératoires, l’élaboration de guides pratiques de
contrôle interne, l’audit organisationnel et technique de leur système
d’information.
I.1.2 Pôle support technique et formation
FINETECH permet à ses partenaires de gérer leurs environnements techniques en leur offrant
les services ci-après :
 Installation systèmes et bases de données Oracle ;
 Optimisation de bases de données Oracle ;
 Maintenance proactive des bases de données ;
 Accompagnement, gestion et conduite de projet d’infrastructures ;
 Mise en place d’architectures de secours sur sites de backup ;
 Elaboration et mise en œuvre de plans de continuité d’activités de formations.
17
FINETECH propose des formations en administration Oracle et sur les outils de développement
Oracle Internet Developper Suite. Sa stratégie d’éditeur de logiciels lui permet de maintenir le
niveau de ses ressources humaines à la pointe de la technologie de conception et de réalisation
des applications.
FINETECH propose également des programmes de formation dans les domaines de la
gouvernance informatique, du management des systèmes d’information, de l’audit et du
contrôle interne, du rôle du contrôle dans les structures informatiques.
I.1.3 Pôle technologies & monétique
 Télécoms : FINETECH, partenaire de l’équipementier RADWIN fournit aux
opérateurs télécoms, aux ISP et aux entreprises des solutions de Boucle Locale
Radio pour l’interconnexion de leurs sites ;
 Réseaux : FINETECH fournit et installe des systèmes de monitoring et
d’analyse des performances des réseaux de ses partenaires. Elle assure
également l’Audit Sécurité des réseaux informatiques ;
 Services monétiques : FINETECH offre des prestations d’assistance à la
maîtrise d’ouvrage et intègre des solutions de paiement pour les banques, les
institutions de microfinance, les compagnies pétrolières. Elle fournit également
des solutions de personnalisation de cartes et d'identification sécurisée ;
 Sécurité : FINETECH est spécialisée dans la fourniture et l'installation des
systèmes sécuritaires d’identification, de vidéosurveillance et de contrôle
d'accès ;
 Archivage numérique : FINETECH accompagne ses partenaires dans les projets
de mise en place de solutions d’archivage numérique informatiques.
I.1.4 Pôle business solutions
FINETECH propose à ses clients à travers le pôle Business Solutions une gamme de produits
de gestion performants pour la maitrise de leur activité.
 NAFA Microfinance offre aux institutions de microfinance une solution
intégrée et complète de gestion et de suivi de leur activité ;
 NAFA GRC est un produit de gestion clientèle conçu pour les sociétés qui
commercialisent l’eau, l’électricité ou le téléphone. Il intègre les processus
d’abonnement, de facturation, de recouvrement et permet de prendre en
charge toute la relation client ;
 NAFA Scolarité est un logiciel spécialisé dans la gestion des établissements
scolaires et universitaires. Il gère les processus d’inscription, l’organisation et
18
le suivi des enseignements, les évaluations et examens, les stages et formations
des enseignants ;
 FINETECH Business Solution propose aussi des solutions sur mesure par la
réalisation d’applications spécifiques sur commande ou développées en régie
avec les équipes du client. Grâce à son expertise sur les outils de reporting et de
pilotage comme business objet, FINETECH accompagne ses partenaires dans
la mise en œuvre de systèmes décisionnels.
Par la suite nous présenterons le projet en donnant le contexte, la problématique et les objectifs
fixés.
I.2 Présentation du sujet

Cette section présente le sujet du présent mémoire. C'est ainsi qu'il s’est agi pour nous de traiter
du contexte à travers une définition des concepts jugés utiles pour la compréhension du sujet,
ensuite de traiter de la problématique et, enfin, de définir les objectifs attendus du stage.
I.2.1 Définitions de concepts et contexte du sujet
I.2.1.1 La notion de système d’information hospitalier (SIH)
Il existe plusieurs définitions du SIH dont celle de Gérard PONÇON qui le définit comme suit
"Le système d'information hospitalier est inséré dans l'organisation "hôpital" en perpétuelle
évolution; il est capable, selon des règles et modes opératoires prédéfinis, d'acquérir des
données, de les évaluer, de les traiter par des outils informatiques ou organisationnels, de
distribuer des informations contenant une forte valeur ajoutée à tous les partenaires internes ou
externes de l'établissement, collaborant à une œuvre commune orientée vers un but spécifique,
à savoir la prise en charge d'un patient et le rétablissement de celui-ci" (PONÇON, 2000 ) . De
cette définition, nous pouvons tirer qu’un SIH est la solution de production, d’échange et de
partage des informations de gestion, financières, techniques et médicales dans un établissement
hospitalier. Le SIH est une solution modulaire composée de plusieurs applications métiers
intégrées fonctionnant autour d’un référentiel unique et où les informations sur les patients
constituent la base de données centrale. Prenant en charge les processus de gestion selon la
technique du Workflow depuis l’admission jusqu’à la sortie en passant par les spécialités du
plateau technique, le SIH prend en charge les informations identificatrices, administratives et
financières du patient véhiculées à travers un identifiant unique.
Les principales structures sanitaires pouvant mettre en place un SIH sont :
 Les hôpitaux ;
 Les cliniques ;
19
 Les centres d’analyses ;
 Les centres de soins ;
 Les cabinets médicaux.
I.2.1.2 Définition des concepts métiers
Avant de parler des structures sanitaires, nous allons parler d’abord du système sanitaire. Un
système sanitaire est défini comme "toutes les activités, officielles ou non, qui portent sur les
services de santé, mis à la disposition d'une population, et sur l'utilisation de ces services par la
population" (OMS).
Une structure de santé est un établissement de santé public ou privé qui dispose des moyens
humains (médical, paramédical, administratif, etc.) et des moyens matériels où sont dispensés
les activités d’un système sanitaire.
Il existe plusieurs concepts métiers liés aux structures sanitaires. Nous définissons ci-après
certains parmi eux que nous jugeons très importants pour la suite du document.
 patient : C’est celui autour de qui est centrée toute l’activité des autres acteurs ;
 les professionnels de santé : médecins, dentistes, pharmaciens, etc.
 prestation : Une prestation est un service rendu par un personnel de soin à un patient ;
 dossier médical : dossier dans lequel sont retracées toutes les prestations concernant le
patient ;
 dossier médico-administratif : Dossier contenant toutes les informations administratives
du patient ;
 hospitalisation : C’est l’admission du patient dans une structure sanitaire ;
 les professionnels paramédicaux : kinésithérapeutes, infirmières, pédicures,
podologues, orthophonistes, orthoptistes, ergothérapeutes, etc.
 plateau technique : L'ensemble des installations et équipements biomédicaux,
techniques et informatiques permettant au personnel de soin de réaliser les prestations ;
 les fournisseurs de biens médicaux : audioprothésiste, oculariste, opticien-lunetier,
orthopédiste-orthésiste, orthoprothésiste, etc.
 personnel de soin : Toute personne qui peut intervenir dans le processus de soins :
professionnels de santé, professionnel paramédicales, etc.
 données sensibles : toutes les données à caractère personnel relatives aux opinions ou
activités à la santé ;
20
 données dans le domaine de la santé : toute information concernant l'état physique et
mental d'une personne concernée, y compris les données génétiques.
I.2.1.3 Les objectif d’un SIH

Les SIH visent principalement l’amélioration de la qualité de soin en passant par l’amélioration
de la communication, la réduction des délais d’attente, l’aide à la prise de décision. Ils cherchent
aussi à maitriser les coûts par la réduction des durées de séjours des patients, la réduction des
tâches administratives, la diminution du personnel.
I.2.1.4 Les modules du SIH

Dans le cas de ce projet, le SIH est un système modulaire composé de huit (8) modules (figure
1) :
Figure 1 : Les différents modules du SIH
 Référentiel :
Ayant un rôle central, le référentiel est l’ossature normative de tout le système. Ce
module a trois déclinaisons correspondant à trois sous- modules:
o la prise en charge des codifications générales caractérisant la gestion
hospitalière ;
o la prise en charge des éléments tarifaires associés aux actes aux fins de
facturation automatique ;
21
o les éléments de paramétrage technique de sécurité, d’habilitation, de traçabilité
et d’ergonomie.
 Gestion des patients :
Ce module est utilisé par tous les autres modules du système d'information hospitalier
et se base sur l’identification des patients par l’attribution d’un index à chaque patient
se présentant à l’hôpital pour une prestation souhaitée.
 Gestion des rendez-vous :
Tout comme le module gestion des patients, ce module est aussi utilisé par tous les
autres modules du SIH. Il permet de suivre l’ensemble des rendez-vous dans la structure
sanitaire.
 Gestion des hospitalisations :
Ce module permet de suivre l’hospitalisation d’un patient dès son entrée à l’hôpital
jusqu’à la sortie, en tenant compte des transferts interservices, des autorisations de sortie
et des différentes prescriptions et demandes effectuées par les médecins traitants.
 Gestion des consultations externes :
Ce module est utilisé pour les consultations des patients venant d’une autre structure
sanitaire.
 Gestion du plateau technique :
La gestion du plateau technique peut être subdivisée en trois (3) autres sous modules
qui sont :
o la gestion des laboratoires ;
o la gestion de l’imagerie médicale ;
o la gestion des blocs opératoires.
 Gestion des stocks pharmaceutiques :
La gestion des stocks pharmaceutiques est un module destiné à gérer les articles
spécifiques tels que les médicaments, les réactifs, etc. depuis le cycle d’achat jusqu’à la
tenue des stocks en pharmacie et au réapprovisionnement.
22
 Gestion de la facturation des prestations :
Ce module permet de collectionner, centraliser, valoriser automatiquement les

prestations et les consommations des patients et l’élaboration des factures.
I.2.1.5 Le Cloud
Le Cloud (ou cloud computing) est une technologie qui permet de mettre sur des serveurs
localisés à distance des données de stockage ou des logiciels qui sont habituellement stockés
sur l'ordinateur d'un utilisateur, voire sur des serveurs installés en réseau local au sein d'une
entreprise". (le-cloud.net, 2016)
I.2.1.6 SaaS
Le SaaS (Software as a Service) est une forme de cloud. Il désigne une application, mise à
disposition à distance par un fournisseur, et accessible par le biais d’un navigateur internet. Elle
est aussi louée, au mois ou à l’usage et sa mise à jour est automatique (journaldunet, 2016).
I.2.1.7 Le contexte du sujet :

Le domaine de la santé regroupe l’ensemble des organisations, des institutions, des ressources
et des personnes dont l’objectif principal est d’améliorer la santé. Il est aujourd’hui un secteur
très saturé, ce qui permet aux moyennes et grandes structures sanitaires de voir le jour. Ces
structures remplissent principalement quatre fonctions essentielles: la prestation de services, la
création de ressources, le financement et la gestion administrative. La gestion de ces fonctions
rencontre de nombreux obstacles liés particulièrement à l’accès aux soins, aux modalités de
financement du secteur, à la production et la productivité des structures sanitaires notamment
par la pénurie des prestataires de service et le grave déficit qualitatif et quantitatif en
professionnels de santé (who, 2016). Ces structures cherchent de plus en plus à informatiser
leur métier comme le montre une étude faite en 2015 dans (ATIH, 2015) qui montre que la
demande d’informatisation des structures sanitaire à augmenter de 8% entre 2014 et 2015.
Dans le souci de permettre aux structures d’atteindre leurs objectifs, l’entreprise FINETECH
compte mettre en place un service cloud (SaaS en particulier) fournissant un système
d’information hospitalier selon le besoin de la structure.
I.2.2 Problématique
La plupart des structures sanitaires fonctionnent manuellement. Pour enregistrer un patient, le
service d’accueil dispose d’un registre au format papier qui contient toutes les informations
administratives du patient. De même, une fiche de patient (dossier médical) est utilisée pour
enregistrer toutes les prestations effectuées par le patient. Ces dossiers médicaux sont ensuite
23
rangés dans des armoires. A chaque venue du patient, un personnel de soin est obligé d’aller
rechercher le dossier médical pour pouvoir effectuer une prestation. Ainsi, pour partager
l’information sur le patient, il faut déplacer physiquement sa fiche de services en services.
Aujourd’hui, on parle de Dossier médical de Patient Informatisé (DPI) ; c’est un concept
intéressant mais qui tarde à devenir une réalité. Certaines structures sanitaires disposent des
logiciels de gestion mais qui ne sont pas intégrés. En outre, on assiste à une éclosion sans cesse
des spécialités médicales et donc plusieurs services rendus dans une même structure sanitaire ;
cela contribue à complexifier la prise de décision à plusieurs niveaux. En prenant en compte
ces différents aspects, les problèmes ci-après se sont dégagés :
 une orientation difficile des patients;
 l’augmentation du coût de prise en charge des patients ;
 une communication difficile entre le personnel médical qui peut retarder les
prises de décision ;
 la non-traçabilité des données ;
 la non-maitrise du processus thérapeutique qui entraine une mauvaise qualité de
soins;
 un manque d’intégration d’un système d’information hospitalier ;
 une perte de temps dans les processus de recherche des informations relatives au
patient ;
 une incapacité de prévenir les maladies.
 etc.
I.2.3 les objectifs
Au vu des principaux problèmes identifiés dans les structures sanitaires, la tâche qui nous est
assignée est d’étudier leur fonctionnement en ayant un niveau d’abstraction permettant de
mettre en place un service cloud fournissant un système d’information hospitalier utilisable
pour n’importe quelle structure sanitaire souhaitant ce service auprès de l’entreprise. Une fois
cette phase d’étude effectuée, il s'agira de mettre en place :
 le socle de base commun à tous les modules ;
 le module référentiel ;
 le module gestion des patients ;
 le module gestion des rendez-vous.
Après avoir défini le sujet, nous allons parler dans la suite de la méthode de développement
utilisée dans le cadre du projet.
24
I.3 Définition de la méthode de développement
Aujourd’hui, avec l’évolution du génie logiciel, la réalisation de projets informatiques
nécessite l’adoption d’une méthode de développement. Une méthode ou processus de
développement comprend principalement une démarche utilisée pour structurer et contrôler le
développement d’une application. Cette section permettra de définir la méthode de
développement qui a été utilisée en tenant compte des éléments qui font la spécificité du projet
que nous appelons dans la suite "l’environnement du projet".
Parmi les éléments de l’environnement du projet, nous pouvons citer les éléments ci-après.
 son type ou sa nature: il s’agit de mettre en place un système d’information composé de
plusieurs modules intégrés ;
 l’équipe de développement : l’équipe est composée d’une seule personne qui porte
différentes casquettes selon la phase de développement ;
 sa taille : ce projet est le regroupement de huit (8) modules allant de l’étude jusqu’à la
mise en place en passant par l’analyse, la conception, codage et test, déploiement de
chacun d’eux ;
 la disponibilité du client : chaque semaine, nous effectuions une présentation en
présence du client ou de son représentant. Celui-ci donnais son avis sur l’artefact
présenté et pouvais apporter des modifications dans les exigences fonctionnelles et non-
fonctionnelles. Ces nouvelles exigences seront automatiquement injectées dans les
tâches à faire ;
 l’organisation de l’entreprise : L’entreprise, dans son fonctionnement habituel, organise
des présentations hebdomadaires avec le responsable des projets durant lesquelles il
s’agit d’exposer l’état d’avancement de chaque travail, d’expliquer clairement les
obstacles rencontrer et de planifier ce qui est à faire d'ici la prochaine présentation en
tenant compte des potentielles modifications apportées à la suite de la présentation
courante. Sont aussi présents aux présentations, des ingénieurs de l’entreprise qui
apportent eux aussi leurs contributions surtout dans les premières phases. Toujours dans
son fonctionnement, l’entreprise préconise l’écriture des tests unitaires pour toute
fonctionnalité développée avant de passer à une autre.
En tenant compte de cet environnement du projet, nous avons utilisé une méthode mixte. Elle
est la réadaptation de la méthode d’agile Scrum dans le sens de la modification de la durée des
sprints ou itérations et aussi de la fréquence des mêlées et de bonnes pratiques issues de la
méthode d’agile XP (eXtreme Programming). Après avoir présenté brièvement l’approche
25
agile, les méthodes Scrum et XP seront présentées ainsi que leur utilisation dans le cadre du
projet.
I.3.1 L'approche agile
Il s’agit d’une approche itérative et incrémentale, qui est menée dans un esprit collaboratif avec
juste ce qu’il faut en terme de formalisme. Elle permet notamment d’impliquer l’ensemble des
collaborateurs ainsi que le client. De ce fait, elle permet de répondre aux attentes du client en
un temps limité. Toutes les méthodes agiles partagent les valeurs communes tirées de
(NEUMANN, 2016) que sont :
 L'équipe et la communication avant les outils et processus : dans la vision agile,

l'équipe est bien plus importante que les outils ou les procédures de fonctionnement. Il
est préférable d'avoir une équipe soudée et dont les membres communiquent entre eux,
composée de développeurs de niveaux différents, plutôt qu'une équipe composée
d'experts qui travaillent de manière isolée. La communication est donc une notion
fondamentale dans un contexte de développement agile.
 L'application avant la documentation : il est primordial que le projet fonctionne, c'est
la priorité avant toute chose. La documentation technique et les autres outils (de tests,
de reporting) constituent une aide précieuse, mais ne sont pas une fin en soi. Une
documentation précise est utile comme moyen de communication. Il est parfois
préférable de simplement commenter abondamment le code lui-même, et surtout de
transférer la totalité des compétences et connaissances du métier à l'ensemble des
collaborateurs de l'équipe.
 La collaboration avant la négociation : le client doit être impliqué dans le
développement. Le fournisseur ne doit pas se contenter de négocier un contrat au début
du projet, puis de refuser l'évolution des besoins du client. Le client doit collaborer avec
l'équipe et fournir des comptes rendus réguliers sur l'adaptation du logiciel à ses attentes.
 L'acceptation du changement et la flexibilité avant la planification : la planification
initiale et la structure du projet doivent être flexibles afin de permettre les évolutions
attendues par le client. En effet, les premières livraisons du projet donnent très souvent
suite à des demandes d'évolution.
L’agilité modifie donc la façon de concevoir des produits, et d’envisager un projet
informatique (notamment en termes d’estimation, de planification et de suivi).
26
I.3.2 La méthode Scrum
La méthode Scrum (figure 2) est une méthode agile, créée en 2002, dont le nom est un terme
emprunté au rugby qui signifie "la mêlée" (NEUMANN, 2016). Elle s'appuie sur le découpage
du projet en itérations encore nommées "sprints". Un sprint peut avoir une durée qui varie
généralement entre deux semaines et un mois. Avant chaque sprint, les tâches sont estimées en
temps et en complexité à l'aide de certaines pratiques comme le "planning poker", une manière
ludique de chiffrer la complexité des tâches ou évolutions à l'aide de cartes à l'instar du célèbre
jeu dont le nom est repris. Ces estimations permettent à la fois de planifier les livraisons, mais
aussi d'estimer le coût de ces tâches auprès du client. Les fonctionnalités (encore appelées "user
stories") qui font l'objet d'un sprint constituent le "sprint backlog" du produit éventuellement
livrable à la fin du sprint.
La méthode Scrum est aussi caractérisée par une "mêlée" quotidienne, encore appelée
"morning" ou "stand-up", dans laquelle les collaborateurs indiquent tour à tour les tâches qu'ils
ont effectuées la veille, les difficultés rencontrées et enfin ce sur quoi ils vont poursuivre leur
travail le jour suivant. Cela permet d'évaluer l'avancement du projet, de mobiliser des ressources
là où cela est le plus nécessaire, mais aussi de venir en aide aux collaborateurs rencontrant des
difficultés lorsque celles-ci ont déjà été rencontrées auparavant par d'autres membres de
l'équipe.
Figure 2 : Vue globale de la méthode Scrum (NEUMANN, 2016)
La méthode Scrum définit trois (3) rôles (Schwaber & Sutherland, 2013) pour un projet :
 Le product owner : il s'agit du représentant officiel du client au sein d'un projet Scrum.
Il est l'interlocuteur principal du Scrum Master et des membres de l'équipe. Il définit les
besoins du produit et rédige les spécifications. Il peut se faire aider de responsables
fonctionnels pour la rédaction des spécifications. Il est également chargé de définir et
prioriser les users stories pour chaque sprint ;
27
 Le scrum master : il s'agit d'une personne chargée de veiller à la mise en application
de la méthode et au respect de ses objectifs. Il ne s'agit pas d'un chef de projet, mais
d'une personne chargée de lever les obstacles éventuels qui empêcherait l'avancement
de l'équipe et du projet pendant les différents sprints ;
 L'équipe ("team members") : ce sont les personnes chargées de la réalisation du sprint
et d'un produit utilisable en fin de sprint. Il peut s'agir de développeurs, architectes,
personnes chargées de faire des tests fonctionnels, etc.
I.3.3 La méthode XP
XP (voir figure 3) est une méthode d’agile. Elle vise principalement la réduction des coûts de
changement. Elle met l’accent sur la revue de code, sur les tests, la conception continue, la
simplicité, la traduction des besoins en métaphores pour faciliter la communication. XP propose
un ensemble de pratiques organisées autour des principes tirés de (Tremblay, 2007) que sont :
 Le client (maîtrise d'ouvrage) pilote lui-même le projet, et ce de très près grâce à des
cycles itératifs extrêmement courts (1 ou 2 semaines) ;
 L'équipe livre très tôt dans le projet une première version du logiciel, et les livraisons
de nouvelles versions s'enchaînent ensuite à un rythme soutenu pour obtenir un feedback
maximal sur l'avancement des développements ;
 L'équipe s'organise elle-même pour atteindre ses objectifs, en favorisant une
collaboration maximale entre ses membres ;
 L'équipe met en place des tests automatiques pour toutes les fonctionnalités qu'elle
développe, ce qui garantit au produit un niveau de robustesse très élevé.
 L’équipe s’organise pour une amélioration continue de la qualité du code sans en
modifier le comportement (commentaire du code, respect des standards, etc.).
Figure 3 : Cycle de XP – Wikipédia

I.3.4 Définition de notre méthode de développement
Après avoir présenté les éléments de notre méthode mixte, nous détaillons dans cette section
leur utilisation effective. Le backlog de produit représente l’ensemble des modules du système
28
d’information à mettre en place. Pour nous, le backlog du sprint représente quant à lui
l’ensemble des tâches du module à réaliser dans le sprint. Les mêlées ou "STAND UP" quant à
elles, sont organisées deux fois chaque semaine comme cité dans l’environnement du projet et
la durée d’un sprint, en tenant compte de la taille d’un module et la taille de l’équipe, est passée
de maximum 4 semaines à maximum 6 semaines. En effet, chaque module traité durant un
sprint fera l’objet d’une analyse, d’une conception, d’une phase de codage alignée aux tests
unitaires de chaque fonctionnalité développée comme préconisé dans les bonnes pratiques
issues de la méthode XP et guidé par le fonctionnement de l’entreprise. En d’autres termes, il
s’agira d’utiliser Scrum pour principalement la gestion du projet et XP pour les activités de
développement. Durant le sprint 0, commun à tous les modules nous avons fait :
 une analyse et spécification des besoins non fonctionnels et fonctionnels ;
 une conception architecturale de tout le système ;
 une conception architecturale pour chaque module du système ;
 un choix des technologies à utiliser.
 une validation avec le client et avec le responsable des projets.
En termes de formalise, UML (Unified Modeling Language) du français langage de
modélisation unifié est utilisé dans le cadre de ce projet. UML se définit comme un langage de
modélisation graphique et textuel destiné à comprendre et décrire des besoins, spécifier et
documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et
communiquer des points de vue et non une méthode (Roques, 2006). UML est devenu une
norme OMG (Object Management Group) en fin 1997 (Gabay & Gabay, 2008).
Sa version 2.5 est composée de 14 diagrammes (cf. figure 4) classés en trois (3) grandes
catégories : les diagrammes structurels (diagramme de classes, diagramme d’objets, diagramme
de packages, diagramme de composants, diagramme de structure composite, diagramme de
déploiement et diagramme de profils), les diagrammes d’interaction (diagramme de séquence,
diagramme de collaboration, diagramme d’interaction et diagramme de temps) et les
diagrammes comportementaux (diagramme de cas d’utilisation, diagramme d’activités et
diagramme d’état-transition). Nous allons présenter les diagrammes utilisés dans le cadre du
projet.
29
Figure 4 : Les diagrammes d'UML
Les diagrammes d’UML utilisés dans le cadre de ce projet sont les suivants :
 Diagramme de cas d’utilisation
Les cas d’utilisation constituent un moyen de recueillir et de décrire les besoins des acteurs du
système. Ils peuvent être aussi utilisés ensuite comme moyen d’organisation du développement
du logiciel, notamment pour la structuration et le déroulement des tests du logiciel. Un
diagramme de cas d’utilisation permet d’avoir une représentation graphique des cas
d’utilisation.
 Diagramme de séquence
L’objectif du diagramme de séquence est de représenter les interactions entre objets en
indiquant la chronologie des échanges. Cette représentation peut se réaliser par cas d’utilisation
en considérant les différents scénarios associés.
 Diagramme de classe
Le diagramme de classes est considéré comme le plus important de la modélisation orientée
objet, il est le seul obligatoire lors d'une telle modélisation. Il permet de fournir une
représentation abstraite des objets du système qui vont interagir pour réaliser les cas
d'utilisation.
 Diagramme de paquetage
Un diagramme de paquetage est un diagramme de structure qui montre les paquetages et,
éventuellement, les relations entre eux.
30
 Diagramme de déploiement
Le diagramme de déploiement décrit la disposition physique des ressources matérielles qui
composent le système et montre la répartition des composants sur ces matériels.
 Diagramme d’activité
Le diagramme d’activité concerne le comportement interne des opérations ou des cas
d’utilisation. Cependant le comportement visé ici s’applique aux flots de contrôle et aux flots
de données propres à un ensemble d’activités et non plus relativement à une seule classe.
Conclusion du chapitre
Ce premier chapitre a présenté d’abord la structure d’accueil dans laquelle nous avons effectué
le stage de fin de formation en occurrence FINETCH. Ensuite, il a présenté le sujet de mémoire
qui porte sur la mise en place d’un service cloud fournissant un système d’information
hospitalier. Enfin, il a présenté la méthode de développement utilisée dans le cadre du projet.
Dans le chapitre suivant nous passons à l’analyse et spécifications des besoins identifiés du
projet.
31
Chapitres II : Analyse et spécification des besoins
L’analyse et la spécification des besoins sont des étapes primordiales de chaque

démarche de développement logiciel. Leur but est de veiller au développement adéquat du
système d’information en accord avec les demandes du client. Leur finalité est la description
générale des besoins fonctionnels et non fonctionnels liés au projet. Ce chapitre est décomposé
en deux sections dont la première fera une présentation de l'analyse des besoins non
fonctionnels et la deuxième l'analyse des besoins fonctionnels.
II.1 Analyse des besoins non fonctionnels

Les besoins non fonctionnels ou exigences techniques font partie des éléments de qualité d’un
produit. Ceux identifiés dans ce projet sont rangés dans des rubriques et présentés ci-après.
 Les performances :
o Montée en charge : le futur système devant être basé sur le cloud, y gérer la
montée en charge s’avère nécessaire. Il devrait pouvoir accepter un nombre
important de requêtes à un instant donné sans que cela n'affecte sa performance;
o Répartition de charges : il faudrait que le système soit en mesure de supporter
plusieurs instances du système d’information, il devra aussi être en mesure de
répartir les charges et ainsi permettre de toujours communiquer avec l’instance
la moins chargée;
o Haute disponibilité et tolérance aux pannes : le système devrait être disponible
même si on le pousse au-delà de ses performances habituelles c'est-à-dire qu'il
faudrait un accès quasi continu à ses fonctionnalités et données.
 La maintenance :
o La maintenance du système devrait se faire de façon facilitée.
 La sécurité :
o La disponibilité : Les services et les informations doivent être accessibles aux
personnes autorisées quand elles en ont besoin ;
o L'intégrité : les données doivent être celles que l'on attend, et ne doivent pas être
altérées de façon fortuite, illicite ou malveillante. En clair, les éléments
considérés doivent être exacts et complets ;
o La confidentialité : seules les personnes autorisées ont accès aux informations
qui leur sont destinées. Tout accès indésirable doit être empêché ;
32
o La traçabilité (ou "Preuve") : garantie que les accès et tentatives d'accès aux
éléments considérés sont tracés et que ces traces sont conservées et exploitables ;
o L'authentification : l'identification des utilisateurs est fondamentale pour gérer
les accès aux ressources du système et maintenir la confiance dans les relations
d'échange ;
o La non-répudiation et l'imputation : aucun utilisateur ne doit pouvoir contester
les opérations qu'il a réalisées dans le cadre de ses actions autorisées, et aucun
tiers ne doit pouvoir s'attribuer les actions d'un autre utilisateur.
 La portabilité : le fonctionnement du système ne devrait pas dépendre du système
d’exploitation dans lequel il tourne.
 L’interopérabilité : Le système devrait pouvoir communiquer et échanger avec
d’autres applications.
 L’accès via le cloud sous forme de service (SaaS) : le système sera entièrement basé sur
le cloud sous forme de SaaS
 Le respect de la législation sur les données personnelles (République du Sénégal, 2008).
II.2 Analyse des besoins fonctionnels

Une application est créée pour répondre, tout d’abord, aux besoins fonctionnels d'une
entreprise. Cette étape de notre processus de développement consiste à faire un repérage des
besoins fonctionnels en utilisant un formalisme (UML). Le but étant de montrer le
fonctionnement du système, de cadrer le périmètre du projet et d'identifier les entités métier du
système.
II.2.1 Analyse globale du SIH
Le diagramme de cas d’utilisation de la figure 5 montre les grandes fonctionnalités du système
sous la forme d'une boite noire. Chacune d’elles a fait l’objet d’une analyse détaillée spécifique.
33
Figure 5 : Fonctionnalités globale du système
La figure 6 permet de faire ressortir graphiquement le découpage du SIH en modules et les

relations entre eux en utilisant le diagramme de package d’UML.
Figure 6 : Découpage des modules du SIH en package et les relations entre eux
34
Deux modules supplémentaires, Commons shared services et Service sont ajoutés pour des
besoins métier.
II.2.3 Analyse fonctionnelle par module

Les différents packages présentés dans la figure 6 constituent le système globale. Ceux d’entre
eux qui ont été traités vont être l’objet d’une analyse détaillée en s’appuyant sur le modèle des
cas d’utilisation d’UML.
II.2.3.1 Analyse fonctionnelle du module "Référentiel"

Ayant un rôle central, le module "Référentiel" est l’ossature normative de tout le système.
L’ensemble de ses fonctionnalités est représenté dans la figure 7.
A. Descriptions des fonctionnalités du module "Référentiel"

Pour décrire les fonctionnalités du module, la documentation des cas d’utilisation est
indispensable, car elle seule permet de communiquer facilement avec les utilisateurs et de
s’entendre sur la terminologie métier employée. UML ne propose pas une présentation type de
cette description si elle est faite textuellement. Cependant nous prenons comme référence la
description textuelle proposée dans (Roques, 2006). Après chaque description textuelle, s’en
suivra une description graphique par le moyen d’un diagramme de séquence d’UML qui montre
les interactions entre l’acteur et le système et les actions que le système doit réaliser en vue de
produire les résultats attendus par l’acteur.
35
Figure 7: Les fonctionnalités du module "Référentiel"
36
i. Descriptions de la fonctionnalité "S’authentifier"
a. Description textuelle
La fonctionnalité "S’authentifier" apparait dans plusieurs interactions du système.
Sommaire d’identification :
Titre : "S’authentifier"
Résumé : Cette fonctionnalité permet à un utilisateur de s’authentifier auprès du système.
Acteur : Utilisateur (principal)
Responsable : Ngagne THIAM
Préconditions : aucune
Description des scénarios :
Scénario nominal : Ce scénario commence quand un utilisateur souhaite faire une opération
sans être authentifié par le système auparavant.
Utilisateur SIH
1. Demande l’accès à une fonctionnalité
2. Vérifie si l’utilisateur n’est pas déjà
authentifié et renvoie vers la page
d’authentification
3. Fournit les informations d’authentification
et valide
4. Vérifie les informations fournies et
renvoie vers la page demandée
Tableau 1 : Scénario nominal de la description textuelle de la fonctionnalité "S'authentifier"
Scénarios alternatifs :
Premier scénario alternatif : Il commence au point 2 du scénario nominal quand l’utilisateur
est déjà authentifié par le système.
Utilisateur SIH
2. Vérifie si l’utilisateur n’est pas
déjà authentifié et renvoie vers
la page qui offre la
fonctionnalité demandée
Tableau 2 : Premier scénario alternatif de la description textuelle de la fonctionnalité "S'authentifier"
Deuxième scénario alternatif : Il commence au point 4 du scénario nominal quand l’utilisateur

fournit de mauvaises informations d’authentification.
37
Utilisateur SIH
4. Vérifie des informations fournies et
redirige vers la page
d’authentification avec un message
d’erreur
5. Fournit les bonnes informations
d’authentification et valide
6. Vérifie les informations fournies et
renvoie vers la page demandée
Tableau 3 : Deuxième scénario alternatif de la description textuelle de la fonctionnalité "S'authentifier"
Scénario d’erreur : Ce scénario commence au point 4 du scénario nominal quand l’utilisateur

fournit de mauvaises informations d’authentification et que le nombre limite de tentative
d’authentification est atteint.
Utilisateur SIH
4. Vérification des informations fournies
et affiche un message d’erreur
Tableau 4 : Scénario d'erreur de la description textuelle de la fonctionnalité "S'authentifier"
Post condition : L’utilisateur est authentifié par le système.

b. Description graphique
La figure 8 fait une description graphique de la fonctionnalité "S’authentifier" en utilisant le
diagramme de séquence d’UML.
Figure 8 : Interactions entre un utilisateur et le SIH pour la réalisation de la fonctionnalité "S'authentifier"
38
ii. Cas d’utilisation "Gérer les structures"
La fonctionnalité "Gérer les structures" est générique. Elle regroupe un ensemble de
fonctionnalités en spécialisation : "Ajouter une structure", "Consulter/Supprimer une structure
", "Consulter/Modifier une structure" et "Consulter les structures". Ainsi, faire sa description
textuelle et sa description graphique revient à faire celles des fonctionnalités en spécialisation.
a. Description textuelle de la fonctionnalité "Ajouter une structure "

Titre : "Ajouter une structure"
Résumé : Cette fonctionnalité permet au super administrateur d’ajouter une structure sanitaire
comme abonnée aux services.
Acteur : Super Administrateur (principal)
Précondition : L’acteur Super Administrateur s’est authentifié.
Scénario nominal : Ce scénario commence lorsque l’acteur Super Administrateur souhaite
ajouter une structure.
Super Administrateur SIH
1. Demande la page d’ajout de structure
2. Retourne le formulaire d’ajout de structure
3. Fournit les informations sur la
structure à ajouter et valide
4. Effectue un traitement et affiche une
notification d’ajout réussie
Tableau 5 : Scénario nominal de la description textuelle de la fonctionnalité "Ajouter une structure"
Scénario alternatif : Ce scénario commence au point 4 du scénario nominal quand une erreur
est détectée dans les informations fournies au système.
4. Effectue un traitement et affiche un
message d’erreur
5. Fournit les bonnes informations et
valide
notification d’ajout réussie
Tableau 6 : Scénario alternatif de la description textuelle de la fonctionnalité " Ajouter une structure"
39
Post condition : Une nouvelle structure est ajoutée comme abonnée aux services.
b. Description graphique de la fonctionnalité "Ajouter une structure"
La figure 9 montre les interactions entre l’acteur Super Administrateur et le système pour la
réalisation de la fonctionnalité en spécialisation "Ajouter une structure" de la fonctionnalité
générique "Gérer les structures" par le biais d’un diagramme de séquence d’UML.
Figure 9 : Interactions entre le super administrateur et le SIH pour la réalisation de la fonctionnalité "Ajouter une structure"
c. Description textuelle de la fonctionnalité "Consulter/Supprimer une structure"

Titre : "Consulter/Supprimer une structure"
Résumé : Cette fonctionnalité permet au super administrateur de consulter les structures
sanitaires abonnées et d'en supprimer une.
Scénario nominal : Ce scénario commence lorsque le super administrateur souhaite supprimer
une structure.
40
1. Demande la liste des structures
abonnées
2. Effectue un traitement et retourne la
liste des structures abonnées
3. Fournit des informations sur la
structure à supprimer puis valide
notification de suppression réussie
Tableau 7 : Scénario nominal de la description textuelle de la fonctionnalité "Consulter/Supprimer une structure"
Scénario alternatif : Ce scénario commence au point 4 quand il y a une erreur sur les
informations fournies au système.
4. Effectue un traitement et détecte une
erreur et affiche un message d’erreur
5. Fournit de bonnes informations sur la
structure à supprimer et valide
notification de suppression réussie
Tableau 8 : Scénario alternatif de la description textuelle de la fonctionnalité "Consulter/Supprimer une structure"
Post condition : Une structure sanitaire est retirée parmi celles abonnées aux services.
d. Description graphique du cas d’utilisation "Consulter/Supprimer une structure"
La figure 10 montre, par le biais d’un diagramme de séquence d’UML, les différentes
interactions entre l’acteur principal Super Administrateur et le système pour la suppression
d’une structure.
41
"consulter/supprimer une structure"
e. Description textuelle de la fonctionnalité "Consulter/Modifier une structure "

Titre : "Consulter/Modifier une structure"
sanitaires abonnées et d'en modifier une.
Scénario nominal : Ce scénario commence quand l’acteur Super Administrateur souhaite
modifier une structure sanitaire abonnée aux services.
42
1. Demande la liste des structures
abonnées
2. Effectue un traitement retourne la
liste des structures abonnées
3. Fournit les informations sur la
structure à modifier et valide
4. Effectue un traitement puis retourne
la structure à modifier
5. Met à jour des informations de la
structure puis valide
6. Effectue un traitement puis affiche
une notification de mise à jour réussie
Tableau 9 : Scénario nominal de la description textuelle de la fonctionnalité "Consulter/Modifier une structure"
Scénario alternatif : Ce scénario commence au point 6 du scénario nominal quand une erreur
est détectée dans les informations fournies au système.
6. Effectue un traitement et détecte une
erreur puis affiche un message
d’erreur
7. Met à jour de bonnes informations de
la structure puis valide
notification mise à jour réussie
Tableau 10 : Scénario alternatif de la description textuelle de la fonctionnalité "Consulter/Modifier une structure"
Post condition : Une structure est mise à jour.

f. Description graphique du cas d’utilisation "Consulter/Modifier une structure"
La figure 11, qui est un diagramme de séquence d’UML, est la description graphique de la
fonctionnalité "Consulter/Modifier une structure ".
43
"Consulter/Modifier une structure"
g. Description textuelle de la fonctionnalité "Consulter les structures"

Titre : "Consulter les structures"

sanitaires abonnées.
Scénario nominal : Ce scénario est le seul, il commence quand l’acteur Super Administrateur
souhaite consulter les structures sanitaires abonnées aux services.
44
1. Demande la page consulter la liste
des structures abonnées
2. Effectue un traitement et retourne la
page contenant les structures
abonnées
Tableau 11 : Scénario nominal de la description textuelle de la fonctionnalité "Consulter les structures"
h. Description graphique de la fonctionnalité "Consulter les structures"

En utilisant un diagramme de séquence d’UML, la figure 12 montre les différentes interactions
entre l’acteur Super Administrateur et le système pour la consultation de la liste des structures
abonnées aux services.
Figure 12 : Interactions entre le super administrateur et SIH pour consulter la liste des structures
B. Analyse des entités métiers du module "Référentiel" et les relations entre elles
Après avoir fait l’analyse des différentes fonctionnalités du module "Référentiel", nous
procédons à l'analyse des entités métier. Cette activité a permis d'obtenir la figure 13 qui
représente ces entités métiers ainsi que les relations entre elles. Nous procédons à une
description de quelques-unes d’entre elles.
Nom de l’entité : Structure

Résumé : cette entité représente la structure sanitaire abonnée aux services.
Attribut Description
libelle Nom de la structure qui sera affiché dans sa vue
codeSaas Le code fourni par l’entreprise à la structure abonnée.
localisationGeo La localisation géographique de la structure.
description Une courte description des activités de la structure
brevePresentation Une brève présentation de la structure
dateCreation Date de création de la structure
45
Figure 13 : Liste des entités métiers du module "Référentiel"
46
Nom de l’entité : Agent
Résumé : cette entité permet de représenter l’ensemble d’un personnel quelconque dans la
structure.
dateEmploie La date à laquelle l’agent est employé dans la structure
Nom de l’entité : Role

Résumé : cette entité représente le rôle de l’utilisateur. Ce rôle lui permet d’avoir un accès à
certaines ressources du système.
nom Le nom du rôle
Nom de l’entité : Utilisateur

Résumé : cette entité représente tout utilisateur du SI.
username Le nom utilisé par l’utilisateur qui sera affiché dans sa page et
visible d’externe
password Le mot de passe utilisé par l’utilisateur
activated Permet de savoir si le compte de l'utilisateur est actif ou pas
enable Permet de savoir si le compte est bloqué
tokenExpired Permet de savoir l’état du token d’authentification de l’utilisateur
Nom de l’entité : Fonctionnalite

Résumé : cette entité représente une fonctionnalité d’un module du système.
libelle Le nom de la fonctionnalité qui sera affiché au niveau de l'interface
utilisateur
Nom de l’entité : Privilege

Résumé : cette entité représente la permission de l’utilisateur sur une fonctionnalité d’un
module du système.
nom Le nom de la permission
libelle Le texte qui sera affiché au niveau de l'interface
utilisateur
url L’adresse d’accès à l’opération (sous la forme d'un lien
par exemple)
47
Nom de l’entité : Module
Résumé : cette entité représente un module du système.
libelle Le nom du module qui sera affiché au niveau de l'interface
utilisateur
priority La priorité du module.
Nom de l’entité : BackupPassword

Résumé : l’entité BackupPassword permet d’historier les mots de passe d’un utilisateur et aussi
d’éviter la réutilisabilité d’un mot passe.
content Ensemble des mots de passes déjà utilisés par un utilisateur
II.2.3.2 Analyse fonctionnelle du module "Gestion des patients"

Le diagramme d’activité de la figure 14 décrit les activités dans le module "Gestion des
patients". Elles sont les premières du processus thérapeutique en allant de la venue du patient
jusqu’à ce qu’il soit orienté dans un service de la structure.
48
Figure 14 : Les activités dans le module "Gestion des patients"
49
L’ensemble des fonctionnalités du module est représenté dans la figure 15 sous la forme d'un
diagramme de cas d’utilisation d’UML.
Figure 15 : Les fonctionnalités du module "Gestion des patients"
50
A. Descriptions des fonctionnalités du module "Gestion des patients"
Pour faire la documentation des cas d’utilisations du module "Gestion des patients", la même
approche que celle avec le module "Référentiel" sera suivie ici.
i. Description de la fonctionnalité "Faire une prestation"

En guise d’exemple, la fonctionnalité "Faire une Prestation" est choisie pour présenter une
partie de l’analyse et de la spécification des besoins qui ont été faites dans ce module. Après
une prestation, plusieurs choix sont possibles suivant son type mais aussi suivant les résultats
qui en découlent. Le personnel de soin peut effectuer une demande ou produire un document.
Un document représente un papier qui peut être produit après une consultation : ordonnance,
certificat, bulletin de résultat, prescription, etc. Tandis qu’une demande peut être de plusieurs
natures : Demande d’analyse, demande d’examen, demande d’un rendez-vous et demande
d’hospitalisation. L'enchaînement d'actions qui précède est représenté dans le diagramme
d'activités de la figure 14.
Comme pour le cas d’utilisation "Gérer les structures" du module référentiel, il s’agira de faire
une description textuelle suivie d’une description graphique des cas d’utilisation en
spécialisation.
a. Description textuelle de la fonctionnalité "Effectuer une demande"

Titre : "Effectuer une demande"
Résumé : Un patient non encore hospitalisé se présente à la structure sanitaire pour solliciter
un service fourni par ladite structure. Il est pris en charge par un personnel de soin de la structure
qui fournira le service attendu sous forme de prestation.
Acteur : Personnel de soin (principal);
Précondition : le patient a déjà un dossier médico-administratif et a aussi un dossier médical.
Une prestation est programmée pour lui avec un personnel de soin de la structure et ce dernier
a reçu toutes les informations nécessaires pour prendre la décision d’effectuer la demande
correspondante.
51
Scénario normal :
Personnel de Soin SIH
1. Demande la page pour effectuer une
demande
2. Affiche la page pour effectuer une
demande
3. Choisit le type de demande à
effectuer
4. Affiche la vue correspondante à la
saisie du type de demande
sélectionné
5. Fournit les informations nécessaires
et soumet sa demande
6. Traite la demande et affiche une
notification
Tableau 12 : Scénario nominal de la description textuelle de la fonctionnalité "Effectuer une demander"
Scénario alternatif : Ce scénario commence au point 6 quand une ou plusieurs informations

saisies ne sont pas correctes.
Personnel de Soin SIH
6. Affiche la page d'origine avec un
message d'erreur
soumet à nouveau sa demande.
8. Traite la demande et affiche une
notification
Tableau 13 : Scénario alternatif de la description textuelle de la fonctionnalité "Effectuer une demander"
Post-conditions : Une prestation est ajoutée et une demande envoyée vers le service
destinataire.
b. Description graphique de la fonctionnalité "Effectuer une demande"
La figure 16 est le diagramme de séquence d’UML correspondant à la description graphique du
cas d’utilisation en spécialisation "Effectuer une demande".
52
Figure 16 : Interactions entre un personnel de soin et le SIH pour "Effectuer une demande"
c. Description textuelle de la fonctionnalité "Produire un document"

Titre : "Produire un document"
Résumé : Un patient non encore hospitalisé se présente à la structure sanitaire pour solliciter
un service fourni par ladite structure. Il est pris en charge par un personnel de soin de la structure
qui fournira le service attendu sous la forme d'une prestation.
Acteur : Personnel de soin (principal);
Préconditions : Le patient a déjà un dossier médico-administratif et a aussi un document
médical. Une prestation est programmée pour lui avec un personnel soignant de la structure et
ce dernier a reçu toutes les informations nécessaires pour prendre la décision de produire un
document.
53
Scénario nominal :
Personnel de soin SIH
1. Demande la page pour produire un
document
2. Affiche la page pour saisir un
document
3. Choisit le type de document à
produire
4. Affiche la vue pour la saisie des
informations qui seront mises dans le
document à produire
5. Fournit les informations nécessaires
et soumet sa demande.
6. Effectue un traitement et présente le
document pour une impression
7. Imprime le document
Tableau 14 : Scénario nominal de la description textuelle de la fonctionnalité "Produire un document"
Scénario alternatif : Ce scénario commence au point 6 du scénario normal quand l’acteur

principal fait une erreur dans les informations saisies.
Personnel de soin SIH
6. Traitement et retourne une
notification d’erreur
soumet sa demande
8. Effectue le traitement et présente le
document pour une impression
9. Imprime le document
Tableau 15 : Scénario alternatif de la description textuelle de la fonctionnalité "Produire un document"
Post-conditions : Une nouvelle prestation est enregistrée et le document produit est remis au
patient.
d. Description graphique du cas d’utilisation "Produire un document"
La figure 17 représente le diagramme de séquence pour le cas d’utilisation spéciale "Produire
un document".
54
Figure 17 : Interactions entre personnel de soin et SIH pour "Produire un document"
B. Analyse des entités métier du module "Gestion des patients" et les relations entre elles.
L’analyse fonctionnelle du module a permis d’avoir les différentes fonctionnalités. Pour les
réaliser, il est nécessaire d’avoir des entités métier qui interagissent entre elles pour rendre le
service attendu par un acteur du système. Cette sous-section permet d’analyser ces entités
métier par le biais du diagramme de classe d’UML de la figure 18. Nous procédons à la
description de quelques entités propres au module. Celles en vert appartiennent au module
"Référentiel", elles ne seront donc pas décrites ici à nouveau.
Nom de l’entité : Prestation

Résumé : Cette entité représente tout service qui peut être rendu à un patient par un personnel
de soin.
datePrestation La date à laquelle la prestation a eu lieu
motif Le but visé par la prestation.
observations Les constats faites sur le patient
resultats Ce qui résulte de la prestation
etat Indicateur sur l’état de la prestation :
Effectuer, Attente.
55
Figure 18 : Liste des entités du module "Gestion des patients"
56
Nom de l’entité : Dossier
Résumé : Cette entité représente soit un dossier médical soit un dossier médico-administratif.
Le premier contient toutes les informations médicales du patient : prestations, résultats, sorties,
etc. et le second les informations administratives du patient.
dateCreation La date de création du dossier
Nom de l’entité : Patient

Résumé : Cette entité représente le patient qui sollicite un service fourni par la structure
sanitaire. C’est l’élément central du système.
index Identifiant unique du patient créé à partir de
son nom, de son prénom, du prénom de son
père, etc.
Nom de l’entité : PersonnelSoin

Résumé : Cette entité représente un personnel de soin de la structure qui effectue une prestation
à un patient. Elle hérite une partie de ses informations de l’entité User du module "Référentiel".
specialite La spécialité du personnel de soin
Nom de l’entité : TypePrestation

Résumé : Cette entité représente les différents types de prestations que peuvent être une
prestation.
libelle Le nom du type de prestation affiché
Ce chapitre a permis de faire l’analyse et la spécification des besoins fonctionnels et non
fonctionnels indiqués par le client à travers un cahier de charges. Cette phase est importante car
la plupart des causes d’échecs d’un projet sont liés à sa mauvaise prise en charge. Toutes les
spécifications qui en résultent ont été validées avec le client. L’analyse permet de répondre à la
question du "quoi ?"; quant à la conception, elle permet de répondre à la question du
"comment ?". La première étant traitée, nous passons à la deuxième dans le chapitre qui suit.
57
Chapitre III : Conception
La conception est une phase importante dans le cycle de développement d’un projet.
Elle se concentre sur le "comment faire". Elle a pour but de définir et de mettre en place les
choix d’architecture et de technologies et de compléter la description du système sous l’angle
technique pour répondre aux exigences techniques et fonctionnelles. Ce chapitre présente
respectivement des définitions jugées utiles à la compréhension des termes utilisés et une
analyse des différentes architectures du système, les outils et technologies utilisés, les
implémentations des architectures et la conception d'un cas d'utilisation en guise d'illustration.
III.1 Définition et analyse d'une architecture du système d'information

III.1.1 Définition d’une architecture du système d’information
Une architecture d’un système dans le sens littéraire peut être définie comme la structuration
d'un système en termes de composants et d'organisation de ses fonctions (Trudel, 2009). Il s’agit
donc du découpage d’un système en des composants et les relations eux.
III.1.2 L’utilité d’une architecture structurée et planifiée

La stratégie des structures sanitaires actuelles est de plus en plus complexe et est sujette à des
modifications. Ces modifications sont souvent dues à des besoins d’optimisation face aux
nombreuses informations échangées entre les nombreux services hospitaliers et à l’éclosion des
spécialités médicales dans le domaine sanitaire.
Une architecture structurée et planifiée permettra :
 d’avoir un système flexible s’adaptant à l’environnement métier d’un service donné ;

 de faciliter la compréhension en donnant une vue de haut-niveau de leur structure et de
leurs exigences. Les motivations de choix de conception sont ainsi mises en évidence ;
 la réutilisation qui favorise l’identification des éléments réutilisables, parties de
conception, composants, caractéristiques, des fonctions ou données communes ;
 la construction qui fournit un plan de haut-niveau du développement et de l’intégration
des modules en mettant en évidence les composants, les interactions et les
dépendances ;
 l’évolution qui met en évidence les points où un système peut être modifié et étendu.
La séparation composant/connecteur facilite une implémentation du type « plug-and-
play» ;
58
 etc.
Pour avoir tous ces avantages, il y a plusieurs styles architecturaux candidats. Parmi eux le style
architectural orienté services plus connu sous le nom de Service Oriented Architecture (SOA).
En effet les temps de réponse sont meilleurs du fait de l’abstraction introduite par la couche
service. Le coût des appels aux objets métiers à partir de la couche service est très faible.
III.1.3 L’apport d’une architecture orientée service
Plusieurs définitions sont données au terme SOA, parmi elles celle donnée dans (Marks, Eric,
Bell, & Michael, 2006) qui définit une architecture SOA comme "étant une architecture métier
conceptuel où les fonctionnalités métier (ou la logique de l’application) est mise à disposition
pour les pour les utilisateurs, en tant que services réutilisables et partagés dans un
environnement informatique". Les services dans une SOA sont les modules d’une
fonctionnalité de l’application avec des interfaces exposées et qui sont invoquées par
messages. Une architecture orientée services est une architecture logicielle s'appuyant sur un
ensemble de services simples. L'objectif d'une architecture orientée services est donc de
décomposer une fonctionnalité en un ensemble de fonctions basiques, appelées services,
fournies par des composants, et de décrire finement le schéma d'interaction entre ces services.
Ce type d’architecture suit des principes de modélisation modernes. Quelques uns de ces
principes sont les suivants :
 L’architecture doit reposer sur le concept d’offre et de demande de services.
 Les composants doivent pouvoir communiquer entre eux de manière asynchrone et
doivent être couplés faiblement.
 L’architecture doit être découpée en plusieurs couches
o L’architecture n-couches la plus connue est probablement la modèle-vue-
contrôleur (cf. figure 21) où l’on trouve les couches présentation, métier, et
données.
Ces principes doivent permettre la flexibilité du système pour s’adapter à la stratégie des
structures. Cette flexibilité découle du fait que les services sont réutilisables grâce à une
interface standardisée, une facilité d’intégration accrue pour une complexité plus faible. En plus
de la flexibilité, le style architectural SOA offre d’autres avantages qui sont présentés à la figure
59
19. Quant à la figure 20, elle montre un exemple d’une architecture d’un système d’information
en SOA où le ESB joue le rôle de chef d'orchestre.
Agilité
Réduction des Interopérabilité

coûts
Extensibilité
Réutilisation
de service
Réduction des
Maintenabilité couts
Figure 19 : Autres avantages d'une architecture en SOA
Figure 20 : Exemple d'architecture en SOA d’un SIH
III.1.4 Architecture Modèle-Vue-Contrôleur (MVC)

Ce patron d’architecture a pour but de séparer la couche interface utilisateur des autres parties
du système (car les interfaces utilisateurs sont beaucoup plus susceptibles de changer que la
base de connaissances du système).
Il admet trois types de composantes ou couches
 Modèle : rassemble des données du domaine, des connaissances du système. Contient

les classes dont les instances doivent être vues et manipulées ;
 Vue : utilisé pour présenter/afficher les données du modèle dans l’interface utilisateur ;
60
 Contrôleur : contient les fonctionnalités nécessaires pour gérer et contrôler les
interactions de l’utilisateur avec la vue et le modèle.
Figure 21 : Les différentes composantes de l'architecture du modèle-vue-contrôleur
III.1.5 Style architectural REST

REST (REpresentational State Transfer) est un style d'architecture pour les systèmes
hypermédia distribués, créé par Roy Fielding en 2000 dans le chapitre 5 de sa thèse de doctorat.
Il utilise le protocole HTTP comme un moyen applicatif. Une architecture REST doit respecter
certaines contraintes (Fielding, 2016) :
 Client-serveur : basé sur offre et demande ;

 Sant-état : chaque requête d'un client vers un serveur doit contenir toute l'information
nécessaire pour permettre au serveur de comprendre la requête, sans avoir à dépendre
d'un contexte conservé sur le serveur ;
 Mise en cache : le serveur envoie une réponse qui donne l'information sur la propension
de cette réponse à être mise en cache, comme la fraîcheur, sa date de création, si elle
doit être conservée dans le futur ;
 Un système hiérarchisé en couche ;
 Une interface uniforme : cette contrainte agit selon quatre règles essentielles :
o l'identification des ressources : chaque ressource est identifiée unitairement ;
o la manipulation des ressources à travers des représentations : les ressources
ont des représentations définies ;
61
o un message auto-descriptif : les messages expliquent leur nature. Par exemple,
si une représentation en HTML est codée en UTF-8, le message contient
l'information nécessaire pour dire que c'est le cas ;
o hypermédia comme moteur d'état de l'application : chaque accès aux états
suivants de l'application est décrit dans le message courant.
III.1.6 Architecture Logicielle Distribuée basée sur les Micro services (ALDM)
Les micro services sont une approche d’architecture et de développement d’une application
composée de petits services (Youssfi, 2015). L’idée étant de découper un grand problème en de
plus petits :
 unités implémentée sous forme de micro services ;
 chaque service est responsable d’une fonctionnalité ;
 chaque micro service est développé, testé et déployé séparément des autres ;
 chaque service tourne dans un processus séparé ;
 la seule relation entre les différents micro services est l’échange de données effectué à
travers les différentes APIs qu’ils exposent. (SOAP, REST, RMI, CORBA, JMS, etc.) ;
 lorsqu’on les combine, ces micro services peuvent réaliser des opérations très
complexes ;
 indépendance relative entre les différentes équipes qui développement les différents
micro services (en partant du principe que les APIs qu’ils exposent sont définis à
l’avance) ;
 facilité des tests et du déploiement ou de la livraison continue ;
 un micro service combine les trois couches "métier, technique, et données".
Ce style architectural apporte de nombreux avantages dont :
 Chaque micro service peut être conçu à l’aide de n’importe quel outil et développé avec
n’importe quel langage et technologie ;
 Ils sont faiblement couplés puisque chaque micro service est physiquement séparé des
autres ;
 Indépendance relative entre les différentes équipes qui développement les différents
micro services (en partant du principe que les APIs qu’ils exposent sont définis à
l’avance).
Une architecture basée sur les micro services est une implémentation du type architecturale
SOA. Le style d’architecture REST est utilisé dans le cadre de ce projet pour l’échange de
données entre les différents micro services et entre le micro service frontal (Entreprise Service
62
Bus) qui est la porte d’entrée au métier du système et la vue. La figure 22 est une représentation
d’un micro service. Il est possible de décomposer un micro service en d’autres micro services.
Figure 22 : L’architecture d’un micro service (Youssfi, 2015)
III.1.6 Architecture du SIH

Après une série de définitions de termes liées aux différentes architectures de la solution, nous
nous attelons à la définition de l'architecture du SIH. La figure 23 permet d’illustrer les
différentes composantes de l’architecture du système d’information.
Figure 23 : Architecture du SIH

Cette architecture est découpée en trois niveaux :
Niveau présentation : Ce niveau représente la partie qui sert de présentation au SIH. Il
regroupe le UX (User eXperience) composé des navigateurs et les clients mobiles et Repository
qui est l’espace de stockage des fichiers de journalisation, d’archivage des traces, etc.
Niveau logique applicative : Ce niveau implémente la logique applicative du SI. Il est
principalement composé de :
 un ensemble d’applications métiers qui sont les modules du SI : Gestion des patients
(GestPatient), des hospitalisations (GestHosp), etc. Chaque module implémente un
métier spécifique à lui et non répétitif sous la forme d’un service ;
63
 services représente la couche d’intégration des autres modules dans le SIH. Il représente
le ESB qui sert de bus de communication des autres modules ;
 les APIs sur les modules représentent le package du module qui implémente
l’interconnexion entre le module et des applications externes au SI donnant ainsi un
caractère interopérable à notre application ;
 AuthN-AuthZ représente la couche qui gère l’authentification (AuthN) et
l’autorisation (AuthZ);
 il est nécessaire de pouvoir tout le temps savoir qui a fait telle action, c’est l’objectif de
la couche Audit de l’architecture.
Niveau persistance : Ce niveau représente la couche de stockage des données manipulées par
le SI.
En plus de ce regroupement par niveau, nous avons les composantes suivantes :
Plateau technique : Certaines structures sanitaires peuvent disposer d’un plateau technique
muni d’automates capables de communiquer directement avec le système à travers le module
"Gestion du plateau technique".
Autres organismes : Dans certains cas, un module peut être interfacé avec des organismes
sociaux qui fournissent des informations supplémentaires et parfois nécessaires pour traiter un
patient.
Cette architecture est entièrement basée sur le style architectural orienté service. Les différents
modules communiquent à travers la couche services. Chaque module est le regroupement d’un
ensemble de micro services. Le module en tant que tel est donc un micro service et respecte le
patron d’architecture MVC présenté à la figure 21.
Il est nécessaire d'avoir des outils et technologies pour implémenter l’architecture de la figure
23. La section qui suit présente les outils et technologies utilisés.
III.2 Présentation des outils et technologies utilisés
Un ensemble d’outils sont utilisés pour mettre en place la solution architecturale proposée.
L’objectif de cette section est de faire une présentation de certains d’entre eux.
III.2.1 La plate-forme de développement d’application web Java EE

Java EE est une plate-forme fortement orientée serveur pour le développement et l'exécution
d'applications distribuées (Doudoux, 2013). Elle est composée de deux parties essentielles :
 un ensemble de spécifications pour une infrastructure dans laquelle s'exécutent les

composants écrits en Java : un tel environnement se nomme serveur d'applications.
64
 un ensemble d'API qui peut être obtenues et utilisées séparément. Pour être utilisées,
certaines nécessitent une implémentation de la part d'un fournisseur tiers.
Sun propose une implémentation minimale des spécifications de Java EE : le Java EE SDK.
Cette implémentation permet de développer des applications respectant les spécifications mais
n'est pas prévue pour être utilisée dans un environnement de production. Ces spécifications
doivent être respectées par les outils développés par des éditeurs tiers.
L'utilisation de Java EE pour développer et exécuter une application offre plusieurs avantages:
 une architecture d'applications basée sur les composants qui permet un découpage de
l'application et donc une séparation des rôles lors du développement
 la possibilité de s'interfacer avec le système d'information existant grâce à de
nombreuses API : JDBC, JNDI, JMS, JCA, etc.
 la possibilité de choisir les outils de développement et le ou les serveurs d'applications
utilisés qu'ils soient commerciaux ou libres
Java EE permet une grande flexibilité dans le choix de l'architecture de l'application en

combinant les différents composants. Ce choix dépend des besoins auxquels doit répondre
l'application mais aussi des compétences dans les différentes API de Java EE. L'architecture
d'une application se découpe idéalement en au moins trois tiers :
 la partie cliente : c'est la partie qui permet le dialogue avec l'utilisateur. Elle peut être
composée d'une application standalone, d'une application web ou d'applets
 la partie métier : c'est la partie qui encapsule les traitements (dans des EJB ou des
JavaBeans)
 la partie des données : c'est la partie qui stocke les données.
III.2.2 Le Framework Spring
Spring est un Framework, un ensemble de bibliothèques et de conventions permettant le
développement rapide d'applications. C’est un socle pour le développement d'applications,
principalement d'entreprises mais pas obligatoirement. Il fournit de nombreuses fonctionnalités
parfois redondantes ou qui peuvent être configurées ou utilisées de plusieurs manières : ceci
laisse le choix au développeur d'utiliser la solution qui lui convient le mieux et/ou qui répond
aux besoins. Spring est ainsi un des Framework les plus répandus dans le monde Java : sa
65
popularité a grandi grâce à la richesse des services qu'il propose ( Dubois, Retaillé, & Templier,
2007) :
 Découplage des composants. Moins d’interdépendances entre les différents modules ;

 Rendre plus aisés les tests des applications complexes c’est-à-dire des applications
multicouches ;
 Un système de transactions au niveau métier qui permet par exemple de faire du "two-
phases-commit" ;
 Un mécanisme de sécurité ;
 Pas de dépendances dans le code à l’API Spring lors l’utilisation de l’injection. Ce qui
permet de remplacer une couche sans impacter les autres ;
 Une implémentation du patron d’architecture MVC ;
 Déployer et consommer des web-services très facilement ;
 Echanger des objets par le protocole HTTP;
 son cœur reposant sur un conteneur de type IoC (Injection of Control) assure la gestion
du cycle de vie des beans et l'injection des dépendances
 l'utilisation de l'AOP
 des projets pour faciliter l'intégration avec de nombreux projets open source ou API de
Java EE. La figure 24 présente l’architecture du framework.
Figure 24 : L'architecture globale de spring Framework (Pivotal Software, 2016)
66
Spring était un framework applicatif à ses débuts mais maintenant c'est une véritable plate-
forme composée du framework Spring, de projets qui couvrent de nombreux besoins et de
middlewares. Spring permet une grande flexibilité dans les fonctionnalités et les projets utilisés
dans une application. Il est par exemple possible d'utiliser le conteneur Spring pour gérer de
façon basique les beans sans utiliser l'AOP. Par contre, certains projets et certaines
fonctionnalités ont des dépendances avec d'autres projets. Spring est associé à la notion de
conteneur léger par opposition aux conteneurs lourds que sont les serveurs d'applications Java
EE. Spring implémente l’architecture MVC présentée dans la figure 21. La figure 25 illustre le
fonctionnement du Framework en montrant comment elle gère une requête cliente.
Figure 25 : Fonctionnement de Spring
Le Framework Spring admet plusieurs composants (Pivotal Software, 2016) dont ceux qui
suivent:
 Spring Boot :
Spring Boot permet entre autres de :
o créer des applications Spring autonomes ;
o intégrer Tomcat, Jetty ou Undertow directement ;
o fournir automatiquement un POM de départ pour simplifier la configuration de
Maven ;
o absolument aucune génération de code et aucune exigence de configuration
XML.
67
Spring boot est utilisé dans le cadre de ce projet pour développer des micro services représentant
un module du SI. Chaque composante Spring Boot utilisé implémente le patron d’architecture
MVC et sa couche est un contrôleur de type REST et produit des données de type JSON.
 Spring Data JPA :
Spring Data JPA vise à améliorer de manière significative la mise en œuvre de couches d'accès
aux données en réduisant l'effort à la quantité qui est réellement nécessaire. En tant que
développeur, on écrit nos interfaces référentielles, y compris les méthodes de recherche
personnalisée et il fournira la mise en œuvre automatiquement. Pour faire le mapping objet
relationnel, l’implémentation de JPA Hibernate est utilisée.
 Spring Security :
Spring Security est un cadre qui se concentre sur la fourniture de l'authentification et
l’autorisation d’applications Java. Comme tous les projets de Spring, la puissance réelle de
Spring Security se trouve dans la façon dont facilement il peut être étendu pour répondre aux
besoins personnalisés. Il a quelques caractéristiques parmi lesquelles :
o la prise en charge complète et extensible pour l'authentification et l'autorisation
o la prise en charge de plusieurs types d’authentifications : LDAP, JDBC, etc.
o la protection contre les attaques telles que la fixation de session, clickjacking, etc.
o la protection contre des attaques de type CSRF, XSS ;
o le mécanisme Single Sign-On ;
o une authentification basée sur les tokens ;
o etc.
 Spring Session :
Spring Session est principalement caractérisé par les fonctionnalités qu’il offre :
o une API pour la mise en œuvre et la gestion des sessions des utilisateurs ;
o la prise en charge les sessions de gestion de plusieurs utilisateurs dans une instance
de navigateur unique (à savoir multiples comptes authentifiés similaires à Google).
o les identifiants de session des en-têtes pour travailler avec les API RESTful ;
 Spring Hateoas :
Spring HATEOAS fournit des API pour faciliter la création de représentations REST qui
suivent le principe HATEOAS. Le cœur du problème auquel il tente de répondre est la création
de liens et l'ensemble de la représentation. Il permet d’avoir un moteur d’état pour une
application basée sur le web service de type REST avec Spring. Spring Hateoas supporte des
hypermédias de formats comme HAL (Hypertext Application Language).
68
 Spring Cloud :
Spring Cloud construit sur Spring Boot en fournissant plusieurs de bibliothèques qui améliorent
le comportement d'une application lorsqu'elle est ajoutée dans un projet. Il est possible de
profiter du comportement de base par défaut pour démarrer très rapidement, et puis au besoin,
il est possible de le configurer ou de l’étendre pour créer une solution personnalisée. Parmi les
composantes de Spring Cloud, il est utilisé Spring Cloud Netflix en utilisant ses composantes
de route et de filtre avec Zuul Proxy Server et Client, un service de découvert avec Eureka
Server et Client, un service de disjoncteur ou Circuit Breaker qui est appelé en cas de problème
de jonction d’un micro service client.
III.2.3 Le Framework AngularJS
AngularJS est un Framework JavaScript développé par Google. Sa particularité vient du fait
qu’il utilisé MVC mais côté client et utilise aussi le Data Binding et le MVVM (Model View
ViewModel). L’architecture d’AngularJS est présentée par la figure 26.
Figure 26 : Architecture d’AngularJS
Dans le cadre du projet, ce Framework est utilisé avec HTML pour la partie Front-end de
l’application. AngularJS permet d'étendre le vocabulaire HTML pour une application web.
L'environnement résultant est expressif, lisible et rapide à développer. AngularJS est un
ensemble d'outils pour la construction du cadre le plus adapté au développement d'applications.
Il est entièrement extensible et fonctionne bien avec d'autres bibliothèques. Chaque fonction
peut être modifiée ou remplacée en fonction des besoins en matière de flux de travail de
développement. La liaison de données est un moyen automatique de mise à jour de la vue
chaque fois que le modèle change, ainsi que la mise à jour du modèle chaque fois que la vue
change.
69
III.2.4 Serveur de base de données PostgreSQL
PostgreSQL est un système de gestion de bases de données relationnelles objet (ORDBMS). Ce
dernier a été développé à l'université de Californie au département des sciences informatiques
de Berkeley ( PostgreSQL Global Development Group, 2016). PostgreSQL est à l'origine de
nombreux concepts qui ne seront rendus disponibles au sein de systèmes de gestion de bases de
données commerciaux que bien plus tard. PostgreSQL est un descendant libre du code original
de Berkeley. Il supporte une grande partie du standard SQL tout en offrant de nombreuses
fonctionnalités modernes :
 requêtes complexes ;
 clés étrangères ;
 triggers ;
 vues modifiables ;
 intégrité transactionnelle ;
 contrôle des versions concurrentes (MVCC, acronyme de "MultiVersion Concurrency
Control").
De plus, PostgreSQL peut être étendu par l'utilisateur de multiples façons, en ajoutant, par
exemple :
 de nouveaux types de données ;
 de nouvelles fonctions ;
 de nouveaux opérateurs ;
 de nouvelles fonctions d'agrégat ;
 de nouvelles méthodes d'indexage ;
 de nouveaux langages de procédure.
Grâce à sa licence libérale, PostgreSQL peut être utilisé, modifié et distribué librement, quel
que soit le but visé, qu'il soit privé, commercial ou académique.
III.2.5 Postman
Dans son utilisation la plus basique, il s’agit d’un outil permettant d’exécuter des appels HTTP
à un serveur pour en interpréter la réponse en dehors de tout contexte métier (getpostman, 2016).
Postman se décline en deux versions : une application “in-browser” et une “application
packagée”, toutes deux pour Chrome. Les fonctionnalités sont proches mais pas strictement
identiques. Dans notre cas, il est utilisé la version packagée. Postman dispose d’un
70
environnement graphique complet pour gérer l’ensemble des interactions avec les micro
services.
III.2.6 Log4J
Log4j est un projet open source distribué sous la licence Apache Software initialement créé par
Ceki Gülcü et maintenu par le groupe Jakarta (Doudoux, 2013). Cette API permet aux
développeurs d'utiliser et de paramétrer un système de gestion de journaux (logs). Il est possible
de fournir les paramètres dans un fichier de configuration ce qui rend sa configuration facile et
souple. Log4j gère plusieurs niveaux de gravités et les messages peuvent être envoyés dans
plusieurs flux : un fichier sur disque, le journal des événements de Windows, une connexion
TCP/IP, une base de données, un message JMS, etc. Log4j utilise trois composants principaux
pour assurer l'envoi de messages selon un certain niveau de gravité et contrôler à l'exécution le
format et la ou les cibles de destination des messages :
 Category/Logger : ces classes permettent de gérer les messages associés à un niveau de

gravité;
 Appenders : ils représentent les flux qui vont recevoir les messages de log (exemple
SocketAppender pour logger à serveur distant);
 Layouts : ils permettent de formater le contenu des messages de log.
Ces trois types de composants sont utilisés ensemble pour émettre des messages vers différentes
cibles de stockage. Ceci permet au Framework de déterminer les messages qui doivent être
loggués, la façon de les formater et vers quelle cible les messages seront envoyés.
III.2.7 Maven
Maven est un outil de "build" (construction), de gestion de projet, un conteneur abstrait où
s'exécutent les différentes étapes de construction du projet (Doudoux, 2013). C'est un outil qui
s'est révélé indispensable pour les projets qui deviennent complexes et qui ont besoin de
construire et de gérer de manière cohérente de nombreux modules et bibliothèques
interdépendants, eux-mêmes utilisant des dizaines voire des centaines de composants tiers. C'est
un outil qui a fortement allégé le fardeau quotidien de la gestion des dépendances vers les
bibliothèques tierces pour des millions d'ingénieurs, et a permis à de nombreuses organisations
de se sortir de l'ornière de la gestion du build de projet pour atteindre un monde où l'effort requis
pour construire et maintenir un logiciel n'est plus le facteur limitant dans sa conception.
71
III.2.8 Tomcat
Apache Tomcat est une implémentation open source d'un conteneur web qui permet donc
d'exécuter des applications web reposant sur les technologies servlets et JSP (Doudoux, 2013).
Tomcat est diffusé en open source sous une licence Apache. C'est aussi l'implémentation de
référence des spécifications servlets jusqu'à la version 2.4 et JSP jusqu'à la version 2.0
implémentées dans les différentes versions de Tomcat. Dans le cadre du projet, le Framework
Spring utilisé embarque sa propre version de Tomcat. La version 8 vient avec la version de
Spring 4 utilisée pour mettre en œuvre le projet.
III.3 Implémentation de l’architecture

Cette section présente d’abord l’implémentation de l’architecture par modules, puis celle de
l’architecture du SIH intégrant les différents modules et enfin celle de l’architecture de la
solution en prenant en compte l’aspect cloud.
III.3.1 Architecture par modules

La figure 27 est l’architecture de chaque module. Elle garde la logique du patron d’architecture
MVC sans la vue et utilise la composante Spring Boot pour implémenter le métier du module.
Figure 27 : Implémentation de l'architecture pour chaque module
Dans certains cas, un module (exemple "Gestion des patients") doit communiquer avec le
système d’information d’un organisme à travers la couche API. La couche services implémente
la logique applicative du module tandis que la couche dao permet d’accéder aux données
stockées dans la base de données PostgreSQL en utilisant Spring Data JPA. La couche model
quant à elle, contient les entités à spécifique au module. La couche core contient les exceptions,
72
énumérations et utilitaires spécifiques au module. La composante Spring Boot IOC Container
représente le conteneur d’injection de dépendance du Framework Spring. Ce mécanisme permet
d’avoir une application extensible, plus flexible et facilement réorganisable et donc
maintenable. XXXService représente l’interface déclarative des méthodes qui constitue le micro
service tandis que XXXServiceImpl est son implémentation. Une partie importante est l’audit ;
elle est faite dans cette partie en utilisant Log4j.
Après avoir présenté l’implémentation de l’architecture de chaque module, nous passerons à
celle de l’architecture globale composée de tous les modules du système.
III.3.2 Architecture du SIH
L’architecture présentée à la figure 23 montre la structuration des composantes du SIH en
fessant abstraction des outils utilisés. Celle présentée à la figure 28 sera son implémentation.
Figure 28 : Implémentation de l'architecture du SIH
Pour accéder aux services fournis par le SIH, il faudra s’authentifier et avoir les droits d’accès
nécessaires. L’outil Spring Security du Framework Spring veille à l’application de la première
condition de cette règle en fournissant tous les éléments nécessaires pour authentifier un
utilisateur (cf. figure 9). En ce qui concerne le contrôle d’accès aux ressources du système, il
est relatif au rôle attribué à l’utilisateur et à travers lequel le système affiche un menu
dynamique et ainsi un utilisateur n’a pas accès aux opérations qu’il n’est pas habilité à exécuter.
La couche Service ou ESB est implémentée en utilisant la composante Spring Boot. Les
couches DAO sont implémentées en utilisant la technologie Spring Data JPA ; PostgreSQL est
utilisée comme moteur de base de données. Maven est utilisé pour gérer la dépendance entre
les modules et le ESB qui est la porte d’entrée au métier du SIH;
73
III.3.3 Architecture globale de la solution
L’architecture présentée à la figure 28 est le cœur de la solution dans le sens où elle fait ressortir
la structuration des composants métiers de la solution et les communications entre elles. Un
ensemble de composantes fournit par le Framework Spring sont utilisées pour prendre en
compte l’aspect cloud. La figure 29 est l’architecture implémentée de la solution globale en
prenant en compte l’aspect cloud.
Figure 29 : Architecture globale de la solution proposée
Nous expliquons ci-après la signification des éléments principaux de cette architecture.

 SIH :
SIH représente le cœur applicatif de la solution qui contient le métier du système. Il est possible
d’avoir plusieurs instances de SIH disponibles et fonctionnelles en même temps. La seule
condition est que le programme puisse accéder et communiquer avec les autres composantes et
ainsi intégrer l'architecture.
 Spring Cloud Netflix : Eureka Discovery :
Cette composante de Spring Cloud Netflix permet de jouer le même rôle qu’un DNS (Domain
Name System) en faisant la correspondance entre un nom et une ou plusieurs instances d’un
micro service. Chaque instance client vient s’enregistrer auprès d’elle en publiant ses
métadonnées : nom, adresse, état, statut, etc.
 Spring Cloud Netflix : Zuul Proxy :
Cette composante de Spring Cloud Netflix permet de router et de filtrer les requetés provenant
de la composante AngularJS. Elle gère aussi la répartition des charges (Load balancing) entre
74
les instances SIH en communiquant avec le serveur Eureka pour trouver l’instance la moins
chargée. Elle partage sa session avec les instances SIH en utilisant une authentification de type
SSO.
 Spring Cloud Config :
La composante Spring Cloud Config fournit un mécanisme de configuration des systèmes

distribués. Elle gère la configuration externe avec un dépôt tel que Git (comme à la figure 29)
contenant les fichiers de configuration centralisés de toutes les composantes du Framework
Spring de l’architecture. Elle fournit des techniques d’encryptage et de décryptage des valeurs
des propriétés contenus dans ces fichiers de configuration. Elle est facilement intégrable dans
une application Spring Boot mais peut être utilisée avec toutes les applications en cours
d'exécution dans une autre technologie.
 Navigateur :
Dans cette architecture, seuls les clients web sont pris en compte et sont représentés par
Navigateur. Eventuellement, les clients mobiles ne passeront pas forcément par AngularJS mais
ils communiqueront directement avec le proxy et recevront des données de type JSON.
III.4 Conception d’un cas d’utilisation

La conception met l’accent sur une solution conceptuelle qui satisfait aux exigences au lieu
d’insister sur l’implémentation.
III.4.1 Modèle dynamique du cas d’utilisation "Ajouter/structure"

III.4.1.1 Par le moyen d’un diagramme de séquence de conception
Dans cette sous-section, nous utilisons les stéréotypes de Jacobson tirés de (Roques, 2006) avec
un diagramme de séquence d’UML (cf. figure 30) pour montrer graphiquement comment un
message émis par un acteur, traverse les différentes couches de l’architecture. La fonctionnalité
qui correspond au cas d’utilisation "Ajouter une structure" est détaillée en guise d’exemple et
le scénario nominal est utilisé.
75
Figure 30 : Différentes étapes traversées par un message émis par un acteur
76
II.4.1.2 Par le moyen d’un diagramme de classe de conception
A partir du diagramme de séquence de conception de la figure 30, nous déduisons le diagramme
de classe de conception de la figure 31 en suivant les recommandations données dans (Roques,
2006). On notera l’utilisation du mot-clé « parameter » sur la dépendance entre certaines classes
pour refléter le type de lien temporaire qui existe entre ces dernières et le mot-clé « local » pour
montrer le caractère local d’une dépendance entre deux entités.
Figure 31 : Modèle dynamique pour le cas "ajouter une structure" : Diagramme de classe de conception
77
III.5 La gestion des erreurs et de la traçabilité
La gestion des erreurs permet d’interrompre l’exécution d’un programme si une erreur se
produit au cours du traitement en lançant une exception personnalisée et en retraçant
l’évènement origine. En effet, à chaque fois qu’une exception est lancée, le programme fait
appel à l’outil de journalisation log4j pour retracer les informations telles que : le message, la
source, le type de l’erreur, l’actions, etc. La figure 32 illustre cette gestion des erreurs par le
biais d’un diagramme de classe d’UML.
Figure 32 : Les classes utilisées dans la gestion des erreurs
En ce qui concerne traçabilité sur les opérations qui affecte la base de données, nous avons mis
en place une entité de base, mère de toutes les autres entités métiers. Elle implémente les
interfaces Serializable et Cloneable de Java comme en témoigne la figure 33.
Elle est dotée des méthodes copie() qui clone un objet estNouvelle() qui teste si l’entité
n’existait pas auparavant dans la base de données et physicalDelete() qui dira si la ligne créée
à partir de l’entité courante peut être supprimée physiquement de la base de donnée. En outre,
une opération de suppression correspond à la mise en jour du statut de la donnée. Le tableau
qui suit fournit une description des attributs de la classe.
78
codeUserCreated Le username de l’utilisateur qui a créé la
donnée
dateCreate Date de création de la donnée
codeUserUpdate Le username de l’utilisateur qui a mise à
jour la donnée
dateUpdate La date de mise à jour de la donnée
codeUserDeleted Le username de l’utilisateur qui a supprimé
la donnée
dateDeleted Date de suppression de la donnée
codeStructureCloud L’identifiant de la structure propriétaire de
la donnée
nameEntity Le nom de l’entitié à travers laquelle la
donnée a été créée
description Une description de la donnée
version La version de la donnée.
statut Le statut (ACTIF, SUPPRIMER) de la
donnée qui permettra d’effectuer une
suppression logique
Figure 33 : Classe abstraite de base
Ce chapitre a permis de montrer l’étude qui a été faite pour l’élaboration d’une architecture du
SIH à travers une série de présentations des styles architecturaux et les outils et technologies
qui sont utilisés dans le cadre du projet. Il a permis de détailler l’architecture des différents
modules qui composent le SIH ainsi que l’architecture de type SOA de tout le SIH et
l’architecture de la solution en tenant compte des aspects liés au cloud. Il a aussi été question
de présenter la conception d’un cas d’utilisation. Dans le chapitre suivant nous abordons la
partie consacrée à la mise en œuvre de la solution.
79
Chapitres IV : Mise en œuvre de la solution
Après avoir étudié, analysé les besoins de notre système et conçu la solution
correspondante, nous présentons sa mise en œuvre. En effet la réalisation part des résultats de
la conception. Les technologies et les outils choisissent durant cette phase de conception
permettent l’implémentation des fonctionnalités résultant de la phase d’analyse de chaque
module du système. Ce chapitre présente la réalisation de la solution. Il est décomposé en trois
(3) sections. La première présente l’ensemble des éléments de l’environnement de
développement, la deuxième fait la présentation de la solution et la troisième présente la une
manière de déployer l’application.
IV.1 Environnement de développement

Dans cette section nous présentons les outils utilisés pour mettre en place l’environnement de
développement du projet. Il s'agit de Eclipse et PhpStom comme environnements de
développement intégré (EDI), JUnit comme environnement de teste, Git comme outil de gestion
de versions, WAMPServer comme environnement de teste d’hébergement et Visual Paradigm
comme environnement de modélisation. Chacun est brièvement présenté dans la suite.
IV.1.1 Eclipse
Eclipse est un EDI dont le but est de fournir une plate-forme modulaire pour permettre de
réaliser des développements informatiques (Doudoux, 2013). Tout le code d'Eclipse a été donné
à la communauté par IBM qui est à l'origine afin de poursuivre son développement. Eclipse
utilise énormément le concept de modules nommés "plug-ins" dans son architecture. D'ailleurs,
hormis le noyau de la plate-forme nommé "Runtime", tout le reste de la plate-forme est
développé sous la forme de plug-ins. Ce concept permet de fournir un mécanisme pour
l'extension de la plate-forme et ainsi fournir la possibilité à des tiers de développer des
fonctionnalités qui ne sont pas fournies en standard par Eclipse.
IV.1.2 PhpStorm
PhpStorm est un EDI intelligent développé par jetBrains. Il est conçu pour la réalisation de
projets conséquents en PHP, et dans l’optique d’optimiser la productivité des développeurs
(OSAXiS, 2016). PhpStorm se distingue de la concurrence soit en proposant de nouvelles
fonctionnalités soit en proposant une implémentation plus efficace ou plus complète de
certaines fonctionnalités existant dans d’autres EDI. Il a aussi l’avantage d’intégrer un
interfaçage avec les principaux outils de gestion de versions (Git, SVN, etc.) et de gestion de
80
tâches (Redmine, YouTrack, etc.) sans installation ou configuration supplémentaire. Pour aider
les développeurs à fournir un code propre et à déboguer leur application, PhpStorm dispose de
nombreux outils. L’inspection de code a pour but de mettre en évidence les erreurs ou alertes
des différents scripts. Il est utilisé dans le cadre du projet pour le développement de la partie
web du système.
IV.1.3 JUnit
Imaginé et développé en Java par Kent Beck et Erich Gamma, JUnit désigne un Framework de
rédaction et d'exécutions de tests unitaires (Guy, 2016). Le but principal de JUnit est d'offrir au
développeur un environnement de développement simple, le plus familier possible, et ne
nécessitant qu'un travail minimal pour rédiger de nouveaux tests. Leur écriture ne représente
pas le seul intérêt d'un tel Framework. Une fois ces tests mis en place, il est très important de
pouvoir les exécuter et d'en vérifier les résultats très rapidement. Comme dit dans la définition
de la méthode de développement utilisé, chaque fonctionnalité développée est testée en utilisant
JUnit.
IV.1.5 Git
Git est un logiciel de gestion de versions décentralisé dont la tâche principale est de gérer
l’évolution du contenu d’une arborescence (Florestan, 2015). Il permet entre autres :
 De suivre l’évolution du code source (modifications effectuées sur les fichiers sources)
et ainsi être capable de revenir sur une version précédente en cas de problème.
 De travailler à plusieurs sur un même projet sans conflits de modifications.
Il est conçu pour être efficace tant avec les petits projets, que les plus importants. Git a
spécialement été créé pour le développement du noyau linux.
IV.1.6 WAMPServer
WAMPServer est une plate-forme de développement web sous Windows. WAMPServer est un
environnement comprenant deux serveurs (Apache et MySQL), un interpréteur de script (PHP),
ainsi que phpMyAdmin pour l'administration Web des bases MySQL. Dans le cadre de ce projet
WAMPServer est utilisé pour avoir le serveur Apache2 dans lequel sera tourné le client web du
SIH.
IV.1.7 Visual Paradigm

Visual Paradigm est un éditeur qui propose des outils pour la conception et la gestion lors du
développement de systèmes informatiques. Parmi cette suite d’outils figure Visual Paradigm
For UML que nous avons utilisé pour créer nos modèles. Il inclut tous les diagrammes UML
81
2.0 et offre une interface très intuitive aux modélisateurs. Sa version communauté est utilisée
dans le cadre du projet.
IV.2 Présentation de la solution

Il s'agit, dans cette section, de faire l’état d’avancement de la partie mise en œuvre de la solution.
Le système est composé de plusieurs modules. Chaque module fait l'objet d’une itération
partant de l’analyse au déploiement en passant par la conception, le codage et les tests unitaires
comme dit dans la méthode de développement. Malgré les modifications majeures apportées au
cours du développement, le socle de base (mise en place de l’architecture complète (cloud et
SIH) de la solution) est mis en place, le module "Référentiel" est traité à 100% et le module
"Gestion des patients" est à 90%. En effet toutes les fonctionnalités sont développées, testées et
le module est ajouté au bus de service (ESB). Il reste tout de même l’intégration dans la partie
web.
Avant de pouvoir bénéficier d’un service quelconque de SI, l’utilisateur doit s’authentifier
auprès du système. Pour cela il fournit son identifiant (nom d’utilisateur, mot de passe) à partir
d’un formulaire comme le montre la figure 34.
Figure 34 : Formulaire d'authentification
Un mécanisme de contrôle de saisie est utilisé dans tous les formulaires à travers lesquels un
utilisateur fournit des informations au système. Par exemple, pour ce formulaire le bouton
"connexion" est désactivé tant qu’une règle appliquée au formulaire est violée. La figure 35 en
est un exemple.
82
Figure 35 : Formulaire d'authentification avec une violation des règles
Si l’utilisateur fournit le bon identifiant, le système récupère son rôle et crée un menu
dynamique et une vue restreinte à l’ensemble des actions qu’il peut effectuer. Par exemple s’il
s’agit du super administrateur, il a une vue qui lui permet d’accéder qu’aux fonctionnalités qu’il
est habilité à exécuter comme en témoigne la figure 36.
Figure 36 : Vue du super administrateur
C’est la même technique qui est utilisée pour tout utilisateur. Les figures 37, 38 et 39 montrent
respectivement des vues pour un administrateur validateur, un administrateur créateur et un
médecin traitant d’une même structure sanitaire HFDK.
83
Figure 37 : Vue de l'administrateur validateur de la structure HFDK
Figure 39 : Vue de l'administrateur créateur de la structure HFDK
Figure 38 : Vue d'un médecin traitant de la structure HFDK
84
Si nous suivons par exemple le super administrateur, il peut exécuter toutes les opérations des
fonctionnalités qui sont accessibles à partir de sa vue. Par exemple dans la figure 40, le super
administrateur accède à la page pour ajouter une structure. Et dans la figure 41 il affiche la liste
des structures sanitaires abonnées aux services.
Figure 40 : Vue Ajouter Structure
Figure 41 : Vue lister les structures abonnées
85
Eureka Discovery renseigne sur l’état des micro services clients déployés, sur la capacité de la
machine serveur dans laquelle il tourne, etc. La figure 43 illustre la vue offerte par Eureka et
dans laquelle trois instance du micro service SIH (ESB-SERVICE) et le serveur de proxy
(Proxy-Service) sont déployés et fonctionnels.
Figure 42 : Les micro services clients au serveur Eureka déployés
Pour la traçabilité, toutes les actions faites par un utilisateur sont journalisées dans un fichier
journal comme en témoigne la figure 43 qui montre une tentative d’authentification d’un
utilisateur.
Figure 43 : Tentative d'authentification d'un utilisateur
V.3 Déploiement de la solution

Pour montrer la configuration physique des différents composants qui participent à l’exécution
du SIH, ainsi que des artéfacts (entités physiques, un fichier de journalisation par exemple)
qu’ils supportent, nous avons établis un diagramme de déploiement d’UML présenté à la figure
44. Dans ce diagramme de déploiement, il est important de noter que les serveurs d’instances
peuvent faire tourner plusieurs instances de SIH moyennant chacun un serveur d’application
(Tomcat dans notre cas). Une seule est choisie pour chaque serveur dans ce diagramme pour
des soucis de clarté. Cependant toute autre instance aurait la même configuration.
86
Figure 44 : Le déploiement de la solution
L’application peut tourner dans presque tous les serveurs d’application qui existent dans le
standard moyennant quelques configurations. Il est aussi possible d’avoir d’autres serveurs
d’instances ; ils auront eux aussi la même configuration que ceux présentés dans la figure 44.
Il suffit juste de connaitre l’adresse de la machine et le numéro de port pour déployer une
nouvelle instance de SIH qui intègre automatiquement l’architecture. L’ordre de déploiement
de la solution est le suivant :
1. démarrer le serveur de configuration Cloud Config;

2. démarrer le serveur de découvert Eureka Discovery ;
3. démarrer le serveur de base de données Data Server ;
4. démarrer le serveur de proxy Zuul Proxy;
5. démarrer au moins une instance de SIH d’un serveur d’instance;
6. démarrer le serveur Apache2.
Ce chapitre qui est consacré à la mise en œuvre de la solution résultant de la conception a permis
de présenter respectivement l’ensemble des outils qui constituent l’environnement de
développement, la présentation de la solution, de même qu'une manière possible de la déployer.
87
Conclusion générale
Dans le cadre de notre stage de fin de formation au sein de l’entreprise FINETECH,

nous avions pour travail de faire une étude des structures sanitaires afin de mettre en place un
service cloud fournissant un système d’information hospitalier (SIH) composé de plusieurs
modules. Pour atteindre les objectifs fixés au début du projet, nous avons tout d’abord décrit
les axes majeurs et piliers qui constituent un SIH à travers une série de définitions de concepts
métier et une présentation du sujet. Nous basant sur le cahier des charges clairement détaillé et
en adoptant une méthode de développement mixte composé de pratiques issues de Scrum et de
XP, nous avons ensuite procédé à l’analyse et à la spécification des besoins non fonctionnels
et fonctionnels avant d’en venir à la phase de conception et de mise en œuvre. Toutes les
fonctionnalités du module "Référentiel" sont développées, testées, intégrées au bus de service
et accessible à partir de la partie web de l’application. Tandis que pour le module "Gestion des
patients", il reste l’intégration dans la partie web. Le retard occasionné se justifie par le fait que
les exigences du client n’ont cessé d'augmenter au fil du temps. Le projet est passé de système
d’information hospitalier pour une structure sanitaire spécifique à service cloud offrant un
système d’information hospitalier en passant par système d’information hospitalier fonctionnel
pour toute structure.
Dans un cadre personnel, nous pouvons dire que notre parcours pour la réalisation de ce
mémoire a été enrichissant. En effet, ce projet nous a permis d'effectuer beaucoup de recherches
mais surtout de mieux connaître l'environnement de l’entreprise et du domaine de la santé. Il
nous a également apporté de nouvelles connaissances tant méthodiques, organisationnelles que
techniques. Aussi, nous espérons que ce mémoire, support du travail qui a été confié à notre
modeste compétence, a respecté les normes aussi bien dans la forme que dans le fond, et que sa
réalisation entière pourra satisfaire ses lecteurs.
Par ailleurs, pour que la mise en œuvre du projet SIH soit effective, il faut impliquer les
utilisateurs finaux afin qu’ils manifestent éventuellement des besoins réels pour le système. Et
cela, à commencer par le directeur des structures sanitaires ainsi que tout le personnel de soin;
D’autre part, il faut pousser les différents services des structures sanitaires à l’utilisation de
l’informatique dans leur fonctionnement habituel. Ceci peut se faire en engageant une équipe
d’informaticiens pour suivre et accompagner les utilisateurs finaux.
88
Comme perceptives nous projetons de :
 terminer la réalisation des fonctionnalités des différents modules ;
 effectuer tous les tests d’intégration ;
 déployer le projet dans les conditions fixées par l’entreprise ;
 former le personnel médical des structures sanitaires abonnées ;
 développer une version mobile étant donné qu’actuellement presque tout le
monde a un smartphone. En plus pour un personnel de soin, il est plus facile et
plus accessible de manipuler une tablette que de manipuler une machine pour
effectuer une prestation ;
 développer un module d’aide à la décision pour les autorités sanitaires et
politiques ;
 développer un module de gestion des données géographique pour permettre aux
autorités de pouvoir avoir une vue géographique des zones les plus affectées par
une maladie donnée.
89
Référence
Dubois, J., Retaillé, J. P., & Templier, T. (2007). Srping par la pratique. Mieux développer ses
applications Java/J2EE avec Spring, Hibernate, Struts, Ajax,... Eyrolles.
(2016, Juin 27). Récupéré sur who: http://www.who.int/healthsystems/topics/fr/
(2016, Juin 27). Récupéré sur le-cloud.net: http://le-cloud.net
(2016, Juin 27). Récupéré sur journaldunet: http://www.journaldunet.com/solutions/saas-

logiciel/saas-definition.shtml
(2016, Juillet 1). Récupéré sur OSAXiS: http://www.osaxis.fr/accelerer-ses-developpements-php-

avec-phpstorm/
(2016, Juin 08). Récupéré sur Pivotal Software: https://spring.io/docs/reference
ATIH. (2015). Atlas des 2015 des SIH, Etat des lieux des systèmes d'information hospitaliers.
Bass, Clements, & Kazman. (2013). Software Architecture in Practice. 3rd Edition.
BELL, M., & MARKS, E. A. (2006). Service Oriented Architecture (SOA): A Planning and Implementation
Guide for Business and Technology.
Bloch, L., & Wolfhugel, C. (s.d.). Sécurité informatique, principes et méthode. Eyrolles.
Doudoux, J. M. (2013). Développons en Java.
Fielding, R. T. (2016, Juin 25). Récupéré sur Roy T. Fielding:

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Florestan, G. (2015). Veille BTS SIO : Git.
Foundation, O. (2016). OWASP Top 10-2013 Les dix risques de sécurité applicatifs web les plus
critiques.
Gabay, J., & Gabay, D. (2008). UML 2 ANALYSE ET CONCEPTION, Mise en oeuvre guidée. Paris: Dunod.
Group, P. G. (2016, Juin 01). postgresql. Récupéré sur Documentation PostgreSQL 9.4.8:
http://docs.postgresqlfr.org/9.4/
Guy, R. (2016, Juin 25). Récupéré sur http://gfx.developpez.com/tutoriel/java/junit/
Learned, E. P., Andrews, R. K., Christensen, C. R., & Guth, W. D. (1969). Business Policy, Text and
Cases. Irwin.
Lewis, J., & Fowler, M. (2016, Mars 5). microservices.html. Récupéré sur martinfowler:
http://martinfowler.com/articles/microservices.html
Marks, A., Eric, Bell, & Michael. (2006). Service-Oriented Architecture: A planning and Implementation
Guide for Business and Technology.
NEUMANN, I. (2016, Juin 25). Récupéré sur

http://ineumann.developpez.com/tutoriels/alm/agile_scrum/
90
OMS, O. M. (s.d.).
PONÇON, G. (2000 ). Le management du système d'information hospitalier : la fin de la dictature

technologique. École Nationale de la Santé Publique.
République du Sénégal. (2008). Loi sur les données à caractère personnel. Journal officielle.
Roques, P. (2006). UML 2 par la pratique, Etudes de cas et exercices corrigés. Eyrolles.
Schwaber, K., & Sutherland, J. (2013). Le Guide Scrum, Le guide définitif de Scrum : les règles du jeu.
Software, P. (2016, Juin 30). Récupéré sur https://spring.io
team, p. (2016, Avril 8). Récupéré sur https://www.getpostman.com/
Tremblay, R. (2007). Implantation d'une méthode agile de développement logiciel en entreprise. Une
culture accueillant le changement. Université Laval.
Trudel, F. (2009). L’ARCHITECTURE LOGICIELLE EN PRATIQUE.
Wikipédia. (2016, Juin 25). Récupéré sur

https://fr.wikipedia.org/wiki/Representational_state_transfer
Wikipédia. (2016, Mai 6). Récupéré sur https://fr.wikipedia.org/wiki/Logiciel_en_tant_que_service
Youssfi, M. (2015). Architectures logicielles distribuées basées sur les micro-services.
91

Memoirengagnethiamfinal 160927130825

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

Memoirengagnethiamfinal 160927130825

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE DU SENEGAL

UNIVERSITE CHEIKH ANTA DIOP DE DAKAR

ECOLE SUPERIEURE POLYTECHNIQUE

MEMOIRE DE FIN DE CYCLE

DIPLOME D’INGENIEUR DE CONCEPTION (DIC)

SUJET : Etude et mise en place d’un système d’information

Lieu de stage : Période stage : 03/2016 – 07/2016

Présenté et soutenu par Professeur encadreur Maitres de stage

Ngagne THIAM Dr Ibrahima FALL Mme Seynabou Sy DIARRA

Mme Dior Fall Lo

Année universitaire : 2015 – 2016

UNIVERSITE CHEIKH ANTA DIOP DE DAKAR

MEMOIRE DE FIN DE CYCLE

DIPLOME D’INGENIEUR DE CONCEPTION (DIC)

SUJET : Etude et mise en place d’un Système d’Information

Lieu de stage : Période stage : 03/2016 – 07/2016

Présenté et soutenu par Professeur encadreur Maitres de stage

Ngagne THIAM Dr. Ibrahima FALL Mme Seynabou Sy DIARRA

Mme Dior Fall LO

Année universitaire : 2015 – 2016

L’Ecole Supérieure Polytechnique de Dakar (ESP) est un établissement public de

Sigles et Significations ______________________________________________________ 11

I.2 Présentation du sujet ________________________________________________________ 19

I.3 Définition de la méthode de développement _____________________________________ 25

Chapitres II : Analyse et spécification des besoins ________________________________ 32

Chapitre III : Conception _____________________________________________________ 58

III.2 Présentation des outils et technologies utilisés ___________________________________ 64

III.3 Implémentation de l’architecture ______________________________________________ 72

III.4 Conception d’un cas d’utilisation ______________________________________________ 75

III.5 La gestion des erreurs et de la traçabilité________________________________________ 78

IV.2 Présentation de la solution ___________________________________________________ 82

Figure 1 : Les différents modules du SIH ............................................................................................... 21

Tableau 1 : Scénario nominal de la description textuelle de la fonctionnalité "S'authentifier"........... 37

Le reste du document est organisé en quatre (4) chapitres :

 le premier chapitre, intitulé "Présentations générales", fait une description de la structure

Ce chapitre présente en premier lieu la structure au sein de laquelle le stage a été

I.1 Présentation de la structure d’accueil

I.1.1 Pôle audit & conseils

I.2 Présentation du sujet

I.2.1.3 Les objectif d’un SIH

I.2.1.4 Les modules du SIH

Figure 1 : Les différents modules du SIH

Ce module permet de collectionner, centraliser, valoriser automatiquement les

I.2.1.7 Le contexte du sujet :

 L'équipe et la communication avant les outils et processus : dans la vision agile,

Figure 2 : Vue globale de la méthode Scrum (NEUMANN, 2016)

Figure 3 : Cycle de XP – Wikipédia

L’analyse et la spécification des besoins sont des étapes primordiales de chaque

II.1 Analyse des besoins non fonctionnels

II.2 Analyse des besoins fonctionnels

La figure 6 permet de faire ressortir graphiquement le découpage du SIH en modules et les

II.2.3 Analyse fonctionnelle par module

II.2.3.1 Analyse fonctionnelle du module "Référentiel"

A. Descriptions des fonctionnalités du module "Référentiel"

Deuxième scénario alternatif : Il commence au point 4 du scénario nominal quand l’utilisateur

Scénario d’erreur : Ce scénario commence au point 4 du scénario nominal quand l’utilisateur

Post condition : L’utilisateur est authentifié par le système.

Figure 8 : Interactions entre un utilisateur et le SIH pour la réalisation de la fonctionnalité "S'authentifier"

a. Description textuelle de la fonctionnalité "Ajouter une structure "

c. Description textuelle de la fonctionnalité "Consulter/Supprimer une structure"

e. Description textuelle de la fonctionnalité "Consulter/Modifier une structure "

Post condition : Une structure est mise à jour.

g. Description textuelle de la fonctionnalité "Consulter les structures"