Conception d'un Système d'information sanitaire prévention d'alerte sur les épidémies

UNIVERSITE DE LUBUMBASHI
FACULTE DES SCIENCES
DEPARTEMENT DE MATHEMATIQUES ET INFORMATIQUE
CONCEPTION D’UN SYSTEME
D’INFORMATION SANITAIRE POUR LA
PREVENTION ET LA RIPOSTE D’EPIDEMIES
CAS DE DPS HAUT KATANGA
Présenté par : NYAMI NYATE Ruphin
Mémoire présenté et défendu en vue de
l’obtention du grade Bachelier en
Mathématiques et Informatique
Option : Informatique
Dirigé par : Prof. Daniel BAVUEZA

~ I ~
ÉPIGRAPHE
« La science, c’est ce que le père enseigne à son fils. La technologie, c’est ce
que le fils enseigne à son papa »
(Michel Seres)

~ II ~
REMERCIEMENTS
Nous te bénissons toi le Dieu tout puissant, maitre de temps et de circonstances,
toi qui as été au début de cette année académique 2018-2019 comme Alpha, durant le parcours
comme Emmanuel et à la fin de l’année comme Oméga. Merci de ton amour et de ta grâce
imméritée jusqu’à ce jour.
Nous souhaitons avant tout remercier notre directeur de mémoire, Professeur
Daniel BAVUEZA, pour le temps qu’il a consacré à nous apporter les outils méthodologiques
indispensables à la conduite de cette étude ; lui qui nonobstant son agenda multidimensionnel,
n’a aménagé aucun effort pour parfaire cette œuvre. Ses conseils et remarques fructueux, sa
disponibilité et surtout sa serviabilité intrinsèque ont contribué au succès de notre mémoire.
Nous remercions les autorités décanales et les professeurs de l’université
de Lubumbashi, qui nous ont fourni les outils nécessaires à la réussite de nos études
universitaires.
Nous témoignons la grandeur d’âme de Madame Daniel Louise EDIA MWANZA
durant la période de rédaction de ce projet et aux protégés de Pax MWANZA : Sa majesté
AMANI, Gift la princesse ELEMANU, EL-BERTH Alliance MWANZA, Préférée Rébecca
TSHIBWABWA pour vos motivations combien louables pour moi.
Une petite mention spéciale pour la reine Angélique LENAR, la princesse Syntyche
NYAMI les princes (Ganelon NYAMI, Gracien NYAMI et Anael NYAMI) tous de la
dynastie Ruphine, pour leur unité et patience durant ce dur labeur académique.
Nous gardons des pensées pieuses à l’égard de NKULU WA KAMANA Kester
qui aurait été présent dans cette salle comme récipiendaire si la vie n’en avait décidé autrement.
Ruphin NYAMI

~ III ~
TABLE DES MATIERES
ÉPIGRAPHE .............................................................................................................. I
REMERCIEMENTS.................................................................................................... II
LISTE DES ABREVIATIONS........................................................................................V
LISTE DE FIGURES..................................................................................................VII
INTRODUCTION GENERALE ...................................................................................1
1. CHOIX ET INTERET DU SUJET........................................................................1
2. PROBLEMATIQUE ET HYPOTHESES.............................................................1
a) PROBLEMATIQUE ....................................................................................1
b) HYPOTHESE............................................................................................ 2
3. ETAT DE LA QUESTION .............................................................................. 2
4. METHODES ET TECHNIQUES.................................................................. 3
4.1. METHODES............................................................................................. 3
4.2. TECHNIQUES.......................................................................................... 4
5. DELIMITATION FONNCTIONNELLE DE L’ETUDE ........................................ 5
6. SUBDIVISION DU TRAVAIL.................................................................................. 5
PREMIER CHAPITRE : CADRE CONCEPTUEL ET THEORIQUE ................................. 6
1.0. Introduction................................................................................................ 6
1.1. Cadre conceptuel ........................................................................................ 6
1.1.2. Riposte contre épidémie........................................................................... 8
1.2 CADRE THEORIQUE................................................................................... 9
1.2.1 PROCESSUS DE DÉVELOPPEMENT LOGICIEL ................................................... 9
1.2.1.2. Un processus de modélisation avec UML...................................................... 11
DEUXIEME CHAPITRE : CADRE DE REFERENCE : PRESENTATION DE
L’ORGANISATION ..................................................................................................17
2.1. Présentation de la Division Provinciale de la Santé du Haut Katanga ...............17
2.1.1. Aperçu historique ...........................................................................................17
2.1.2. Situation Géographique .................................................................................17
2.1.3. Mission..........................................................................................................18
TROISIEME CHAPITRE : APPLICATION DE LA METHODE 2TUP DANS LA
CONCEPTION DE JANGOSOFT ............................................................................ 22
3.0. Introduction.................................................................................................... 22
3.1. Etude préliminaire ..................................................................................... 22
3.1.1. Présentation du Projet à réaliser.............................................................. 22
3.1.2. Recueil des besoins fonctionnels.............................................................. 22

~ IV ~
3.1.3. Identification des acteurs ........................................................................ 23
3.1.4. Identification des messages ..................................................................... 24
3.1.5. Modélisation du contexte....................................................................... 25
3.2.1. Identification des cas d’utilisations........................................................... 27
3.2.2. Description préliminaire de cas d’utilisation............................................. 29
3.2.2.1. Élaboration du diagramme des cas d’utilisation ....................................... 30
3.2.2.2. Description détaillée de cas d’utilisation .................................................. 30
3.2.2.3. Élaboration du diagramme d’activité....................................................... 39
3.2.2.4. Élaboration des diagrammes de séquences système .................................. 40
3.2.3. Définition des itérations.......................................................................... 43
3.2.6. Élaboration du diagramme de classe métier............................................. 47
3.3. ANALYSE................................................................................................... 48
3.3.1. Découpage en catégories ........................................................................ 48
3.3.1.1. Diagramme de packages d’analyse .......................................................... 48
3.3.2. Dépendances entre catégories................................................................. 49
3.3.3. Développement du modèle statique ....................................................... 49
3.3.4.1. Identification des opérations système ...................................................... 52
3.3.5. Spécification détaillée des opérations systèmes « JANGOSOFT »............... 53
3.3.5.2. Diagramme d’interaction globale......................................................... 62
3.4.1. Conception détaillée du cas d’utilisation « Notifier cas »........................... 64
3.4.2. Configuration matérielle de JANGOSOFT ............................................... 69
3.4.3. Architecture en couches de JANGOSOFT ................................................ 70
3.4.4.1. Spécification du style d’architecture 3-tiers : Diagramme de composants....71
CHAPITRE QUATRE : RESULTATS DE L’ETUDE........................................................ 74
4.2. Environnement d’exécution de notre application ............................................. 74
4.3. Environnement de développement............................................................... 75
CONCLUSION GENERALE......................................................................................81
BIBLIOGRAPHIE .................................................................................................... 82

~ V ~
LISTE DES ABREVIATIONS
A
- API : Abstract Programing Application
- AS : Air de Santé
B
- BCZ : Bureau central de la Zone de Santé
- BPC : Bureau provincial de Contrôle contre le SIDA
C
- CDEP : Consulter Données Epidémiologique
- CN : créer nouvelle Notification
- CZS : Chef de Zone de Santé
- CS : Centre de Santé
- CU : Cas d’Utilisation
D
- DAO : Data Access Object
- DM : Data Manager
- DPS : Division Provinciale de la Santé
- DS : Diagramme de Séquences
E
- ECPS : Equipe Cadre Provinciale de la Santé
- EJB : Entreprise Java Beans
F
- FAC : Force Armée Congolaise
G
- GR : Gérer Riposte
H
- HGR : Hôpital Général de Référence
- HQL : Hibernate Query Language
- HTML : Hypertext MarkUp Language
I
- IHM : Interface Home Machine
- IPSec : Internet Protocol Security
- ISC : Institut Supérieur de Commerce
- ISS : Institut Supérieur de Statistiques
- IT : infirmier Traitant
J
- JPA : Java Persitence API (Abstract Programming Application)
M
- MCZS : Médecin Chef de Zone de Santé
- MIP : Médecin Inspecteur Provincial
- MP : Mettre à jour Pathologie
- MVC : Modèle Vue Contrôleur
- MySQl : My Structured Query Language
O
- OMS : Organisation Mondiale de la Santé
- ONG : Organisation Non Gouvernementale
- ORM : Object RelationShip Model
P
- PDO : PHP Data Object

~ VI ~
- PEV : Programme Elargi de Vaccinations
- PHP : Hupertext Prepocessor
- PMA : Paquet Minimum d’Activités
- PNLP : Programme National de Lutte contre le Paludisme
R
- REST : Representational State Transfert
S
- SIDA : Syndrome Immunodéficitaire Acquis
- SNIS : Système National D’Information Sanitaire
- SURVEPI : Surveillance Epidémiologique
- SSP : Soins de Santé Primaires
T
- TA : Taux d’Attaque
- TL : Taux de Létalité
- TM : Taux de Morbidité
U
- UML : Unified Modeling Language
- UP : Unifie Process
- 2TUP : Two Truck UP
X
- XP : eXtreme Programming
W
- WAMP : Window Apache MySQL PHP
- WAN : Wide Area Net Work
Z
- ZS : Zonte de Santé

~ VII ~
LISTE DE FIGURES
Figure 1—Système d'information soumis à deux types de contraintes................................................. 10
Figure 2—Modèle en Y......................................................................................................................... 10
Figure 3—Localisation du bâtiment de la DPS Haut Katanga à Lubumbashi ........................................ 17
Figure 4—Pyramide sanitaire du Ministère de la Santé........................................................................ 20
Figure 5—Organigramme de la Division Provinciale du Haut Katanga................................................. 21
Figure 6—Circuit de circulation des Informations Epidémiologiques.................................................. 23
Figure 7—Diagramme de contexte statique......................................................................................... 26
Figure 8 : Diagramme de cas d'utilisation système ............................................................................... 30
Figure 9 : Diagramme d'activité............................................................................................................ 40
Figure 10—DS du CU s'Authentifier.................................................................................................... 41
Figure 11—DS du CU Notifier cas ....................................................................................................... 41
Figure 12—DS Compiler rapport HGR ................................................................................................ 42
Figure 13—Diagramme de séquences du CU centralisé données épidémiologique ............................ 43
Figure 14—Diagramme de package système........................................................................................ 44
Figure 15—Diagramme de classes participantes du cas d’utilisation « Notifier cas d’épidémie »....... 45
Figure 16—Diagramme de classes participantes du cas d’utilisation « Maitre à jour liste pathologie »
............................................................................................................................................................... 46
Figure 17—Diagramme de classes participantes du cas d’utilisation « Déclarer épidémie »............... 46
Figure 18—Diagramme de classes participantes du cas d’utilisation « Gérer Riposte »...................... 46
Figure 19—Diagramme de classes participantes du cas d’utilisation « Consulter données
épidémiologiques »............................................................................................................................... 47
Figure 20 : Diagramme de classe métier............................................................................................... 47
Figure 21—découpage en catégories du projet ..................................................................................... 48
Figure 22—Dépendances entre catégories............................................................................................ 49
Figure 23—Diagramme de paquetage d'analyse................................................................................... 48
Figure 24—Diagramme de classes de la catégorie Déclarations .......................................................... 50
Figure 25—Diagramme de classes de la catégorie Pathologies............................................................ 50
Figure 26—Diagramme de classes de la catégorie « StructureSanitaire » :.......................................... 51
Figure 27—Opérations système ............................................................................................................ 52
Figure 28—Interface du système........................................................................................................... 53
Figure 29—DS détaillée de l'opération système notifié........................................................................ 55
Figure 30—non validation de la création d’une notification pour cause d’un cas existant déjà.......... 56
Figure 31—Diagramme de communication de calcul de taux de mortalité, morbidité et de taux de
prévalence.............................................................................................................................................. 56
Figure 32—Diagramme de classes de conception détaillée.................................................................. 57
Figure 33—Diagramme de séquences de l'opération système "Créer Notification"............................ 58
Figure 34—Diagramme de séquences de l'Opération système "Ajouter catégorie pathologie".......... 59
Figure 35—Diagramme de séquences système du cas d'utilisation Gérer Riposte épidémie............. 60
Figure 36—Diagramme de séquences de conception du CU consulté données épidémiologiques..... 61
Figure 37—Diagramme d'états-transition ............................................................................................. 61
Figure 38—Diagramme d'interaction globale ....................................................................................... 62
Figure 39—Diagramme de navigation globale ..................................................................................... 63
Figure 40—Diagramme de classes de conception détaillée avec interfaces techniques de jangosoft 65
Figure 41—Diagramme de classes de conception détaillée techniques de jangosoft.......................... 66

