Mémoire ngagne thiam_final

Année universitaire : 2015 – 2016
REPUBLIQUE DU SENEGAL
***** * * ********
UNIVERSITE CHEIKH ANTA DIOP DE DAKAR
SUJET : Etude et mise en place d’un système d’information
hospitalier (SIH) basé sur le cloud
MEMOIRE DE FIN DE CYCLE
Pour l’obtention du :
DIPLOME D’INGENIEUR DE CONCEPTION (DIC)
Présenté et soutenu par Professeur encadreur Maitres de stage
Ngagne THIAM Dr Ibrahima FALL Mme Seynabou Sy DIARRA
Mme Dior Fall Lo
ECOLE SUPERIEURE POLYTECHNIQUE
DEPARTEMENT GENIE INFORMATIQUE
Lieu de stage : Période stage : 03/2016 – 07/2016

Etude et mise en place d’un Système d’Information Hospitalier (SIH) basé sur le cloud
1

2
Année universitaire : 2015 – 2016
REPUBLIQUE DU SENEGAL
***** * * ********
UNIVERSITE CHEIKH ANTA DIOP DE DAKAR
SUJET : Etude et mise en place d’un Système d’Information
Hospitalier (SIH) basé sur le cloud
MEMOIRE DE FIN DE CYCLE
Pour l’obtention du :
DIPLOME D’INGENIEUR DE CONCEPTION (DIC)
Présenté et soutenu par Professeur encadreur Maitres de stage
Ngagne THIAM Dr. Ibrahima FALL Mme Seynabou Sy DIARRA
Mme Dior Fall LO
ECOLE SUPERIEURE POLYTECHNIQUE
DEPARTEMENT GENIE INFORMATIQUE
Lieu de stage : Période stage : 03/2016 – 07/2016
Chapitres II :
Analyse et
spécification
des besoins

3
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 ;
Dedicaces

4
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.
Remerciements

5

6
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.
Avant-propos

7
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.
Résumé

8
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.
Abstract

9
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
Table des matières

10
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

11
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
Sigles et Significations

12
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
Table des figures

13
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

14
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
Table des tableaux

15
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 ;
Introduction

16
 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.

17
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.
Chapitre I : Présentations générales

18
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

19
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 ;

20
 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é ;

21
 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) :
 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 ;
Figure 1 : Les différents modules du SIH

22
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.

23
 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

24
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.

25
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

26
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).

27
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.
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 ;
Figure 2 : Vue globale de la méthode Scrum (NEUMANN, 2016)

28
 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.).
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
Figure 3 : Cycle de XP – Wikipédia

29
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.

30
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.
Figure 4 : Les diagrammes d'UML

31
 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.

32
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é ;
Chapitres II : Analyse et spécification des besoins

33
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.

34
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 5 : Fonctionnalités globale du système
Figure 6 : Découpage des modules du SIH en package et les relations entre eux

35
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.

36
Figure 7: Les fonctionnalités du module "Référentiel"

37
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.

38
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"

39
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"

40
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.
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.
Figure 9 : Interactions entre le super administrateur et le SIH pour la réalisation de la fonctionnalité "Ajouter une structure"

41
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.

42
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.
"consulter/supprimer une structure"

43
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 ".

44
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.
"Consulter/Modifier une structure"

45
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.
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
Figure 12 : Interactions entre le super administrateur et SIH pour consulter la liste des structures

46
Figure 13 : Liste des entités métiers du module "Référentiel"

47
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)

48
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.

49
Figure 14 : Les activités dans le module "Gestion des patients"

50
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"

51
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.

52
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".

53
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.
Figure 16 : Interactions entre un personnel de soin et le SIH pour "Effectuer une demande"

54
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".

55
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.
Figure 17 : Interactions entre personnel de soin et SIH pour "Produire un document"

56
Figure 18 : Liste des entités du module "Gestion des patients"

57
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.
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é
Conclusion du chapitre
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.
index Identifiant unique du patient créé à partir de
son nom, de son prénom, du prénom de son
père, etc.

58
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» ;
Chapitre III : Conception

59
 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

Mémoire ngagne thiam_final

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (6)

Similaire à Mémoire ngagne thiam_final

Similaire à Mémoire ngagne thiam_final (20)

Dernier

Dernier (20)

Mémoire ngagne thiam_final