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.

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

Figure 11 : Interactions entre le super administrateur et le SIH pour la réalisation de la fonctionnalité "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é


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


60

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.

Figure 19 : Autres avantages d'une architecture en SOA

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 ;

Agilité

Interopérabilité

Extensibilité

Réduction des coutsMaintenabilité

Réutilisation de service

Réduction des coûts

Figure 20 : Exemple d'architecture en SOA d’un SIH


61

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.

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 ;

Figure 21 : Les différentes composantes de l'architecture du modèle-vue-contrôleur


62

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


63

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.

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.

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 ;

Figure 22 : L’architecture d’un micro service (Youssfi, 2015)

Figure 23 : Architecture du SIH


64

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.


65

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


66

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)


67

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.


68

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


69

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.

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.

Figure 26 : Architecture d’AngularJS


70

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


71

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.


72

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.

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,

Figure 27 : Implémentation de l'architecture pour chaque module


73

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

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;

Figure 28 : Implémentation de l'architecture du SIH


74

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.

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

Figure 29 : Architecture globale de la solution proposée


75

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


76

Figure 30 : Différentes étapes traversées par un message émis par un acteur


77

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


78

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.

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.

Figure 32 : Les classes utilisées dans la gestion des erreurs


79


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


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.

Figure 33 : Classe abstraite de base


80

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

Chapitres IV : Mise en œuvre de la solution


81

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


82

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.

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.

Figure 34 : Formulaire d'authentification


83

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.

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.

Figure 35 : Formulaire d'authentification avec une violation des règles

Figure 36 : Vue du super administrateur


84

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


85

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


86

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.

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.

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.

Figure 42 : Les micro services clients au serveur Eureka déployés

Figure 43 : Tentative d'authentification d'un utilisateur


87

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.

Figure 44 : Le déploiement de la solution


88

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.

Conclusion générale


89

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.


90

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/

Référence


91

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.

Mémoire ngagne thiam_final

Engineering

Transcript of Mémoire ngagne thiam_final