~ VIII ~
Figure 42—Diagramme de séquences de conception de l'opération système "Notifier"
............................................................................................................................................................... 67
Figure 43—Configuration Matérielle de JANGOSOFT ....................................................................... 69
Figure 44—Modèle Logique de données .............................................................................................. 68
Figure 45—Modèle en couche de jangoSOFT...................................................................................... 70
Figure 46—Pattern MVC de JangoSoft ................................................................................................ 71
Figure 47—Architecture en couche de JANGOSOFT.......................................................................... 72
Figure 48—Spécification d’organisation du modèle de déploiement de JANGOSFT.......................... 73
Figure 49—Consol d'administration de Wildfly 8 ................................................................................ 74
Figure 50—déploiement de jangoSoft................................................................................................... 74
Figure 51—Interface démarrage d'Eclipse............................................................................................ 75
Figure 52—Environnement d'Eclipse ................................................................................................... 76
Figure 53—Architecture JPA................................................................................................................ 76
Figure 54--les couches de l'application jangosoft ................................................................................. 78
Figure 55—échantillon code de la couche Métier................................................................................. 78
Figure 56—échantillon de code sources de la couche métier ............................................................... 79
Figure 57—code source de la couche persistance................................................................................. 79
Figure 58—Capture d'écran du code source de la notification............................................................. 80
Figure 59—extrait de codes HQL avec Hibernate ................................................................................. 80
LISTE DES TABLEAUX
Tableau 1—Modélisation du contexte................................................................................................... 25
Tableau 2—Tableau de cas d'utilisation................................................................................................ 27
Tableau 3--Tableau 3—Tableau de contraintes non fonctionnelles du cas d'utilisation Notifier cas... 32
Tableau 4—Tableau de contraintes non fonctionnelles du cas d'utilisation Mise à jour Pathologie... 33
Tableau 5—Contraintes non fonctionnelles :........................................................................................ 36
Tableau 6—Contraintes non fonctionnelles :........................................................................................ 39
Tableau 7—Définition des itérations..................................................................................................... 43
Tableau 8—Structuration en package ................................................................................................... 44

~ 1 ~
INTRODUCTION GENERALE
1. CHOIX ET INTERET DU SUJET
Le choix de ce sujet est justifié du fait que nous sommes préoccupés par les soucis
de sauver de vie. Surtout qu’à ce moment précis la maladie à virus EBOLA est en train de
ravager nos compatriotes à l’Est de la République Démocratique du Congo. Ainsi nous avons
pensé choisir ce sujet.
L’intérêt sous l’angle social de ce sujet est de pouvoir sauver des vies humaines.
Une fois la solution proposée est implémentée, elle va effectivement permettre aux décideurs
de prendre des décisions à temps tant pour la prévention que pour la riposte afin de diminuer
la létalité de certaines pathologies.
Ce travail servir de la documentation aux futurs chercheurs en sciences
informatiques plus précisément dans la conception de systèmes d’information et aussi le
domaine épidémiologique.
Le souci d’approfondir nos connaissances dans le domaine de conception et
développement logiciel surtout dans un prestigieux cadre comme celui de la santé publique, qui
nous animés hier a rencontré un assouvissement palpable grâce à cette étude.
2. PROBLEMATIQUE ET HYPOTHESES
a) PROBLEMATIQUE
Par nature, la gestion des données médicales impose des structures de données
complexes à maitriser. Par ailleurs, la riposte à une épidémie est tributaire à la localisation de
celle-ci et surtout être en possession de données fiables pour la prise de décisions stratégiques
et opérationnelles.
La Division Provinciale de la Santé (DPS) du Haut Katanga est notifiée
hebdomadairement par 27 Zones de Santé constituée chacune d’un réseau de Centres de Santés
de Références ; la ville de Lubumbashi seule dispose de 11 Zones de Santé et avec plus de 45
Centres de Santé ; pour arriver à organiser une riposte efficace revient à disposer de données
de toutes ces structures avec une complétude c’est-à-dire la réception de notifications de chaque
structure sanitaire et promptitude (la réception à temps de notifications en provenance de
structures sanitaire) de l’ordre de 90%. Il est cependant quasi-impossible à l’heure actuelle
d’avoisiner ce taux de complétude et promptitude vu la distance géographique qui séparent les
structures sanitaires de la DPS et les moyens de communication mis en place. Et ceci a pour
conséquence directe l’augmentation du taux de létalité, mortalité, de prévalence de certaines
pathologies chroniques ; pourtant sous surveillance.
Il sied d’épingler les contraintes suivantes dans la gestion des ripostes d’épidémies
et de leur prévention :

~ 2 ~
- Faible taux de promptitude due au retard de transmission de données
épidémiologiques ;
- Difficulté d’organiser une riposte et prévention efficace dues aux notifications
partielles dans une zone de santé.
 Ici, il sera question de mener notre réflexion sur comment et quand centraliser
les données épidémiologiques pour augmenter l’accessibilité et afin de préparer une riposte à
temps ?
b) HYPOTHESE
Eu égard aux préoccupations soulevées dans la problématique, nous osons croire
que la centralisation de données épidémiologiques est possible grâce la conception d’une
application informatique qui permettra de :
- de réaliser des notifications des épidémies et transmission immédiate de données
à la DPS.
- Augmenter le taux de promptitude et complétude car les données arrivent à
temps et chaque structure aura notifié ses cas d’épidémie.
La disponibilité de données sanitaires permettra aux décideurs de décisions de
riposte dans des zones touchées et à fort taux de prévalence, ce qui permettra de combattre les
maladies à forte létalité et sauver ainsi de vies humaines.
3. ETAT DE LA QUESTION
Loin de nous la prétention d’être pionnier scientifique ; plusieurs chercheurs nous
précédé et aborder ce thème sous différents angles notamment :
- KAYEMBE MABANZO [1] dans son travail intitulé « Mise en place d’une base de
données centralisées pour le suivi de dossiers de patients dans une polyclinique ». (Mémoire
Licence 2011, ISS). L’auteur a soulevé la problématique de la centralisation de données d’un
patient sur une unique base de données afin de permettre l’accès direct par tous les intervenants.
L’auteur démontre que la prise en charge urgente d’un patient nécessite de connaître
l’historique de traitements antérieurs. Une chose est de centraliser les données et une autre est
d’augmenter l’accessibilité sans limite géographique. Nous nous somme inspiré du résultat de
son étude tout en y ajoutant l’aspect l’accessibilité sur différents terminaux.
- YAV RUMB Emmanuel [2] dans son travail intitulé « Analyse métier, Conception et
réalisation par approche agile d’un outil orienté objet de suivi de vaccinations des enfants de 0
à 5 ans». (Mémoire Licence 15, ISC). L’auteur a soulevé la problématique de la cartographie
sanitaire de la ville de Lubumbashi, afin d’assurer une couverture vaccinale dans tous les
quartiers. Comme solution, l’auteur a proposé une application Web couplée au GoogleMap
pour localiser les quartiers et connaitre le circuit de distribution de vaccin dans les hôpitaux
pilotes. La solution de cette étude permet de connaitre le nombre d’enfants vaccinés dans une
zone de santé, santé de santé ou air de santé. L’analogie avec ce prédécesseur résident au niveau
de l’architecture applicative basée sur un environnement distribué sous Java Enterprise Edition
(J2E) que nous avons opté dans notre étude.

~ 3 ~
- KATETA UPEMBA Boris [3], dans son projet qu’il intitulé : « conception du système
d’information d’échange et partage des dossiers de patient entre structures sanitaires en
République Démocratique du Congo que nous avons nommé Ehr-Drc (Electronic Health record
for democratic republic of congo) » (Mémoire Licence 2017 ISS).
 A soulevé les problèmes que voici : Aucune donnée importante de santé ne
s’échange ni se partage entre hôpitaux, les données de santé sont donc privées aux hôpitaux qui
les possèdent.
 En cas de transfert du patient d’un hôpital vers un autre, l’hôpital qui l’accueil
ne connait pas l’historique de celui-ci et recommence le processus à zéro.
 Le ministère de santé publique ne maitrise pas les dossiers de santé des patients
car n’étant pas à la procession des données de santé de ces derniers.
 Tout le monde peut consulter, prescrire et soigner ou traiter un patient, même un
inconnu au ministère de santé.
Face à ce qui précède, il a proposé de concevoir un système d’informatique
d’échange et partage des données de santé entre hôpitaux et acteurs de santé en République
Démocratique du Congo afin de rendre les hôpitaux et acteurs de santé interopérable.
Sa solution lui a permis de résoudre les problèmes cités-haut dans la mesure où :
les structures sanitaires, les divisions de santés et les autres acteurs de santé seront
interopérable, c’est-à-dire qu’ils pourront échanger et partager les informations sanitaires entre
eux ; il n’aura plus redondance des dossiers des patients dans car un patient n’aura qu’un dossier
privé accessible par toutes les structures sanitaires du pays.
Quant à nous, nous voulons mettre en place un système d’Information sanitaire avec
au centre une application Mobile pour le suivi et localisation épidémiologique dans la Ville et
ses environs. Qui pourra permettre aux différentes structures sanitaires de pouvoir fournir les
données sur tous les cas suspects d’épidémies. Alors la DPS peut avoir toutes les données
nécessaires à temps pour organiser la prévention et la riposte.
4. METHODES ET TECHNIQUES
4.1. METHODES
Pour mener notre projet nous allons faire usage d’une démarche disciplinée et pour
cela notre choix s’est porté vers la méthode 2TUP. Notre projet est basé sur un processus de
développement bien défini qui va de la détermination des besoins fonctionnels attendus du
système jusqu’à la conception et le codage final.
Ce processus se base lui-même sur le Processus Unifié (Unified Process) qui est
devenu un standard général pour l’orienté objet réunissant les meilleures pratiques de

~ 4 ~
développement. Cette méthode ne se base aucunement sur un processus linéaire mais bien, sur
un développement itératif et incrémental.
2TUP signifie «2 Track Unified Process» .C’est un processus qui répond aux
caractéristiques du Processus Unifié. Le processus 2TUP apporte une réponse aux contraintes
de changement continuel imposées aux systèmes d’information de l’entreprise. En ce sens, il
renforce le contrôle sur les capacités d’évolution et de correction de tels systèmes. «2 Track»
signifient littéralement que le processus suit deux chemins. Il s’agit des « chemins fonctionnels
» et «d’architecture technique», qui correspondent aux deux axes de changement imposés au
système d’information.
4.2. TECHNIQUES
Les techniques utilisées dans ce travail sont :
- La modélisation avec UML
Tout au long de cette étude, nous sommes passés par plusieurs outils qui génèrent
les diagrammes UML. Nous allons faire une présentation rapide de ceux-là.
 StarUML1 5.0 : c’est un outil open source, très simple d’utilisation et intuitif
pour un débutant. L’outil propose les diagrammes UML nécessaires à une bonne modélisation
et respect l’approche MDA. StarUML peut également générer de façon automatique des
diagrammes de classes grâce aux 26 patrons de conception qu’il connaît (3 patterns pour EJB).
- Enteprise Architect2
: c’est un outil propriétaire édité par la société SPARX Systems et
sûrement l’outil le plus professionnel sur le marché, il est très puissant et agréable à utiliser. Il est un
outil de modélisation UML, SysML, ArchiMate, BPMN de et offre toutes les possibilités du niveau de
modélisation UML, Base de données génération de codes sources et d’interface graphique.
- Technique de Programmation
La technique que nous allons utiliser pour programmer notre application est la
programmation orienté objet basé sur un modèle d’architecture du Modèle Vue Controleur
(MVC). Les outils techniques choisis sont :
 Adoption d’une architecture à 3 couches.
 Utilisation du langage Java.
 Utilisation coté client du langage PHP et Android
 Omission d’une base de données au profit de la Mapping Objet Relationnel (JPA
Hibernate).
 Utilisation de l’IDE Eclipse JEE et de ses plugins JbossTools, Hibernate.
1
https://www.projet-plume.org/fiche/staruml en ligne (20/12/2019)
2
http://www.umlchannel.com/fr/enterprise-architect (20/12/2019)

~ 5 ~
- Technique de prototypage
En se basant sur les codes sources des applications existantes dans le
développement mobil et distribué, nous allons bâtir la nôtre en important ces bibliothèques et
aspirer certain design de sites web pour construire notre application distribuée.
5. DELIMITATION FONNCTIONNELLE DE L’ETUDE
Le système d’information sanitaire étant vaste et que les données manipulées font
partie des étendues illimitées, nous allons borner fonctionnellement notre étude sur :
- La récolte de données épidémiologiques par les différents infirmiers traitants de
tous les centres de santé par zone de santé ;
- La déclaration des épidémies par l’agent de santé habilité selon le comportement
cette maladie sur terrain ;
- Préparer les ripostes sur les épidémies par chaque médecin chef de zone de
santé ;
- La gestion de pathologies sous surveillance par le Chef de Division Provinciale
de la Santé, selon le programma national de la santé ;
- La centralisation et archivage des données épidémiologiques périodiquement.
6. SUBDIVISION DU TRAVAIL
Hors mis l’introduction et la conclusion générales, notre projet sera mené en en
deux grandes parties :
La première partie portera sur le cadre conceptuel et théorique, dans celle-ci il y
aura deux chapitres : le premier chapitre de cette première partie du travail portera sur la
définition de concepts du métier et une approche théorique sur la démarche utilisée. Le second
sera orienté sur le cadre de référence où nous présenterons l’existant afin de s’équiper des
arguments probants sur l’éventuelle informatisation.
La deuxième partie du travail sera consacrée à l’Application de la méthode 2TUP,
qui sera organisé en deux chapitres dont le premier jettera son dévolu la démarche de
conception de la méthode 2TUP et la modélisation ; et le second enfin le dernier s’appesantira
sur l’implémentation et la présentation des résultats de notre étude.

~ 6 ~
PREMIER CHAPITRE : CADRE CONCEPTUEL ET THEORIQUE
1.0. Introduction
Ce chapitre traite des notions générales en rapport avec notre étude. Il subdivisé en
deux principaux points ; le premier concerne le cadre conceptuel ou la définition des concepts-
clés et le second traite des notions générales en rapport avec notre étude.
1.1. Cadre conceptuel
Dans tout travail, il y a des concepts-clés qui reviennent très souvent et dont la
définition constitue un point de départ pour la compréhension de tout le travail. Il est donc
important, dans le cas de notre étude, de commencer par définir les concepts-clés qui
reviendront en leitmotive tout au long de notre travail. Nous allons donc définir successivement
le concept d’épidémie et les concepts qui lui sont liés, le concept de riposte.
1.1.1. Epidémie
Une épidémie (du grec epi = au-dessus et demos = peuple) est la propagation rapide
d'une maladie infectieuse à un grand nombre de personnes, le plus souvent par contagion [4].
Selon le Dictionnaire Hachette 2015, l’épidémie est définie comme étant un développement
rapide d’une maladie chez un grand nombre d’individu d’une région donnée. Par exemple :
EBOLA, Cholera, Poliomyélite, etc. ;
Selon les perspectives de cette étude, une épidémie est une augmentation d'une
maladie endémique ou l'apparition d'un grand nombre de malades là où la maladie était absente.
1.1.1.1. Epidémiologie
Selon Mégarbane [5], L’épidémiologie est branche de la médecine qui étudie les
divers facteurs conditionnant l'apparition, la fréquence, le mode de diffusion et l'évolution des
maladies affectant des groupes d'individus. Les indicateurs épidémiologiques essentiels sont :
 Prévalence : le rapport entre les anciens cas + nouveau cas / population couverte par
une zone de santé.
 Incidences ou taux d’attaque
Le taux d’attaque (TA) est l’incidence cumulée des cas d’une pathologie dans le
temps depuis le début de l’épidémie. Il est essentiel de connaître le nombre total de personnes
vivant dans une zone affectée pour calculer le TA. Le TA est plus précis lorsque l’on utilise
des chiffres de population correspondant aux zones administratives signalant des cas. Par
exemple, la description de l’impact d’une épidémie touchant 3 quartiers d’une ville est plus
précise si la population totale de ces 3 quartiers sert de base au calcul, plutôt que la population
totale de la ville.
Le TA est habituellement exprimé en pourcentage. La formule de calcul est la suivante :
Nombre de cas pendant une période
TA = ––––––––––––––––––––––––––––––––––––––––––––––––– x 100
Population exposée à l’épidémie pendant la même période

~ 7 ~
 Taux de morbidités
Le taux de morbidité est le pourcentage des individus malades dans une population,
dans un temps donné, d’une maladie particulière ou de l’ensemble des maladies.
 Taux La létalité
Le taux de létalité est la proportion de cas fatals liés à une maladie ou à une
affection particulière, par rapport au nombre total de cas atteints par la maladie ou concernés
par la condition particulière. Le taux de létalité (TL) est la proportion de cas d’une pathologie
qui meurent de cette même pathologie ou de ses complications dans les centres de traitement
et/ou dans la communauté [6].
Le TL est exprimé en pourcentage. La formule de calcul est la suivante :
Nombre de décès dus à une pathologie pendant une période
TL = –––––––––––––––––––––––––––––––––––––––––––––––– x 100
Nouveaux cas de la pathologie pendant la même période
Dans les structures de traitement, le TL est calculé sur une base hebdomadaire et cumulative. Il
sert évaluer la qualité de la prise en charge des patients. L’indicateur standard d’une prise en
charge adéquate est un TL < 1%. Toutes les structures doivent surveiller le TL et la qualité des
soins, en particulier si le TL est > 1%. Le TL global combine les décès survenus dans les
structures de traitement et dans la communauté. Il est suivi pendant toute la durée de l’épidémie
et donne une indication de l’adéquation de la réponse en termes de prévention des décès
évitables.
1.1.1.2. Surveillance épidémiologique
Il s’agit d’une activité de santé publique qui a pour objet de collecter, de façon
continue, des Informations sur les évènements de santé, d’analyser ces informations pour
construire des indicateurs chiffrés et de les cartographier, puis de diffuser ses résultats, afin de
produire une aide aux décideurs dans le domaine de la santé humaine et animale.
Dans le cadre de ce travail, l’épidémiologie désigne le contrôle préventifs effectué
par les agents de santé pour notifier, éradiquer les maladies à taux de létalité aigué sur la
population. La surveillance épidémiologique a pour d’améliorer l’exploitation des données de
surveillance pour :
- déceler à temps tout évènement inhabituel et répondre rapidement aux présomptions
d’épidémie ;
- suivre de près l’impact des interventions se traduisant par exemple par une réduction de
l’incidence, de la propagation de la maladie, ou de la mortalité ;
- faciliter une riposte factuelle ;
- concevoir, organiser et appliquer une politique sanitaire.
- Faciliter la circulation des données de surveillance entre les différents échelons du système
de santé et à l’intérieur de chacun de ces échelons.
- Promouvoir la participation des cliniciens au système de surveillance.

~ 8 ~
- Promouvoir la participation de la communauté à la détection des problèmes sanitaires et à
la riposte.
- Déclencher les enquêtes épidémiologiques pour la détection, l’investigation et la
notification des problèmes sanitaires, et la mise en œuvre d’interventions sanitaires
efficaces.
1.1.1.3. Vaccination
Selon l’Organisation Mondiale de la Santé (OMS), la vaccination consiste à
immuniser une personne contre une maladie infectieuse, généralement en lui administrant un
vaccin [7]. Il est établi que la vaccination permet de combattre et d’éliminer des maladies
infectieuses potentiellement mortelles et on estime qu’ainsi plus de 2 à 3 millions de décès par
an sont évités. C’est l’un des investissements les plus rentables dans le domaine de la santé.
La prévention des infections est le principal moyen qu'ont utilisé les pays
développés pour améliorer la santé maternelle et infantile. La vaccination est l'une des
techniques qui concourent à cet objectif.
En RDC, le Programme Elargi de Vaccination (PEV), créé en 1978, a pour mission
de contribuer à une meilleure survie de l'enfant en réduisant la morbidité et la mortalité
attribuables aux maladies évitables par la vaccination. Depuis 1981, les activités du PEV ont
été progressivement intégrées dans les centres de santé au point que ce jour, toutes les zones de
santé ont intégré le PEV dans leurs activités de routine.
Les maladies cibles du PEV sont : la tuberculose, la diphtérie, le tétanos néo-natal, la
coqueluche, la poliomyélite, la rougeole, la fièvre jaune, l'hépatite virale B, la méningite et
récemment l’EBOLA.
1.1.1.4. La lutte contre le paludisme en RDC
Pour lutter contre le paludisme, le programme national de lutte contre le paludisme,
le Programme National de Lutte contre le Paludisme PNLP en sigle s’investie dans la
prévention, la surveillance et la prise en charge de la maladie. Le PNLP dit que ses programmes
de lutte vise à réduire le taux de morbidité et mortalité due au paludisme au sein de la
communauté et en particulier chez les enfants de moins de cinq ans et chez les femmes
enceintes. Parmi les activités de ses programmes, le PNLP signale la distribution des
moustiquaires imprégnées d’insecticides, la formation des relais communautaires.
1.1.2. Riposte contre épidémie
Une riposte est un ensemble d’actions offensives menées pour combatte une
épidémie. Une riposte a pour finalité d’interrompre la transmission de l’épidémie dans les
structures sanitaires affectées grâce à la mise à l’échelle des mesures de contrôle de l’épidémie
efficaces et reposant sur des bases factuelles et de prévenir la propagation de la maladie dans
les zones de santés voisines à risque par le renforcement des actions de préparation et
d’intervention en cas d’épidémie. Sur la base du profil épidémiologique et des connaissances
techniques et opérationnelles, la riposte se concentre sur trois piliers majeurs :
- Les interventions immédiates de riposte à l’épidémie de maladie;
- Une coordination et collaboration renforcées;

~ 9 ~
- L’intensification de la mobilisation des ressources humaines et financières.
- La sensibilisation de la population par de relais communautaires.
1.2 CADRE THEORIQUE
1.2.1 PROCESSUS DE DÉVELOPPEMENT LOGICIEL
KAZI A. souligne l’existence de méthodes de développement de manière
pléthorique, rend le choix parmi elles difficile [8]. Dans le cadre de conception et
développement des applications informatique, nous pouvons citer à ce propos les méthodes de
développement objet suivantes : 2TUP, RUP, XP, AUP, SCRUM, MERISE II, AXIAL,... tout
dépend des objectifs et de la vision du projet et surtout de l’agilité de l’équipé. Par ailleurs,
Pascal Roques & Franck Vallée appellent l’ensemble d’étapes et de sous étapes de réalisation
d’une application informatique comme étant un « processus de développement » qui définit une
séquence d’étapes, en partie ordonnées, qui concourent à l’obtention d’un système logiciel ou
à l’évolution d’un système existant [9]. L’objet d’un processus de développement est de
produire des logiciels de qualité qui répondent aux besoins de leurs utilisateurs dans des temps
et des coûts prévisibles.
Le Processus Unifié (PU ou UP en anglais pour Unified Process) est une méthode
de développement logiciel construite sur UML ; elle est itérative et incrémentale, centrée sur
l’architecture, conduite par les cas d’utilisation et pilotée par les risques.
 itérative et incrémentale : la méthode est itérative dans le sens où elle propose de
faire des itérations lors de ses différentes phases, ceci garantit que le modèle construit
à chaque phase ou étape soit affiné et amélioré. Chaque itération peut servir aussi à
ajouter de nouveaux incréments.
 conduite par les cas d’utilisation : elle est orientée utilisateur pour répondre aux
besoins de celui-ci.
 centrée sur l’architecture : les modèles définit tout au long du processus de
développement vont contribuer à établir une architecture cohérente et solide.
 pilotée par les risques : en définissant des priorités pour chaque fonctionnalité, on
peut minimiser les risques d’échec du projet.
La gestion d’un tel processus est organisée d’après les 4 phases suivantes :
1. Préetude(Inception) : c’est ici qu’on évalue la valeur ajoutée du développement et
la capacité technique à le réaliser (étude de faisabilité).
2. Elaboration : sert à confirmer l’adéquation du système aux besoins des utilisateurs
et à livrer l’architecture de base.
3. Construction : sert à livrer progressivement toutes les fonctions du système.
4. Transition : déployer le système sur des sites opérationnels.
1.2.1.1. LE PROCESSUS 2TUP
2TUP, signifie « 2 Track Unified Process ». C’est un processus UP qui répond aux
caractéristiques que nous venons de citer. Le processus 2TUP apporte une réponse aux

~ 10 ~
contraintes de changement continuel imposées aux systèmes d’information de l’entreprise. En
ce sens, il renforce le contrôle sur les capacités d’évolution et de correction de tels systèmes. «
2 Track» signifie littéralement que le processus suit deux chemins. Il s’agit des « chemins
fonctionnels » et « d’architecture technique », qui correspondent aux deux axes de changement
imposés au système d’information.
Figure 1—Système d'information soumis à deux types de contraintes
Source : Roques P (UML en action)
Ainsi pour schématiser cette méthode, généralement le modèle dit en Y est
recommandé pour démontrer dans le figure suivante :
Figure 2—Modèle en Y
Source : Roques P (UML en action)
1.2.1.1.1. La branche gauche (fonctionnelle) comporte :
 La capture des besoins fonctionnels, qui produit un modèle des besoins focalisé
sur le métier des utilisateurs. Elle qualifie au plus tôt le risque de produire un système inadapté
aux utilisateurs. De son côté, la maîtrise d’œuvre consolide les spécifications et en vérifie la
cohérence et l’exhaustivité l’analyse, qui consiste à étudier précisément la spécification
fonctionnelle de manière à obtenir une idée de ce que va réaliser le système en termes de métier.
Les résultats de l’analyse ne dépendent d’aucune technologie particulière [4].

~ 11 ~
1.2.1.1.2 La branche droite (architecture technique) comporte :
 La capture des besoins techniques, qui recense toutes les contraintes et les choix
dimensionnant la conception du système. Les outils et les matériels sélectionnés ainsi que la
prise en compte de contraintes d’intégration avec l’existant conditionnent généralement des
prérequis d’architecture technique ;
 La conception générique, qui définit ensuite les composants nécessaires à la
construction de l’architecture technique. Cette conception est la moins dépendante possible des
aspects fonctionnels. Elle a pour objectif d’uniformiser et de réutiliser les mêmes mécanismes
pour tout un système. L’architecture technique construit le squelette du système informatique
et écarte la plupart des risques de niveau technique. L’importance de sa réussite est telle qu’il
est conseillé de réaliser un prototype pour assurer sa validité.
1.2.1.1.3 La branche du milieu comporte :
 La conception préliminaire, qui représente une étape délicate, car elle intègre le
modèle d’analyse dans l’architecture technique de manière à tracer la cartographie des
composants du système à développer ;
 La conception détaillée, qui étudie ensuite comment réaliser chaque composant
;
 l’étape de codage, qui produit ces composants et teste au fur et à mesure les
unités de code réalisées ;
 L’étape de recette, qui consiste enfin à valider les fonctions du système
développé.
1.2.1.2. Un processus de modélisation avec UML
Il nous paraît difficile d’envisager le processus 2TUP sans recourir à UML comme
support. Certes, les concepts présentés jusqu’à présent ne sont pas spécifiquement liés à une
notation particulière. Nous avons cependant omis de préciser le rôle central et fondamental de
la modélisation objet tout au long du développement d’une solution logicielle.
Le recours à la modélisation est depuis longtemps une pratique indispensable au
développement logiciel, car un modèle est prévu pour arriver à anticiper les résultats du codage.
Un modèle est en effet une représentation abstraite d’un système destiné à en faciliter l’étude
et à le documenter [8]. C’est un outil majeur de communication entre les différents intervenants
au sein d’un projet. Chaque membre de l’équipe, depuis l’utilisateur jusqu’au développeur,
utilise et enrichit le modèle différemment. En outre, les systèmes devenant de plus en plus
complexes, leur compréhension et leur maîtrise globale dépassent les capacités d’un seul
individu. La construction d’un modèle abstrait aide à y remédier. Le modèle présente
notamment l’atout de faciliter la traçabilité du système, à savoir la possibilité de partir d’un de
ses éléments et de suivre ses interactions et liens avec d’autres parties du modèle. Certains
modèles sont mentaux, d'autres sont codifiés. La réalisation de ce processus requiert l'utilisation
de techniques de modélisation appropriées, dont le but est de documenter, de prévoir, d’étudier,
de collecter ou d’estimer les informations d’un système. Associé au processus de

~ 12 ~
développement, un modèle représente la vue sur une spécification ou sur une solution de
système, pris à un niveau de détail pertinent pour exprimer ou concevoir la cible de l’étape en
cours.
Associé au processus de développement, un modèle représente l’ensemble des vues
sur une expression de besoins ou sur une solution technique. Pris à un niveau de détail pertinent,
il décrit ou conçoit la cible de l’étape en cours. Le modèle sert donc des objectifs différents
suivant l’activité de développement et sera construit avec des points de vue de plus en plus
détaillés :
Dans les activités de spécification des exigences, il convient premièrement de
considérer le système comme une boîte noire à part entière afin d’étudier sa place dans le
système métier plus global qu’est l’entreprise. On développe pour cela un modèle de niveau
contexte,
Dans les activités d’analyse, le modèle commence à représenter le système vu de
l’intérieur. Il se compose d’objets représentant une abstraction des concepts manipulés par les
utilisateurs. Le modèle comprend par ailleurs deux points de vue, la structure statique et le
comportement dynamique. Il s’agit de deux perspectives différentes qui aident à compléter la
compréhension du système à développer.
Dans les activités de conception, le modèle correspond aux concepts informatiques qui
sont utilisés par les outils, les langages ou les plates-formes de développement. Le modèle sert
ici à étudier, documenter, communiquer et anticiper une solution. Il est en effet toujours plus
rentable de découvrir une erreur de conception sur un modèle, que de la découvrir au bout de
milliers de lignes codées sans méthode. Pour la conception du déploiement enfin, le modèle
représente également les matériels et les logiciels à interconnecter.
en dernier lieu, l’utilisation extensive de modèles dans les dernières phases de
conception, ainsi que le caractère systématique qui s’esquisse dans le passage d’UML au code.
Dans ce cadre, le modèle devient directement exécutable, de sorte que la dernière étape
fastidieuse du codage devienne presque inutile.
1.2.1.2.1. PRESENTATION SOMMAIRE D’UNIFIED MODELING LANGUAGE
Dans Rocque [8, p. 4] définit UML 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.
UML unifie à la fois les notations et les concepts orientés objet. Il ne s’agit pas
d’une simple notation, mais les concepts transmis par un diagramme ont une sémantique précise
et sont porteurs de sens au même titre que les mots d’un langage. UML a une dimension
symbolique et ouvre une nouvelle voie d’échange de visions systémiques précises. Ce langage
est certes issu du développement logiciel mais pourrait être appliqué à toute science fondée sur
la description d’un système. Dans l’immédiat, UML intéresse fortement les spécialistes de
l’ingénierie système.
UML 2 s’articule autour de treize types de diagrammes [8], chacun d’eux étant
dédié à la représentation des concepts particuliers d’un système logiciel. Ces types de
diagrammes sont répartis en deux grands groupes :

~ 13 ~
• Six diagrammes structurels :
- Diagramme de classes : Il montre les briques de base statiques : classes, associations,
interfaces, attributs, opérations, généralisations, etc.
- Diagramme d’objets : Il montre les instances des éléments structurels et leurs liens à
l’exécution.
- Diagramme de packages : Il montre l’organisation logique du modèle et les relations entre
packages.
- Diagramme de structure composite : Il montre l’organisation interne d’un élément statique
complexe.
- Diagramme de composants : Il montre des structures complexes, avec leurs interfaces
fournies et requises.
- Diagramme de déploiement : Il montre le déploiement physique des « artefacts » sur les
ressources matérielles.
• Sept diagrammes comportementaux :
- Diagramme de cas d’utilisation : Il montre les interactions fonctionnelles entre les acteurs
et le système à l’étude.
- Diagramme de vue d’ensemble des interactions : Il fusionne les diagrammes d’activité et
de séquence pour combiner des fragments d’interaction avec des décisions et des flots.
- Diagramme de séquence : Il montre la séquence verticale des messages passés entre objets
au sein d’une interaction.
- Diagramme de communication : Il montre la communication entre objets dans le plan au
sein d’une interaction.
- Diagramme de temps – Il fusionne les diagrammes d’états et de séquence pour montrer
l’évolution de l’état d’un objet au cours du temps.
- Diagramme d’activité : Il montre l’enchaînement des actions et décisions au sein d’une
activité.
- Diagramme d’états : Il montre les différents états et transitions possibles des objets d’une
classe.
Voici une présentation rapide des différents diagrammes UML qui peuvent être
utilisés tout au long d’un projet :
 Le diagramme des cas d’utilisation
Il montre les interactions fonctionnelles entre les acteurs et le système à l’étude. Il
représente également la structure des fonctionnalités nécessaires aux utilisateurs du système. Il
est normalement utilisé lors des étapes de capture des besoins fonctionnels et techniques. On y
trouve les concepts suivants :
Acteur : Un acteur représente un rôle joué par une entité externe (utilisateur humain,
dispositif matériel ou autre système) qui interagit directement avec le système étudié [9]. Un
acteur peut consulter et/ou modifier directement l’état du système, en émettant et/ou en recevant
des messages susceptibles d’être porteurs de données. Certains acteurs sont principaux :
agissent directement sur le système et d’autres secondaires subissent l’action d’un cas
d’utilisation déjà déclenché. Ils peuvent être soit consultés par le système à développer, soit

~ 14 ~
récepteur d’informations de la part du système. Cela est généralement un autre système
(logiciel) avec lequel le nôtre doit échanger des informations.
 Cas d’utilisation : Un cas d’utilisation (use case) représente un ensemble de séquences
d’actions qui sont réalisées par le système et qui produisent un résultat observable intéressant
pour un acteur particulier. Un cas d’utilisation modélise un service rendu par le système. Il
exprime les interactions acteurs/système et apporte une valeur ajoutée « notable » à l’acteur
concerné. Le Cas d’utilisation n’est rien d’autre que “l’usage que des acteurs font du système”.
Un acteur est entité extérieure qui interagit avec le système.
 Afin d’optimiser la formalisation des besoins en ayant recours notamment à la
réutilisation de cas d’utilisation, trois relations peuvent être décrites entre cas d’utilisation : une
relation d’inclusion (« include ») une relation obligatoire si elle existe entre deux dans
d’utilisation, une relation d’extension (« extend ») optionnelle et une relation de
généralisation.
 Le diagramme d’activités :
Il représente les règles d’enchaînement des activités et actions dans le système. Il
peut être assimilé comme un algorithme mais schématisé. Le diagramme de packages : présent
depuis UML 2.0, ce diagramme modélise des catégories cohérentes entre elles, pour un souci
de partage des rôles. Correspond à l’étape de modélisation des différents scénarios d’un cas
d’utilisation.
Le diagramme d'activité présente une vision macroscopique et temporelle du
système modélisé : Action, Action structure, Historique, Fusion, Décision, "Join" et "fork".
 Nœud Action (action) : Un nœud action correspond à un traitement qui modifie l’état
du système. Cette action peut être appréhendée soit à un niveau élémentaire proche d’une
instruction en termes de programmation soit à un niveau plus global correspondant à une ou
plusieurs opérations.
 Activité (activity) : Une activité définit un comportement décrit par un séquencement
organisé d'unités dont les éléments simples sont les actions [9]. Le flot d'exécution est modélisé
par des nœuds reliés par des arcs (transitions). Le flot de contrôle reste dans l'activité jusqu'à ce
que les traitements soient terminés. Une activité est un comportement (behavior en anglais) et
à ce titre peut être associée à des paramètres.
 Transition : Le passage d'une activité vers une autre est matérialisé par une transition.
Graphiquement les transitions sont représentées par des flèches en traits pleins qui connectent
les activités entre elles. Elles sont déclenchées dès que l'activité source est terminée et
provoquent automatiquement et immédiatement le début de la prochaine activité à déclencher
(l'activité cible). Contrairement aux activités, les transitions sont franchies de manière
atomique, en principe sans durée perceptible. Les transitions spécifient l'enchaînement des
traitements et définissent le flot de contrôle.
 Nœud de bifurcation (fourche) : Un nœud de bifurcation (fourche) permet à partir
d’un flot unique entrant de créer plusieurs flots concurrents en sortie de la barre de
synchronisation.

~ 15 ~
Nœud de jonction (synchronisation) : Un nœud de jonction (synchronisation)
permet, à partir de plusieurs flots concurrents en entrée de la synchronisation, de produire un
flot unique sortant. Le nœud de jonction est le symétrique du nœud de bifurcation
 Nœud de test-décision : Un nœud de test-décision permet de faire un choix entre
plusieurs flots sortants en fonction des conditions de garde de chaque flot. Un nœud de test-
décision n’a qu’un seul flot en entrée. On peut aussi utiliser seulement deux flots de sortie : le
premier correspondant à la condition vérifiée et l’autre traitant le cas sinon.
 Nœud de fusion-test
Un nœud de fusion-test permet d’avoir plusieurs flots entrants possibles et un seul flot
sortant. Le flot sortant est donc exécuté dès qu’un des flots entrants est activé.
 Le diagramme de classes
Il est sûrement l’un des diagrammes les plus importants dans un développement
orienté objet. Sur la branche fonctionnelle, ce diagramme est prévu pour développer la structure
des entités manipulées par les utilisateurs. Dans ce diagramme, deux concepts clés : classe et
objet
 Classe : Regroupe des objets de même nature (mêmes attributs + mêmes
opérations).
 Objet : un objet est une instance d’une classe. Un objet est une instance (ou
occurrence) d’une classe. (Objet = Etat + Comportement + Identité)
 Attribut : Un attribut est une caractéristique partagée par tous les objets de la
classe. Il associe à chaque objet une valeur appartenant à un type simple (int, bool),
primitif (Date) ou énuméré.
 Opération : Une Opération est un service qui peut être demandé à tout objet de
la classe. Donc un comportement commun à tous les objets de la classe.
 Une association : représente une relation sémantique durable entre deux classes.
Exemple : une personne peut posséder des voitures. La relation possède est une
association entre les classes Personne et Voiture.
 Multiplicité : Elle spécifie le nombre d’objets qui peuvent participer à une
relation avec un objet de l’autre classe dans le cadre d’une association.
 Agrégation et Composition
Une agrégation est un cas particulier d’association non symétrique exprimant une
relation de contenance.
Une composition est une agrégation plus forte impliquant que :
 un élément ne peut appartenir qu’à un seul agrégat composite (agrégation non partagée);
 la destruction de l’agrégat composite entraîne la destruction de tous ses éléments (le
composite est responsable du cycle de vie des parties).

~ 16 ~
 Le diagramme de séquence
Le diagramme de séquence est une représentation graphique de chronologie des
échanges de messages entre les acteurs et le système. Le temps « ligne de vie » est représenté
verticalement et les échanges de messages horizontalement. Les diagrammes de séquences
permettent de décrire COMMENT les éléments du système interagissent entre eux et avec les
acteurs :
 Les objets au cœur d’un système interagissent en s’échangent des messages.
 Les acteurs interagissent avec le système au moyen d’IHM (Interfaces Homme-
Machine).
Les concepts clés sont :
 Ligne de vie : Une ligne de vie représente l’ensemble des opérations exécutées par un
objet. Un message reçu par un objet déclenche l’exécution d’une opération. Le retour
d’information peut être implicite (cas général) ou explicite à l’aide d’un message de retour.
 Type de Message : dans un diagramme de séquence, quatre types de messages peuvent
être distingués :
a) create : Message dont on spécifie la création d’un objet.
b) destroy : message dont on détruit un objet existant.
c) call : Bloque l'expéditeur jusqu'à prise en compte du message par le destinataire.
Le flot de contrôle passe de l'émetteur au récepteur (l'émetteur devient passif et le récepteur
actif) à la prise en compte du message.
d) Send : Le message envoyé peut être pris en compte par le récepteur à tout
moment sans bloquer l’expéditeur.
CONCLUSION PARTIELLE
Dans ce chapitre, il est question de donner une brève description de la démarche
2TUP et bien sûr une brève définition les différents concepts (termes) utilisés dans ce travail et
sur le champ d’application. Après cette présentation et afin d’éclairer le lecteur sur le principal
processus de développement que nous allons utiliser dans l’approche UP, nous donnons ci-
dessous dans le chapitre suivant le cadre de référence ou présentation de l’organisation.

~ 17 ~
DEUXIEME CHAPITRE : CADRE DE REFERENCE :
PRESENTATION DE L’ORGANISATION
2.1. Présentation de la Division Provinciale de la Santé du Haut Katanga
2.1.1. Aperçu historique
La Division Provinciale de la Santé (DPS) du Haut Katanga fut créée par l’arrête
ministériel N°1250 /CAB/MIN/SP//CJ/OMK/2012 du 3 novembre 2012 portant réorganisation
des divisions provinciales de la sante en République Démocratique du Congo. Vu l’étendue
territoriale de la province, les longues distances séparant le siège des zones de santé de la DPS,
la précarité des réseaux de communication et les faibles performances de la Division provinciale
actuelle dans l’encadrement des Zones de santé en charge de l’offre de soins de santé primaires
de qualité aux populations.
La Division Provinciale de la Santé du Haut Katanga à pour siège : Lubumbashi est
Composée de 27 zones de santé suivantes : Kamalondo, Kampemba, Tshamilemba, Katuba,
Kisanga, Kenya, Kowe (FAC), Lubumbashi, Mumbunda, Vangu (FAC), Rwashi, Kambove,
Kapolowe, KilelaBalanda, Kikula, Likasi, Mitwaba, MufungaSampwe, Panda, Kasenga,
Lukafu, Kafubu, Kipushi, Kilwa, Pweto, Sakania
2.1.2. Situation Géographique
La division provinciale de la Santé du Haut Katanga est située dans la partie Est de la commune
de Lubumbashi .Il est limité au nord par l'avenue Mamayemo, au Sud par l'avenue des Ecoles,
à l'Est par le Lycée Wema et à l'Ouest par l'avenue Likasi.
Figure 3—Localisation du bâtiment de la DPS Haut Katanga à Lubumbashi
Source : prise d’écran Google Maps

~ 18 ~
2.1.3. Mission
La Division Provinciale de la Santé fait partie intégrante du système national de
santé. Elle constitue un service technique de la Province qui a notamment pour mandat :
 l’organisation et la promotion des soins de santé primaires ;
 l’application et le contrôle de la législation médicale et pharmaceutique ;
 la planification provinciale ;
 l’organisation des services d’hygiène et de prophylaxie provinciale ;
 l’organisation de la médecine curative, des laboratoires médicaux et des
services pharmaceutiques.
2.1.4. Structure organisationnelle
Au niveau national, le système de santé de la RDC est organisé en pyramide à trois
niveaux : le niveau périphérique ou opérationnel représenté par la zone de santé, le niveau
intermédiaire d’appui technique représenté par la division provinciale de la santé et le niveau
central d’appui stratégique.
a) Le niveau central :
Le cabinet du Ministre de la Santé Publique, le Secrétariat Général à la Santé
Publique, 13 Directions centrales (dont la 4è est chargée de la lutte contre la maladie), ainsi que
52 programmes spécialisés offrent un appui stratégique et normatif aux provinces et aux ZS.
Parmi les 52 programmes, on peut citer : le Programme de Lutte contre le
Paludisme, le Programme de Lutte contre la Trypanosomiase, le Programme de Lutte contre la
Lèpre, le Programme de Lutte contre l’Onchocercose, le Programme de Lutte contre la
Tuberculose, le Programme de Lutte contre le SIDA, le Programme de Lutte contre la
Bilharziose, le Programme Élargi de Vaccination (PEV) et le Programme National de la
Nutrition…
Dans le cadre de cet appui et pour la réalisation de sa mission, le Ministère de la
Santé entretient un partenariat actif et mutuellement avantageux avec plusieurs partenaires dont
des agences du système des Nations Unies, des organismes de coopération bi et multilatérale,
des ONGs internationales et nationales, des organisations à assise communautaire, et les
réseaux confessionnels.
Dans le cadre de ce partenariat agissant, les principaux problèmes de santé du pays
sont discutés, les mesures de lutte et les principes directeurs des interventions sont définis, les
urgences et les priorités sont arrêtées, et l’évaluation de l’action est faite.
Le concept de ‘ Secteur de la Santé ‘ désigne l’ensemble des acteurs de la santé
dans le cadre de ce large partenariat, travaillant aux côtés du Ministère de la Santé et sous sa
houlette pour atteindre des objectifs fixés par le pays.
b) Le niveau intermédiaire :
Il a un rôle technique d’appui aux ZS. Chaque Province dispose d’une Division
Provinciale de la Santé. Celle-ci est dirigée par un Chef des Directions du niveau National.

~ 19 ~
Chaque Province a un Hôpital et un Laboratoire Provinciaux qui fonctionnent sous l’autorité
du Chef de Division Provincial de la Santé.
La politique de santé de la province est sous la charge du Ministre provincial de la
Santé. Toutefois, le gouvernement provincial collabore étroitement avec le gouvernement
central dans ce domaine, afin d’assurer la diffusion et la mise en œuvre des normes et directives
édictées au niveau central.
L’inspection des ZS ainsi que l’appui technique et programmatique à leur apporter
sont du domaine de l’équipe cadre provinciale de la santé (ECPS) que coordonne le Médecin
Inspecteur Provincial (MIP) au sein de la Division provinciale de la santé (DPS). La DPS
compte à ce jour 13 Bureaux dont un (le 4ème Bureau) s’occupe de coordonner la lutte contre
la maladie dans la province. A ce niveau existe également le Bureau provincial de coordination
de lutte contre le VIH et le SIDA (le BPC/SIDA), et les bureaux de coordination des autres
programmes de lutte contre la maladie (Tuberculose, Santé de la reproduction, Sécurité
transfusionnelle, Paludisme, etc). Certaines provinces sont subdivisées en Districts Sanitaires
qui constituent les relais de la Division Provinciale.
c) Le niveau périphérique
C'est le niveau opérationnel qui est constitué par la zone de santé qui comprend un
réseau des Centres de Santé et un Hôpital général de référence (HGR). Il est dirigé par l’équipe
du Bureau Central de la Zone de Santé.
La Zone de Santé est l’unité opérationnelle de planification et de mise en œuvre de
la politique sanitaire du pays. Elle fonctionne comme une entité décentralisée autonome dotée
de ses propres organes de gestion et de son plan d’action.
Elle couvre en moyenne une population de 100.000 à 150.000 habitants en milieu
rural et 200.000 à 250.000 habitants en milieu urbain. En général, une Zone de Santé comprend
: un Hôpital Général de Référence (HGR), des Centres de Santé de Référence (CSR) structures
facultatives, et des Centres de Santé (CS) desservant chacun une ‘ Aire de Santé ‘, ayant en
moyenne entre 5.000 et 10.000 habitants.
Le réseau de Centres de Santé offre un paquet minimum d’activités de soins de
santé primaires, tandis que les CSR et l’Hôpital Général de Référence (HGR) offrent un paquet
complémentaire d’activités.
La Zone de Santé est dirigée par une équipe-Cadre de la Zone de Santé, qui a la
charge de la planification, la mise en œuvre et le reportage des activités de santé.
Toutes les structures de soins d’une ZS sont situées dans l’une de ses AS. Ces
structures de soins sont soit d’obédience étatique, soit confessionnelle, ou encore privée lucratif
ou non. On les distingue en structures intégrées et structures non intégrées. Les structures
intégrées sont celles qui collaborent avec l’équipe-cadre de la ZS dans la mise en œuvre du
paquet d’activités préventives, curatives, et promotionnelles. Ces structures rapportent
mensuellement leurs activités au Bureau Central de la Zone de Santé. Une aire de santé est dite

~ 20 ~
opérationnelle lorsqu’elle est desservie par au moins une structure de soins intégrée, et qu’elle
réalise au moins 80 % des activités.
Toute la population de la Zone de Santé est couverte par des Centres de Santé selon
le plan de couverture sans discrimination d’origine ni d’ethnie.
d) Rôle du centre de santé dans la zone de santé
Le Centre de Santé (CS) est le niveau de la zone de santé où se fait le premier
contact de la population avec le service de Santé quel que soit l’origine où l’ethnie. Sa
spécificité est être le point d’interaction entre le service de Santé et la communauté. Il offre de
façon intégrée des Soins Curatifs, Préventifs et Promotionnels selon les modalités définies par
les Soins de Santé Primaires (SSP), organisés en Paquet Minimum d’Activités (PMA).
Le CS offre aussi des services complémentaires à ceux offerts par l’hôpital de
référence où les services sont nécessairement de compétence et de plateau technique différents
de ceux du Centre de Santé. Cette répartition des tâches entre le CS et l’hôpital doit être telle
que chaque échelon remplisse son rôle en fonction de son propre paquet d’activités. Le Système
de référence et de contre-référence entre le CS et l’hôpital doit donc fonctionner de telle façon
que, quel que soit le niveau du Système où elle se trouve, la personne soit référée à l’unité du
Système qui est la plus adaptée à son problème de Santé actuel.
En matière de suivi et évaluation, un système national d’information sanitaire
intégré permet de suivre les progrès réalisés en routine, d’autres activités telles que les enquêtes
tant aux niveaux communautaires que des services, la surveillance épidémiologique et d’autres
études permettent de renseigner le niveau de prise en charge.
Figure 4—Pyramide sanitaire du Ministère de la Santé
Source : Cartographie des systèmes d’approvisionnement et de distribution des médicaments et autres produits de santé en
RDC, Ministère de la Santé, Secrétariat Général à la Santé, Programme National D'approvisionnement en Médicament,
OMS Décembre 2019

~ 21 ~
Figure 5—Organigramme de la Division Provinciale du Haut Katanga
Source : Bureau Ressources Humaines DPS Haut Katanga, Mardi 18 février 2020 à 15h45

~ 22 ~
TROISIEME CHAPITRE : APPLICATION DE LA
METHODE 2TUP DANS LA CONCEPTION DE JANGOSOFT
3.0. Introduction
L’application de la démarche 2TUP oblige le respect strict des étapes du cycle de
vie logiciel incrémental et itératif. Ainsi nous allons dans ce chapitre premièrement faire l’étude
préliminaire c’est-à-dire identifier les besoins fonctionnels, délimiter le système ainsi qu’à
l’organisation de cas d’utilisation. Il sera également question de construire une première
ébauche de classes participantes liées à l’analyse de besoins. Le développement dynamique sera
au rendez-vous pour comprendre les interactions entre des acteurs du système. Enfin, nous
aboutir cette étape par la conception détaillée de notre solution.
3.1. Etude préliminaire
L’étude préliminaire (ou Préetude) est la toute première étape du processus 2TUP.
Elle consiste à effectuer un premier repérage des besoins fonctionnels et opérationnels, en
utilisant principalement le texte, ou diagrammes très simples. Elle prépare les activités plus
formelles de capture des besoins fonctionnels et de capture techniques.
3.1.1. Présentation du Projet à réaliser
Le projet JANGOSOFT a pour finalité de concevoir et développer un logiciel
client-serveur qui doit centraliser les données sanitaires et gérer l’évolution épidémiologique
dans la ville de Lubumbashi tout en donnant la possibilité aux décideurs de préparer la riposte.
Et ceci dans chaque structure sanitaire du bas au sommet. Il doit permettre de suivre en temps
réel la prise en charges des cas, l’appui logistique et financier dans chaque structure sanitaire.
3.1.2. Recueil des besoins fonctionnels
Nous avons effectué plusieurs recherches pour identifier au mieux les besoins des
utilisateurs afin de répondre aux attentes de ces derniers. Nous sommes allés chercher les
informations au sein de la Division Provinciale de la Santé (DPS), des différends Hôpitaux
généraux de référence (HGR). Cette phase correspond à une recherche sur le terrain pour bien
définir le cadre de notre système. Nous nous sommes aussi procuré quelques documents, qui
expliquent le mode de fonctionnement du Système National d’Information Sanitaire (SNIS)
ainsi que pour le suivi épidémiologique, et ça nous a permis d’établir le cahier des charges
préliminaire suivant :
Pour la ville de Lubumbashi seule, la Division provinciale de la santé encadre 11
Zone de Santé (KAMPEMBA, RUASHI, KAMALONDO, KENYA, Zone de Santé KATUBA,
LUBUMBASHI, MIMBUNDA, Zone de Santé TSHAMILEMBA, Zone de Santé KISANGA,
KOWE et Zone de Santé VANGU), dont chacune est structurée en :
- Hôpital Général de Référence (HGR),
- Airs de santé,
- Centre de santé de Référence,

~ 23 ~
- Centre de santés,
- Poste de santé,… Selon le plan sanitaire national, chaque structure doit notifier les cas
d’épidémies de son ressort et en faire rapport à sa hiérarchie.
Par ailleurs, chaque zone de santé contient un Hôpital Général de référence dirigé par un
Médecin Chef de Zone de Santé. Le circuit de transmission de rapports épidémiologique est le
suivant :
Figure 6—Circuit de circulation des Informations Epidémiologiques
Chaque structure doit notifier les cas à sa hiérarchie jusqu’au partenaire sanitaire
qui doivent appuyer les structures les plus affectées afin de sauver des vies humaines.
Chaque Hôpital Général de Référence doit compiler les cas de sa juridiction,
ressortir le taux de prévalences, la promptitude, la complétude ainsi que les causes de cette
épidémie.
Pour chaque pathologie sous surveillance, les cas sont notifiés par tranche d’page
(0 < 5 ans, > 5 ans), y compris pour le cas de décès. Le rapport épidémiologique est
hebdomadaire. À la 53 ième semaine, la division de santé doit faire les statistiques périodiques
pour chaque pathologie, Zone de santé et tranche d’âge.
Chaque Zone de santé délègue un agent chargé de suivi épidémiologie pour déposer
le rapport épidémiologique, exposer les problèmes liés à l’épidémiologie et surtout solliciter un
partenaire capable d’appuyer financièrement et logistiquement l’ensemble des structures de la
Zone Santé. Et pour la notification, certaines pathologies sont à notification immédiate et
d’autres hebdomadaire voir trimestriel.
La Division Provinciale de Santé (DPS) dispose d’une cellule technique chargé de
la récolte des données de santé, d’analyser et de planifier la reposte des épidémies ou de
proposer des appuis logistiques aux différentes structures touchées.
3.1.3. Identification des acteurs
Nous allons maintenant énumérer les acteurs susceptibles d’interagir avec le
système, mais d’abord nous donnons une définition de ce que c’est un acteur. Définition : un
acteur représente l'abstraction d'un rôle joué par des entités externes (utilisateur, dispositif
matériel ou autre système) qui interagissent directement avec le système étudié.
Les acteurs les plus importants pour le système de suivi épidémiologique sont :
1. Infirmier traitant (IT) : Un infirmier Traitant peut créer une notification d’épidémie,
consulter l’évolution de cas d’épidémie dans l’air de santé ou centre de santé de son
ressort.

~ 24 ~
2. Médecin chef de Zone de Santé (MCZ) : le Médecin Chef de Zone de santé peut
consulter les notifications, compiler les cas, déclarer une épidémie.
3. DATA MANNANGER : un Data manager réceptionne les notifications de cas
d’épidémie de la province, le compile et transmet le rapport à la hiérarchie.
4. PARTERNAIRE : un partenaire de santé peut consulter les données épidémiologiques,
localiser une structure la plus touchée.
5. Chef de division : un chef de division crée une pathologie et la déclare sous surveillance
selon ses caractéristiques.
6. Administrateur : un administrateur crée de compte utilisateur et l’attache à un groupe
d’utilisateur donné.
3.1.4. Identification des messages
Pour améliorer le contenu informatif du modèle suivant, il est recommandé de
détailler les différents messages échangés entre le système et l’extérieur.
Par définition, un message représente la spécification d’une communication unidirectionnelle
entre les objets qui transporte de l’information avec l’intention de déclencher une activité chez
le récepteur [9].
Le système reçoit les messages suivants :
 Déclaration d’une épidémie.
 Les créations, modifications, suppressions de la liste de pathologie sous surveillance.
 Les créations, modifications, du rapport de notifications d’épidémies
 Création d’une cause d’épidémie
 Création, modification/suppression de pathologies à notification hebdomadaire ou
trimestrielle
 Transmission rapport d’épidémie à la hiérarchie.
 Consultation de données épidémiologiques.
 Ajout / modification / suppression d’une zone de santé, Airs de santé ou centre de santé.
 La compilation des données épidémiologiques
 Les créations, modifications, suppressions de profils utilisateurs.
 Les créations, modifications de rapports épidémiologiques
 Création, édition d’un plan de riposte d’épidémie.
Le système émet les messages suivants :
 Liste de Zone de santé de Référence
 Liste de structures sanitaires par Zone de santé
 Liste des Ais de santé par Zone de Santé
 Liste de pathologies sous surveillance
 les pathologies à notification immédiate
 les pathologies à notification hebdomadaire
 les pathologies à notification trimestrielle

~ 25 ~
 Taux de prévalence par pathologie
 Taux de morbidité
 Taux de promptitude par structure
 Tranche d’âge la plus touché/pathologie/structure sanitaire
 Taux de complétude par semaine
 Evolution de cas par pathologie/semaine/structure
 Nombre de cas par pathologie/période
 Nombre des Airs de santé de la ville
 Plan de riposte d’une épidémie
 Liste de causes d’épidémie créées
 Liste de comptes utilisateurs
3.1.5. Modélisation du contexte
A partir des informations obtenues lors des deux précédentes étapes, nous allons
modéliser le contexte de notre application. Ceci va nous permettre dans un premier temps, de
définir le rôle de chaque acteur dans le système :
Tableau 1—Modélisation du contexte
Utilisateurs finaux Description des Besoins fonctionnels
Infirmier traitant
L’application doit permettre à l’Infirmier Traitant de :
 S’authentifier
 Créer une notification d’épidémie
 Créer une cause
 Transmettre le rapport à la hiérarchie
Médecin CZS
L’application doit permettre au Médecin Chef de Zone de :
 Consulter le rapport de sa Zone de Santé
 Compiler les cas
 Transmettre le rapport à la division de santé
 Déclarer épidémie
 Créer un plan de riposte d’épidémie
Data Manager
L’application doit permettre au Data Manager de :
 Consulter le rapport de la ville
 Centraliser les données épidémiologiques
 Consulter le rapport par critère (HGR, période)
Partenaire
L’application doit permettre au Partenaire de santé de :
 Consulter les données épidémiologiques
 Localiser une structure
Administrateur
L’application doit permettre à l’administrateur de :
 Créer de comptes utilisateurs

~ 26 ~
 Donner des droits d’accès
Chef de Division L’application doit permettre au Chef de division de :
 Consulter les rapports épidémiologiques
 Ajout d’une pathologie dans la liste
 Supprimer une pathologie de la liste
 Ajout d’une nouvelle structure sanitaire
Source : données de terrain
3.1.5.1. Diagramme de contexte dynamique
Le diagramme de contexte statique nous permet de définir les limites et
l’environnement du système afin de répondre aux questions qui va l’utiliser ou interagir avec
lui ? Qu’est ce qui sort de son cadre ? Le système doit fournir des services à son environnement.
Par environnement, on entend les utilisateurs qui ont besoin de ce logiciel. Les différents
acteurs qui interagissent avec le système sont repris dans la figure suivante.
Figure 7—Diagramme de contexte statique
Source : conçu par nous-même sous l’outil Entreprise Architect 13.5
3.2. Capture des besoins fonctionnels
Dans cette partie du travail, nous allons nous découvrir les exigences fonctionnelles
de notre future application. La capture de besoins fonctionnels représente un point de vue «
fonctionnel » de l’architecture système. Par le biais des cas d’utilisation, nous serons en contact
permanent avec les acteurs du système en vue de définir les limites de celui-ci, et ainsi éviter
de trop s’éloigner des besoins réels de l’utilisateur final.
JANGOSOFT
Infirmier Traitant
Medecin CZS
Administrateur
Chef de
division
Data Manager
Partenaire
1: creerNotification()
1.1: modifierNotification()
1.2: consulterCasEpidémie()
1.3: annulerNotification()
2: liste cas notifier()
3: liste pathologie ()
4: compiler cas d'épidémie()
4.1: rechercherTauxPrevalence()
4.2: planRiposte()
4.3: rapportEpidémiologique()
5: liste pathologie()
5.1: creation listepathologie sous surveillance()
5.2: plan Riposte épidémie()
5.3: transmission rapport Epidémiologique()
5.4: rapport épidémiologique()
5.5: creation compte utilisateur()
5.6: liste compte utilisateur()
5.7: consultation données épidémiologique()
5.8: rapport épidémiologique()

~ 27 ~
Dans le cadre de la branche fonctionnelle de la démarche 2TUP, le cas d’utilisation
doit mettre en valeur les interactions métier entre les acteurs et le système. On exprimera donc
des actions effectuées dans le cadre du métier de l’utilisateur, par opposition à des
manipulations de l’application ou à des comportements techniques [9, p. 61].
3.2.1. Identification des cas d’utilisations
Un cas d’utilisation représente un ensemble de séquences d’actions réalisées par le
système, et le lien entre ces séquences d’actions est précisément l’intention fonctionnelle de
l’acteur vis-à-vis du système [8]. Un cas d’utilisation modélise un service rendu par le système.
Il exprime les interactions acteurs/système et apporte une valeur ajoutée « notable » à l’acteur
concerné [9].
L’identification des cas d’utilisation une première fois, nous donne un aperçu des
fonctionnalités futures que doit implémenter le système. Cependant, il nous faut plusieurs
itérations pour ainsi arriver à constituer des cas d’utilisation complets. D’autres cas d’utilisation
vont apparaître au fur à mesure de la description de ceux-là, et l’avancement dans le « recueil
des besoins fonctionnels ».
Pour constituer les cas d’utilisation, il faut considérer l'intention fonctionnelle de
l'acteur par rapport au système dans le cadre de l'émission ou de la réception de chaque message.
En regroupant les intentions fonctionnelles en unités cohérentes, on obtient les cas d'utilisations
[9].
Tableau 2—Tableau de cas d'utilisation
Cas d’utilisation Acteurs principaux,
Secondaires
Messages reçus/émis par les acteurs
Notifier cas Infirmier traitant
émet : création, modification, annulation d’une
notification
reçoit :
- Nombre de cas d’épidémie
- taux de prévalence
- taux de morbidité
Médecin CZS, Data
Manager
reçoit :
- rapports de structures de la Zone de
Santé
- Nombre de cas d’épidémies
- taux de prévalence
- taux de morbidité
Mettre à jour
pathologie
surveillée
Chef de division
pathologie
reçoit :
- liste de pathologie sous surveillance
- liste de pathologies à notification
immédiate
hebdomadaire
Médecin Chef de
Zone
reçoit :
- liste de pathologie sous surveillance

~ 28 ~
immédiate
hebdomadaire
Gérer données
épidémiologiques
Data Manager
émet : création, modification, annulation du
rapport d’épidémie par Zone de santé, par air
de santé.
reçoit :
- nombre de cas d’épidémies par
Pathologie
- nombre de cas par période
- évolution de cas par Zone de santé
- taux de prévalence par pathologie
- nombre de cas de décès par zone de
santé.
Partenaire, Chef de
division
reçoit : rapport évolution épidémiologique
Gérer ripostes
Médecin CZS
émet : création, modification, annulation d’un
plan de riposte, création, modification,
annulation d’une mesure sanitaire de
prévention.
reçoit :
- liste des mesures sanitaires
- plans de riposte
Chef Division,
Partenaire, Infirmier
Traitant
reçoit : liste des épidémies de la Zone de Santé
- Plan de riposte
- Mesures sanitaires de prévention
Déclarer épidémie
Médecin CZS
déclaration d’épidémie.
Reçoit :
- Liste des épidémies sous contrôle
- Liste de structures sanitaires touchées
- Nombre de cas de décès
Chef de division,
Partenaire
Reçoit : Liste des épidémies déclarées
Consulter données
épidémiologiques
Partenaire
Emet : consultation de données
épidémiologiques.
Reçoit : évolution de cas par épidémie
Data manager,
Médecin CZS
- Plan d’appui de ripostes et prévention
Gérer profil
utilisateur Administrateur
Emet : création, modification, désactivation
d’un compte utilisateur
Reçoit : liste de comptes utilisateur
Source : données de terrain
Remarque 1 : Du fait qu’elles ne rentrent pas dans le cadre de notre projet, la gestion
d’affectation des équipements et le suivi de traitement, affectation médicaments dans les zones
touchées ne sera pas considérées.

~ 29 ~
Remarque 2: Ce premier tableau n'est pas définitif, un processus de développement avec 2TUP
UML est itératif, il se peut qu'il change au fur et à mesure de l'avancement du projet.
3.2.2. Description préliminaire de cas d’utilisation
La description préliminaire est une étape importante dans la découverte de cas d’utilisation,
servant ainsi à fixer les idées sur les intentions et les actions que les utilisateurs ont a priori sur
chaque cas d’utilisation [9]. Ainsi pour les cas d’utilisation précédemment définis, nous
donnons la description préliminaire individuelle suivante :
Mettre à jour pathologie surveillée (Chef de division)
Intention : mettre à la disposition des zones de santé de la liste des pathologies sous
surveillance sur le territoire national
Action : création d’une nouvelle pathologie (nom, signe clinique), modification/ retrait d’une
pathologie existante.
Notifier cas d’épidémie (Infirmier Traitant)
Intention : annoncer les cas d’une épidémie détectés dans une structure sanitaire en vue
d’une riposte et prise en charge immédiat ;
Action : créer une nouvelle notification (nombre des cas d’épidémie, nombre de décès, taux
de prévalence, taux de morbidité), modifier ou annuler une notification existante.
Gérer données épidémiologiques (Data manager)
Intention : centraliser données des épidémies détectées dans la ville de Lubumbashi afin
d’informer les autorités et partenaires pour prendre de mesures adéquates de la riposte
Action : création d’un rapport périodique d’épidémie (HGR, pathologie, n° période, nombre de
cas enfants, nombre de cas adultes, évolution par rapport aux périodes passées)
Gérer ripostes (Médecin chef de zone de santé)
Intention : rendre de mesures sanitaires nécessaires de riposte à une épidémie sévissant dans
une zone de santé, en demandant de l’aide aux partenaires et à l’Etat congolais.
Action : créer un nouveau plan de riposte, modifier/annuler un plan de riposte
Déclarer épidémie (Médecin chef de zone de santé)
Intention : alerter les autorités et partenaires ainsi que le public d’une épidémie afin de prévenir
la contenions et se conformes aux instructions de l’Etat qui obligent chaque ZS de données
l’évolution épidémiologique
Action : créer un nouveau rapport épidémiologique périodique (hebdomadaire, mensuel,
annuel, semestriel,…), modifié / annuler un rapport épidémiologique existant.
Consulter données épidémiologiques (Partenaire)
Intention : se rendre compte de l’évolution des épidémies dans la ville en vue de prendre de
mesures nécessaires pour d’appui contre cette épidémie

~ 30 ~
Action : consulter par HGR, par période, transmettre au Médecin CZS les propositions d’appui.
Gérer profil utilisateur (Administrateur)
Intention : gérer les droits d’accès aux données afin de sécuriser ces dernières
Action : création/modification/désactivation d’un compte utilisateur.
3.2.2.1. Élaboration du diagramme des cas d’utilisation
Voici le diagramme de cas d’utilisation résultant du métier :
Figure 8 : Diagramme de cas d'utilisation système
Source : conçu par nous-même sous l’outil Entreprise Architect 13.5
3.2.2.2. Description détaillée de cas d’utilisation
Pour comprendre la réalisation de chaque cas d’utilisation, nous allons recenser
toutes les interactions de façon textuelle.
Sommaire d’identification
Titre : Notifier cas épidémiologique
But : alerter les autorités compétentes de la présence d’une épidémie dans une structure
sanitaire selon les dispositions légales et la politique de prise en charge.
Résumé : création d’une nouvelle notification, d’une nouvelle épidémie, modification ou
annulation de la notification.
Acteurs : Infirmier traitant (Principal), Médecin CZS (secondaire).
Date de création : 11/08/2019 Date de mise à jour : 20/11/2019
Version : 2.1. Responsable : Ruphin NYAMI & Pax MWANZA
Précondition
1. L’IT est authentifié
2. Au moins une pathologie sous surveillance existe
Enchainement Nominaux
JANGOSOFT
«business actor»
Intfirmier
Traitant
«business actor»
Médecin CZS
«business actor»
Chef de
division
«business actor»
Data Manager
«business actor»
PartenaireAdministrateur
Notifier cas
d'epidémie
Mettre a jour
pathologie
Gérer données
épidémiologiques
Gérer riposte
épidemies
Déclarer
épidémie
Consulter données
épidémiologiques
Gérer profil
S'authentifier
Agent Santé
«include»
«include»
«include»«include»
«extend»
«include»
«include»
«include»

~ 31 ~
Ce cas d’utilisation commence lorsque l’Infirmier Traitant demande au système de notifier un
nouveau cas d’épidémie.
Enchainement (a) : créer une nouvelle notification en détection
L’Infirmier Traitant fournit le nom de la pathologie, le nombre de cas, la tranche d’âge affectée,
le nom de la structure sanitaire et le nom de la zone de santé pour la notification qu’il veut
créer.
S’il s’agit d’une nouvelle épidémie non surveillée, l’Infirmier doit renseigner les symptômes de
la dite épidémie.
Enchainement (b) Ajouter les pathologies
Pour une notification, l’Infirmier Traitant doit fournir la liste de pathologies et pour chacune,
le nombre de cas détectés.
Enchainement (c) Signaler Décès
Pour chaque pathologie, l’Infirmier Traitant doit signaler le nombre de décès et calculer le
taux de morbidité et de prévelance.
Si la pathologie ne fait pas partie de la liste de pathologies surveillées, alors exécuter :
[Exception1 : pathologie non surveillée]
Si une information obligatoire est absente alors exécuter
[Exception 2 : Saisie non valide]
Enchaînement (d) Valider une notification en construction
L’Infirmier Traitant valide une notification en construction : il doit alors préciser le n° de la
semaine, l’heure et la date d’établissement. Le système édite alors l’état de notification.
Enchaînement alternatifs
Enchaînement (e) Modifier une Notification d’épidémie en cours
L’Infirmier Traitant enlève une maladie et ses cas, ou attache nouvelle maladie à la notification
L’Infirmier Traitant modifie également à son gré le nombre de cas (inférieur à 5 ans, supérieur
à 5 ans) et le nombre de décès
Enchaînement (f) Modifier une notification validée
L’Infirmier Traitant peut encore modifier une notification au minimum 8 heure avant sa
compilation au niveau de la Zone de Santé. Toute modification d’une Notification validée
entraînant son invalidation, il doit donc ensuite la valider à nouveau en précisant le n° de la
semaine, les noms de pathologies, nombre de cas détectés, nom de la structure sanitaire.
Enchaînement (h) Annuler une mission
L’Infirmier Traitant annule une notification non transmise ou une mission transmise au
minimum 8 heure avant la compilation au niveau de HGR.
Post conditions :
1. une nouvelle notification a été créée avec succès.
2. la liste de pathologies notifiées existe dans la base.
Besoins d’IHM :
❍ Pour lister les pathologies sous surveillance
Afin d’établir la notification de sa structure sanitaire, l’infirmier traitant doit pouvoir
répertorier les maladies sous surveillance de sa zone de santé et le modèle de présentation.
Il doit pouvoir filtrer ou ordonner cette liste suivant :
• le type de pathologie

~ 32 ~
• la tranche d’âge,
• le nombre de décès,
• le taux de prévalence,
• taux de morbidité.
• surveillée ou non
Chaque ligne de la liste représente une notification et regroupe l’ensemble des informations de
filtre.
Une couleur différente doit permettre de distinguer les maladies avec taux de prévalence élevé
de celles qui ne le sont pas.
❍ Pour consulter ou modifier une notification
L’infirmier traitant dispose d’une fiche par pathologie. Plusieurs fiches peuvent être ouvertes
simultanément.
Cette fiche récapitule :
• le nom de la pathologie notifiée,
• le n° de la semaine,
• le nombre total de cas notifiés
• le nombre de cas inférieur à 5 ans,
• le nombre de cas supérieur à 5 ans,
• l’évolution de la pathologie par rapport à la semaine passée
• le taux de prévalence,
• le taux de morbidités
Depuis cette fiche, l’infirmier traitant peut modifier le nombre de cas déjà signalé.
Contraintes non fonctionnelles :
Tableau 3—Tableau de contraintes non fonctionnelles du cas d'utilisation Notifier cas
Contrainte Descriptif
Temps de réponse L’interface de l’infirmier traitant doit réagir en l’espace de 2 secondes au
maximum
Concurrence
Les validations d’une notification doivent être signalées par un message
d’avertissement
aux autres partenaires de santé et au MCZ du ressort de la structure qui
notifie.
Fréquence Permanente
Volumétrie
Une notification représente en moyenne 1 Ko de données. Le
nombre moyen estimé de notifications par mois 4 et 52 notifications
par ans. Et ma durée de rétention est de 10 ans
Disponibilité
Le système est accessible aux infirmiers 7 jours sur 7, aux heures
d’ouverture des hôpitaux.
Confidentialité
Les infirmiers traitants sont identifiés par le système en fonction de
leur nom, de leur mot de passe et du rôle qu’ils détiennent dans la
structure sanitaire.
Intégrité Non applicable dans la mesure où les données épidémiologiques
d’une structure sanitaire ne sont accessibles qu’au seul infirmier en
modification.
Source : conçu par nous-même

~ 33 ~
Sommaire d’identification
Titre : Mettre à jour liste pathologie
But : informer toutes les Zones de santé de la liste de pathologies à surveiller et à notifier aux
autorités en d’un cas détecté.
Résumé : création d’une nouvelle pathologie, modification ou annulation de la liste de
pathologie.
Acteurs : Chef de division (Principal), Médecin CZS (secondaire).
Date de création : 01/08/2019 Date de mise à jour : 15/11/2019
Version : 2.1. Responsable : Ruphin NYAMI & Pax MWANZA
Précondition
1. Le chef de division est authentifié
2. Il existe au moins une liste de pathologie sous surveillance
Enchainement Nominaux
Ce cas d’utilisation commence lorsque le chef de division demande au système de mettre à jour
la liste d’épidémies.
Enchainement (a) : créer une nouvelle pathologie
Le chef de division fournit le nom de la pathologie, les symptômes et autres détails techniques.
S’il s’agit d’une nouvelle épidémie non surveillée, le chef de division doit préalablement
l’ajouter à la base.
Pour chaque pathologie, l’Infirmier Traitant doit signaler le nombre de décès et calculer le
taux de morbidité et de prévelance.
Si la pathologie fait déjà partie de la liste de pathologies sous surveillance, alors exécuter :
[Exception1 : DuplicataPathologie]
Si une information obligatoire est absente alors exécuter
[Exception 2 : Saisie non valide]
Enchaînement (b) Valider une pathologie en création
Le chef de division valide une pathologie en création
Enchaînement alternatifs
Enchaînement (e) Modifier une pathologie en cours
Le chef de division edite une maladie dans la liste d’épidémie, ou attache nouvelle maladie à la
liste.
Post conditions :
1. une nouvelle pathologie a été créée avec ses attributs.
2. la liste de pathologies mise à jour.
Contraintes non fonctionnelles :
Tableau 4—Tableau de contraintes non fonctionnelles du cas d'utilisation Mise à jour Pathologie
Contrainte Descriptif
Temps de réponse L’interface du chef de division doit réagir en l’espace de 2 secondes au
maximum
Concurrence
La validation d’une pathologie doit être signalée par un message
d’avertissement
aux HGR de ville de Lubumbashi.
Fréquence Rare

Conception d'un Système d'information sanitaire prévention d'alerte sur les épidémies

Conception d'un Système d'information sanitaire prévention d'alerte sur les épidémies

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Conception d'un Système d'information sanitaire prévention d'alerte sur les épidémies

Similar to Conception d'un Système d'information sanitaire prévention d'alerte sur les épidémies (18)

Conception d'un Système d'information sanitaire prévention d'alerte sur les épidémies