République Algérienne Démocratique et Populaire

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université Abderrahmane Mira - Béjaia -

Faculté des Sciences Exactes
Département d’Informatique

Mémoire de fin de cycle master 2

En vue de l’obtention du diplôme de Master Professionnel en Informatique

Option : Génie Logiciel

Conception et réalisation d’une

application web pour la gestion des
ordonnances et du stock des
médicaments à titre ambulatoire.

Réalisé par : Mlle. MEZIANI Keltoum Mlle. CHALAL Rosa

Soutenu le 21 juin 2023, Devant le jury composé de :

Président : Mr. AISSANI Sofiane (MCA)

Encadrant : Mr. ZERARGA Loutfi (MCB)
Examinatrice : Mme. YESSAD Samira Epose OUYAHIA (MCB)
Co-Encadrant : Mr. ARAB Abdelouahab (CHU)

Promotion : 2022/2023
Dédicace

“ Avec tous mes sentiments de respect, avec l’expérience de ma

reconnaissance, je dédie ma remise de diplôme et ma joie à mon
paradis, à la prunelle de mes yeux, à la source de ma joie et
mon bonheur, ma lune et le fil d’espoir qui allume mon chemin,
ma moitié : MAMAN
A celui qui m’a fait devenir une femme, ma source de vie,
d’amour et d’affectation à mon support qui était toujours à mes
côtés pour me soutenir et m’encourager : PAPA
A mon cher frère Billal et mes deux petites soeurs Imene et Mira
A tous les membres de ma famille, mes amis et mes collègues
de ma promotion

”
Rosa

I
Remerciements

Tout d’abord, nous remercions Allah le tout puissant de nous avoir donné le courage et la
patience nécessaires à mener ce travail à son terme.

Nous remercions tous les membres du jury, pour avoir accepté d’examiner notre travail. Nous
disons mille fois merci à nos familles pour leurs soutiens, leurs conseils et leurs encouragements.

Nos vifs remerciements vont en premier lieu à notre encadrant Mr ZERARGA Loutfi
pour avoir accepté de nous guider tout au long de ce travail, pour sa disponibilité et son
implication pour l’aboutissement de ce travail, et nous souhaitons profiter de cette occasion
pour exprimer notre gratitude et nos remerciements les plus chaleureux envers la directrice de
l’école ’Amis de java’ Mme KERKOUR Kahina (Mme java).

Nous tenons également à exprimer notre gratitude envers le personnel de la pharmacie

principale du CHU Bejaia, en particulier Mr ADNANE Abdelouahid, Mr ARAB Abde-
louahab et Mr FERHAT Zobir pour leur accueil chaleureux et leur coopération lors de
notre stage. Leur participation active et leur disponibilité ont grandement facilité la réalisation
de cette étude.

Nous exprimons nos reconnaissances envers toutes les personnes qui ont contribué de près ou
de loin à ce mémoire, qu’ils soient mentionnés ici ou non. Votre collaboration et vos contributions
ont été précieuses et ont enrichi ce travail.

II
Table des matières

Dédicace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I

Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II

Introduction générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1 Contexte d’étude et recueil des besoins . . . . . . . . . . . . . . . . . . . . . . . 3

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Centre Hospitalo-universitaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Présentation du CHU de Béjaia . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Historique du CHU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Missions et objectifs du CHU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Les missions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.2 Les objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Organigramme du CHU de Béjaia . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Présentation de la pharmacie principale . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Organigramme de la pharmacie principale . . . . . . . . . . . . . . . . . . . . . 6
1.7 Ressources disponibles dans la pharmacie principale . . . . . . . . . . . . . . . . 8
1.7.1 Moyens matériels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7.2 Moyens logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7.3 Moyens humains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.8 Objectifs et missions de la pharmacie principale . . . . . . . . . . . . . . . . . . 11
1.9 Étude des documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.9.1 Le dossier médical établit par médecin . . . . . . . . . . . . . . . . . . . 12
1.9.2 Les informations nécessaires pour la gestion de stock . . . . . . . . . . . 13
1.10 Fonctionnement de la direction au quotidien . . . . . . . . . . . . . . . . . . . . 14
1.11 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.11.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.11.2 Solutions proposées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.12 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Méthodologie de conception et spécification des besoins . . . . . . . . . . . . 18

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Méthodologie de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.1 Méthodes agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.2 Méthode Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.3 Langage de modélisation UML . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Pilotage du projet avec scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.1 Rôle et user stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

III
Table des matières

2.4.2 User-Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.3 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.4 Diagramme de contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.5 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . 25
2.4.6 Planification des releases . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5 Backlog-Product (carnet de produit) . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6 Charte graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6.1 Logotype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6.2 Les couleurs dominantes . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3 Release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Étude du sprint 1 : Espace administrateur . . . . . . . . . . . . . . . . . . . . . 30
3.2.1 Diagramme de cas d’utilisation du sprint 1 . . . . . . . . . . . . . . . . . 31
3.3 Cas d’utilisation ”s’authentifier” . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.1 Description textuelle du cas d’utilisation ”s’authentifier” . . . . . . . . . 31
3.3.2 Diagramme d’interaction de cas d’utilisation ”s’authentifier” . . . . . . . 32
3.4 Cas d’utilisation ’Ajouter compte’ . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.1 Description textuelle de cas d’utilisation ajouter compte . . . . . . . . . 33
3.4.2 Diagramme d’interaction de cas d’utilisation ’Ajouter un compte’ . . . . 34
3.5 Cas d’utilisation ’modifier spécialité’ . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.1 Description textuelle de cas d’utilisation modifier spécialité . . . . . . . . 35
3.5.2 Diagramme d’interaction de cas d’utilisation modifier spécialité . . . . . 36
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4 Release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Etude de sprint 2 : Médicaments . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.1 Diagramme de cas d’utilisation du sprint 2 . . . . . . . . . . . . . . . . . 37
4.2.2 Description textuelle de cas d’utilisation ’Ajouter une DCI’ . . . . . . . . 38
4.2.3 Diagramme d’interaction de cas d’utilisation ’Ajouter une DCI’. . . . . . 39
4.3 Etude de sprint 3 : Espace médecin . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.1 Diagramme de cas d’utilisation du sprint 3 . . . . . . . . . . . . . . . . 40
4.3.2 Diagramme d’interaction de cas d’utilisation ’Rechercher patient’ . . . . 40
4.3.3 Diagramme d’interaction de cas d’utilisation ’Ajouter patient’ . . . . . . 41
4.3.4 Diagramme d’interaction de cas d’utilisation ’Rechercher médicament’ . 42
4.3.5 Description textuelle de cas d’utilisation ’Prescrire une ordonnance’ . . . 42
4.3.6 Diagramme d’interaction de cas d’utilisation ’Prescrire une ordonnance’ 43
4.4 Etude de sprint 4 : Servir ordonnance . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.1 Diagramme de cas d’utilisation de sprint 4 . . . . . . . . . . . . . . . . 44
4.4.2 Diagramme d’interaction de cas d’utilisation ’Rechercher ordonnance’ . . 45
4.4.3 Description textuelle de cas d’utilisation ’Servir ordonnance’ . . . . . . . 46
4.4.4 Diagramme d’interaction de cas d’utilisation servir ordonnance . . . . . 47
4.5 Etude de sprint 5 : Gestion de stock . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5.1 Diagramme de cas d’utilisation du sprint 5 . . . . . . . . . . . . . . . . . 48
4.5.2 Description textuelle de cas d’utilisation ’Établir un bon de commande’ . 49
4.5.3 Diagramme d’interaction de cas d’utilisation ’Établir un bon de commande’ 50

IV
Table des matières

4.5.4 Description textuelle de cas d’utilisation ’ajouter bon de réception’ . . . 51

4.5.5 Diagramme d’interaction de cas d’utilisation ’Ajouter bon de réception’ . 53
4.6 Etude de sprint 6 : Ordonnance externe . . . . . . . . . . . . . . . . . . . . . . 54
4.6.1 Diagramme de cas d’utilisation du sprint 6 . . . . . . . . . . . . . . . . . 54
4.6.2 Diagramme d’interaction ’Rechercher médecin externe’ . . . . . . . . . . 55
4.6.3 Diagramme d’interaction ’Ajouter médecin externe’ . . . . . . . . . . . . 55
4.6.4 Description textuelle de cas d’utilisation ajouter une ordonnance externe 56
4.6.5 Diagramme d’interaction de cas d’utilisation ’Ajouter une ordonnance
externe’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5 Conception de la base de données . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2 Règles de gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.4 Dictionnaire de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.5 Schéma relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.5.1 Les règles de passage du diagramme de classe vers modèle relationnel . . 65
5.5.2 Modele relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.2 Langages, environnement et outils de développement . . . . . . . . . . . . . . . 68
6.3 Sécurité de l’application grâce à l’authentification et l’autorisation . . . . . . . . 73
6.4 Présentation des interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.4.1 Interface de login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.4.2 Interface de tableau de bord . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.4.3 Interface de la liste des services . . . . . . . . . . . . . . . . . . . . . . . 76
6.4.4 Interface d’ajout d’un compte . . . . . . . . . . . . . . . . . . . . . . . . 76
6.4.5 Interface d’ajout des médicaments . . . . . . . . . . . . . . . . . . . . . 78
6.4.6 Interface d’ajout d’un patient . . . . . . . . . . . . . . . . . . . . . . . . 78
6.4.7 Interface d’ajout d’une ordonnance . . . . . . . . . . . . . . . . . . . . . 79
6.4.8 Interface d’impression d’une ordonnance . . . . . . . . . . . . . . . . . . 80
6.4.9 Interfaces liste des ordonnances . . . . . . . . . . . . . . . . . . . . . . . 80
6.4.10 Interfaces de servir une ordonnance . . . . . . . . . . . . . . . . . . . . 81
6.4.11 Interfaces des bons de commandes. . . . . . . . . . . . . . . . . . . . . . 82
6.4.12 Interface des bons de réceptions . . . . . . . . . . . . . . . . . . . . . . 83
6.4.13 Interface d’affichage de stock des médicaments . . . . . . . . . . . . . . . 84
6.4.14 Interface d’ajout d’un médecin externe . . . . . . . . . . . . . . . . . . . 85
6.4.15 Interface d’ajout d’une ordonnance externe . . . . . . . . . . . . . . . . . 85
6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Conclusion et perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

V
Table des matières

A Structure du CHU de Béjaia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

B Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

VI
Table des figures

1.1 Organigramme du CHU de Béjaia[9]. . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Organigramme de la pharmacie principale. . . . . . . . . . . . . . . . . . . . . . 7
1.3 Le tableau de bord du logiciel 3COH. . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 L’interface d’EPIPHARM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1 Les principaux composants de la méthode scrum[6]. . . . . . . . . . . . . . . . . 20

2.2 les différents diagrammes UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 L’architecture MVC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4 Diagramme de contexte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5 Diagramme de cas d’utilisation global. . . . . . . . . . . . . . . . . . . . . . . . 25
2.6 Planification des releases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7 Le logo de OrdoTrack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.8 La palette des couleurs d’OrdoTrack. . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1 Diagramme de cas d’utilisation administrateur. . . . . . . . . . . . . . . . . . . 31

3.2 Diagramme d’interaction ”S’authentifier”. . . . . . . . . . . . . . . . . . . . . . . 33
3.3 Diagramme d’interaction ’Ajouter un compte. . . . . . . . . . . . . . . . . . . . 34
3.4 Diagramme d’interaction modifier spécialité. . . . . . . . . . . . . . . . . . . . . 36

4.1 Diagramme de cas d’utilisation de pharmacien chef pour la gestion des médica-
ments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Diagramme d’interaction ’Ajouter une DCI’. . . . . . . . . . . . . . . . . . . . . 39
4.3 Diagramme de cas d’utilisation de médecin. . . . . . . . . . . . . . . . . . . . . 40
4.4 Diagramme d’interaction ’Rechercher patient’. . . . . . . . . . . . . . . . . . . . 41
4.5 Diagramme d’interaction ’Ajouter patient’. . . . . . . . . . . . . . . . . . . . . . 41
4.6 Diagramme d’interaction ’Rechercher médicament’. . . . . . . . . . . . . . . . . 42
4.7 Diagramme d’interaction ’Prescrire une ordonnance’. . . . . . . . . . . . . . . . 44
4.8 Diagramme de cas d’utilisation pharmacien pour les ordonnances. . . . . . . . . 45
4.9 Diagramme d’interaction ’Rechercher ordonnance’. . . . . . . . . . . . . . . . . . 46
4.10 Diagramme d’interaction ’Servir ordonnance’. . . . . . . . . . . . . . . . . . . . 47
4.11 Diagramme de cas d’utilisation de pharmacien pour la gestion de stock. . . . . . 49
4.12 Diagramme d’interaction ’Établir un bon de commande’. . . . . . . . . . . . . . 51
4.13 Diagramme d’interaction ’Ajouter bon de réception’. . . . . . . . . . . . . . . . . 53
4.14 Diagramme de cas d’utilisation de pharmacien chef pour la gestion des ordon-
nances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.15 Diagramme d’interaction ’Rechercher médecin externe’. . . . . . . . . . . . . . . 55
4.16 Diagramme d’interaction ’Ajout médecin externe’. . . . . . . . . . . . . . . . . . 56
4.17 Diagramme d’interaction ’Ajouter une ordonnance externe’. . . . . . . . . . . . . 58

5.1 Diagramme de classe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

VII
Table des figures

6.1 Logo de HTML CSS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.2 Logo de Bootstrap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.3 Logo de Javascript. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.4 Logo de Vue js. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.5 Logo de PHP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.6 Logo de Laravel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.7 Logo de Inertia js. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.8 Logo de MySQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.9 Logo de MAMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.10 Logo de Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.11 Logo de GitHub Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.12 Logo de Scrumblr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.13 Logo de Visual Paradigmr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.14 Logo de Figma. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.15 Logo de Illustrator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.16 Schéma représente les fonctionnalités de la sécurité. . . . . . . . . . . . . . . . . 73
6.17 Interface de connexion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.18 Interface de tableau de bord. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.19 Interface liste des services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.20 Interface créer un compte pharmacien chef. . . . . . . . . . . . . . . . . . . . . . 76
6.21 Interface créer un compte pharmacien. . . . . . . . . . . . . . . . . . . . . . . . 77
6.22 Interface créer un compte médecin. . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.23 Interface ajouter une DCI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.24 Interface ajouter un patient. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.25 Interface sélectionne de patient et médicaments pour l’ordonnace. . . . . . . . . 79
6.26 Interface de remplissage des champs pour l’ordonnance. . . . . . . . . . . . . . . 79
6.27 Interface imprimer une ordonnance. . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.28 Interface de la liste des ordonnances. . . . . . . . . . . . . . . . . . . . . . . . . 80
6.29 Interfaces de servir une ordonnance. . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.30 Interface des détails de la délivrance de l’ordonnance. . . . . . . . . . . . . . . . 81
6.31 Interface ajouter un bon de commande. . . . . . . . . . . . . . . . . . . . . . . . 82
6.32 Interface afficher un bon de commande. . . . . . . . . . . . . . . . . . . . . . . . 82
6.33 Interface réceptionner un bon de commande. . . . . . . . . . . . . . . . . . . . . 83
6.34 Interface afficher un bon de réception . . . . . . . . . . . . . . . . . . . . . . . . 83
6.35 Interface afficher stock des médicaments . . . . . . . . . . . . . . . . . . . . . . 84
6.36 Interface afficher état de stock . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.37 Interface ajouter un médecin externe. . . . . . . . . . . . . . . . . . . . . . . . . 85
6.38 Interface détails de l’ordonnance externe. . . . . . . . . . . . . . . . . . . . . . . 85

B.1 Ordonnance interne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

B.2 Ordonnance externe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
B.3 Bon de commande. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
B.4 Bon de livraison. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
B.5 Bon de réception. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

VIII
Liste des tableaux

1.2 Comparaison entre les deux logiciels . . . . . . . . . . . . . . . . . . . . . . . . 11

1.4 Profils des membres de l’équipe dirigeante. . . . . . . . . . . . . . . . . . . . . . 11
1.6 L’ensemble des informations d’une ordonnance. . . . . . . . . . . . . . . . . . . 13
1.8 L’ensemble des informations pour la gestion de stock. . . . . . . . . . . . . . . . 14

2.2 La répartition des rôles pour la réalisation de projet. . . . . . . . . . . . . . . . 23

2.4 L’ensemble des User-Stories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6 Le carnet de produit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Description textuelle du cas d’utilisation ”s’authentifier”. . . . . . . . . . . . . . 32

3.4 Description textuelle du cas d’utilisation ajouter compte. . . . . . . . . . . . . . 34
3.6 Description textuelle du cas d’utilisation modifier spécialité. . . . . . . . . . . . 35

4.2 Description textuelle du cas d’utilisation ’ajouter une DCI’ . . . . . . . . . . . . 38

4.4 Description textuelle du cas d’utilisation ’Prescrire une ordonnance’. . . . . . . . 43
4.6 Description textuelle du cas d’utilisation ’Servir ordonnance’. . . . . . . . . . . . 47
4.8 Description textuelle du cas d’utilisation ’Établir un bon de commande’. . . . . 50
4.10 Description textuelle du cas d’utilisation ’Ajouter bon de réception’. . . . . . . . 52
4.12 Description textuelle du cas d’utilisation ’Ajouter une ordonnance externe’. . . . 57

IX
Liste des sigles et acronymes

3COH Triple compatibilité hospitalière

CHU Centre Hospitalo Universitaire

CNAS Caisse nationale de sociale

DCI Dénomination Commune Internationale

EPH Établissement Public Hospitalier

HTML HyperText Markup Language

JS JavaScript

MVC Model-View-Controller, ou modèle-vue-contrôleur

PHP Hypertext Preprocessor

RDV Rendez-Vous

UML Unified Modeling Language, ou langage de modélisation unifié

XML Extensible Markup Language

X
Introduction générale

La santé numérique, également connue sous le terme de santé connectée ou e-santé, fait
référence à l’application des technologies de l’information et de la communication dans le do-
maine de la santé. Elle englobe un large éventail d’applications, telles que les dossiers médicaux
électroniques, la télé-médecine, les applications mobiles de santé, les dispositifs portables de
suivi de la condition physique, les solutions de gestion des pharmacies, et bien plus encore.
Dans ce contexte que notre stage au sein de la pharmacie principale de l’établissement
CHU de Béjaia a pris place. Au cours de ce stage, nous avons eu l’opportunité de recueillir des
informations sur les processus de gestion des prescriptions et de délivrance des médicaments. En
analysant ces pratiques, nous avons identifié certaines problématiques : i) prescription manuelle
des ordonnances, ii) remise des prescriptions par les patients, iii) enregistrement manuel des
délivrances.
La prescription manuelle présente des risques potentiels tels que des erreurs d’écriture, des
difficultés de déchiffrement et des ambiguïtés. Ces facteurs peuvent conduire à des confusions
ou des erreurs lors de la délivrance des médicaments.
La méthode actuelle de remise des prescriptions par les patients présente des risques tels que la
perte, le vol ou la détérioration des ordonnances, compromettant ainsi la sécurité et la continuité
des soins.
L’utilisation de registres écrits pour enregistrer les détails des délivrances peut être chrono-
phage et entraîner des erreurs, des retards et une gestion peu performante de l’information.
Cela peut également entraîner des difficultés dans la recherche et le suivi des informations
pertinentes.
En résumé, ces méthodes manuelles peuvent avoir des conséquences négatives pour les patients
et nécessitent une amélioration pour optimiser l’efficacité et la sécurité de la délivrance des
médicaments.

La gestion traditionnelle des ordonnances, qui ne répond pas aux besoins ni des patients
ni des professionnels de santé, a attiré notre attention et nous a orientés à réaliser un projet
de fin d’études de master sous le thème « Conception et réalisation d’une application web de
gestion des ordonnances et du stock des médicaments à titre ambulatoire, cas d’études : CHU
Béjaia ». Nous avons ainsi conçu et développé une application web que nous avons nommée
”OrdoTrack”, qui répond aux besoins de gestion des ordonnances et de stock des médicaments,
tout en favorisant l’efficacité, la sécurité et la continuité des soins pour les patients du CHU
de Bejaïa qui bénéficient d’un traitement à titre ambulatoire . Cette application facilite la
prescription automatique, la délivrance et le suivi des ordonnances électroniques. Elle offre
également un moyen plus sûr, plus pratique et plus efficace pour les patients et les professionnels
de santé.
L’application web OrdoTrack vise à atteindre les objectifs suivants :

1
Introduction générale

• Proposer un moyen d’édition automatique des ordonnances, facilitant leur gestion et leur
suivi.

• Libérer les patients de la responsabilité de sauvegarder et de transporter leurs ordonnances

en main propre chez les pharmaciens.

• Faciliter aux pharmaciens la délivrance des ordonnances électroniques, tout en sauvegar-

dant tous les détails de la délivrance.

• Permettre un suivi précis des données de la délivrance, favorisant ainsi la continuité des
soins et la sécurité des patients.

• Garantir le suivi, la traçabilité et l’historique des délivrances.

• Mettre en place un système informatisé de gestion de stock qui surveille automatiquement

les niveaux de médicaments disponibles et déclenche une alerte lorsque le stock atteint
un niveau insuffisant et lorsque les dates de péremption sont proches

La suite de notre rapport est organisée comme suit :

Le premier chapitre, intitulé « Contexte d’études et recueil des besoins », à pour rôle d’in-
troduction au projet. Nous y présentons l’organisme d’accueil, sa structure et ses missions, tout
en fournissant une description détaillée de l’étude de l’existant et du contexte de travail. Ce
chapitre aborde également la problématique et les objectifs du projet.
Le deuxième chapitre, « Méthodologie de conception et spécification des besoins », est consa-
cré à la présentation de la méthode Scrum, du langage de modélisation UML, ainsi l’architecture
MVC de notre système. Nous y détaillons également la spécification des besoins, en identifiant
les acteurs et l’environnement général à l’aide d’un diagramme de contexte. Nous établissons
également le diagramme de cas d’utilisation global, accompagné des user stories et le carnet de
produit (backlog-product).
Dans le troisième et quatrième chapitres, nous présentons l’étude des livrables selon les
sprints planifiés. Nous y incluons le diagramme de cas d’utilisation, les descriptions textuelles
et la réalisation des diagrammes d’interaction pour chaque sprint.
Le cinquième chapitre « Conception de la base de données » est consacré à la présentation des
règles de gestion, diagramme de classes, du dictionnaire de données et du passage au relationnel.
Dans le sixième chapitre nous décrivons l’implémentation de cette application, en présentant
les outils et les langages utilisés, ainsi que les différentes interfaces de notre application.
Enfin, nous concluons par un résumé des résultats obtenus et nous proposons quelques
perspectives d’évolution.

2
Chapitre 1

Contexte d’étude et recueil des besoins

1.1 Introduction
Ce chapitre est un chapitre introductif dans lequel nous expliquons et décrivons le contexte
et les objectifs de notre travail. En présentant dans un premier lieu l’organisme d’accueil (CHU
de Béjaia). En deuxième lieu, nous décrivons la pharmacie principale, sa structure, sa situation
informatique, ses missions et son fonctionnement au quotidien. En dernier lieu nous exposons
en détail la problématique et les solutions proposées.

1.2 Centre Hospitalo-universitaire

Les centres hospitalo-universitaires (CHU) sont des hôpitaux publics qui rassemblent des
fonctions de soins, d’enseignement et de recherche médicale. Cette triple mission leur confère
une place particulière dans le système des soins hospitaliers [10].

1.2.1 Présentation du CHU de Béjaia

Le Centre Hospitalier Universitaire est un établissement public à caractère administra-
tif, doté de la personnalité juridique et de l’autonomie financière, assurant des soins par des
professionnels de santé expérimentés et des étudiants. Par convention, le CHU est associé à
l’Université. Les étudiants pratiquent l’enseignement avec de vrais patients au sein du CHU.
L’enseignement concerne la médecine générale ou spécialisée, les spécialités paramédicales et
les chercheurs scientifiques. Le CHU dispose d’un centre de services d’urgence et d’un centre
antipoison.
Le CHU de Béjaia a été créé par le décret exécutif n° 09-319 du 17 chaoual 1430 corres-
pondant au 6 octobre 2009 complétant la liste des centres hospitalo-universitaires annexée au
décret exécutif n° 97-467 du 2 Chaàbane 1418 correspondant au 23 décembre 1997 fixant les
règles de création, d’organisation et de fonctionnement des centres hospitalo-universitaire[5].
Le siège du Centre Hospitalo-universitaire (CHU) de Béjaïa se trouve à l’hôpital Khellil
Amrane avec ces consistances physiques :

• Hôpital Khellil Amrane.

3
Chapitre 1. Contexte d’étude et recueil des besoins

• Hôpital Frantz Fanon.

• Hôpital Targua Ouzemmour (Clinique Mère-Enfant).

1.2.2 Historique du CHU

La construction de l’hôpital de Béjaia a eu lieu en date 1878 ou Mr et Mme Troncy on fait
une donation à la commune de Bougie d’un immeuble pour la construction d’un hôpital civil.
En 1889 cet immeuble a été vendu à Mr le général Surney qui a contribué avec les fonds de
subvention du gouvernement général à la construction de l’hôpital actuel. D’après les archives
du répertoire des malades hospitalisés on a déduit que l’hôpital a commencé ses activités en
janvier 1896 ou à cette période cet hôpital a été un établissement colonial que seuls les privilégiés
accéder aux soins.
À sa construction, il a été nommé « Hôpital Civil de Bougie ». Vers les années 50, il a
été nommé « Hôpital Régional de Bougie » d’après les archives. En 1927 et 1928, Des travaux
d’entretien et de réfection de peinture et badigeons des bâtiments existants ont été entrepris.
Quelques années après l’indépendance, il a pris le nom du « Secteur Sanitaire de Béjaia ».
Après l’inauguration et la mise en service de l’EPH Khelil Amran en 1991, « Secteur Sanitaire
de Béjaia » devient « Hôpital Frantz Fanon ».
La structure de l’hôpital Mère et enfant de Béjaia est à l’origine d’une structure de la CNAS,
versée à la santé et qui a été réaménagée en clinique Targua Ouzemmour spécialisé en mère
et enfant qui faisait partie du secteur sanitaire de Béjaia en 1991. En 2011, l’hôpital Khellil
Amrane est devenu le siège du Centre Hospitalo-universitaire (CHU) de Béjaia. La création de
ce dernier est faite suite à l’inauguration de la faculté de médecine [5].

1.3 Missions et objectifs du CHU

1.3.1 Les missions

Le CHU de Béjaia est constitué de l’ensemble des services sanitaires, de prévention de soins
et d’hospitalisation pour accomplir un ensemble de missions selon trois niveaux [8].

En matière de santé

• D’assurer les activités de diagnostic, de soins, d’hospitalisation et des urgences médico-

chirurgicales, de prévention ainsi que de toute activité concourante à la protection et à
la promotion de la santé de la population.

• D’appliquer les programmes nationaux, régionaux et locaux de santé.

• De participer à l’élaboration des normes d’équipement sanitaire scientifique et pédago-

gique des structures de la santé.

• De contribuer à la protection et à la promotion de l’environnement dans les domaines

relevant de la prévention, de l’hygiène, de la salubrité, de la lutte contre les nuisances et
fléaux sociaux[8].

4
Chapitre 1. Contexte d’étude et recueil des besoins

En matière de formation

• D’assurer, en liaison avec l’université d’enseignement supérieur de la formation en sciences

médicales et sciences de soins infirmiers, la formation graduée et post-graduée en sciences
médicales et de participer à l’élaboration et à la mise en œuvre des programmes y afférents.

• De participer à la formation, au recyclage et au perfectionnement des personnels de santé

[8].

En matière de recherche

• D’effectuer, dans le cadre de la réglementation en vigueur, tous travaux d’étude et de

recherche dans le domaine des sciences de santé.

• D’organiser des séminaires, colloques, journées d’études et autres manifestations tech-

niques et scientifiques en vue de promouvoir les activités de soins, de formation et de
recherche en sciences de la santé [8].

1.3.2 Les objectifs

CHU a notamment comme objectif de :

• Maintenir un niveau élevé de soins.

• Organiser des formations médicales et soins infirmiers.

• Développer les recherches en science de la santé.

• Soutenir la mise en œuvre des schémas régionaux d’organisation et de suivis, d’accompa-

gner les recompositions internes, les regroupements de plateaux techniques, les partena-
riats entre les établissements publics et privés [8].

1.4 Organigramme du CHU de Béjaia

L’organigramme 1.1 présente la structure du CHU ainsi que ses différentes unités et les
directions associées.

5
Chapitre 1. Contexte d’étude et recueil des besoins

Fig. 1.1 : Organigramme du CHU de Béjaia[9].

La description détaillée de la structure du CHU est présentée en annexe A. Dans les parties
suivantes, nous nous intéressons plus particulièrement à la pharmacie principale qui est attachée
à la sous-direction des produits pharmaceutiques.

1.5 Présentation de la pharmacie principale

La pharmacie principale du CHU de Béjaia est localisée à l’hôpital Khelil Amrane et repartie
en deux unités Targua Ouzemmour, Frantz Fanon.
Elle a pour missions d’assurer a gestion et la distribution des produits pharmaceutiques aux
services de l’établissement et aux deux autres unités, l’élaboration des besoins, l’approvision-
nement, la préparation, le stockage, la distribution et la délivrance des médicaments.

1.6 Organigramme de la pharmacie principale

L’organigramme de la figure 1.2 présente la structure de la pharmacie principale et ses
unités.

6
Chapitre 1. Contexte d’étude et recueil des besoins

Fig. 1.2 : Organigramme de la pharmacie principale.

• Consommables : Cette unité est responsable de la gestion des consommables médicaux,

tels que les pansements, les compresses, les seringues, les aiguilles, etc. Elle assure la
réception, le stockage et la distribution de ces produits dans le CHU.

• Réactif de laboratoire : Cette unité est chargée de la gestion des réactifs de laboratoire
et des équipements nécessaires aux analyses médicales. Elle assure la réception, le stockage
et la distribution de ces produits aux différents laboratoires du CHU.

• Instrumentation et ostéosynthèse : Cette unité est responsable de la gestion des

instruments chirurgicaux et médicaux utilisés pour les opérations et les procédures médi-
cales, des implants orthopédiques tels que les plaques, les vis, les clous etc. Elle assure la
réception, le stockage et la distribution de ces produits aux différents services d’orthopédie
du CHU.

• Médicaments : Cette unité est chargée de la gestion des médicaments dans la pharmacie
du CHU. Elle assure la réception, le stockage, la délivrance et la gestion des commandes
de médicaments pour les patients hospitalisés, ainsi que pour les patients suivis en am-
bulatoire. Chaque médicament est déterminé par certains paramètres.

– DCI : Dénomination Commune Internationale. Il s’agit d’un nom générique qui

permet d’identifier la substance active d’un médicament, indépendamment de sa
marque commerciale ou de son fabricant. Elle facilite la communication et la com-
préhension internationales des médicaments et peut contribuer à réduire les coûts
pour les patients.

7
Chapitre 1. Contexte d’étude et recueil des besoins

– Nom commercial : Est un nom choisi par le fabricant d’un médicament pour
le commercialiser. Il s’agit d’un nom unique et facilement identifiable qui est utilisé
pour promouvoir et vendre le médicament auprès des professionnels de la santé et des
patients. Le nom commercial n’a pas de signification pharmaceutique et n’indique
pas la composition ou la fonction du médicament, contrairement à la DCI.
– Forme : Se réfère à la présentation physique et chimique du médicament ainsi qu’à
la quantité de substance active qu’il contient. Par exemple, un médicament peut
être présenté sous forme de comprimés, de capsules, de solution orale, de pommade,
de spray, etc.
– Dosage : Fait référence à la quantité de substance active présente dans chaque unité
de forme du médicament, telle que milligrammes (Mg), micro-grammes (µg), unités
internationales (UI), etc.

1.7 Ressources disponibles dans la pharmacie principale

Dans cette partie, nous allons présenter les ressources matérielles, logicielles et humaines
disponibles.

1.7.1 Moyens matériels

Les outils de bureautique et équipements de communication :

• 7 Ordinateurs.

• 6 Onduleurs.

• 3 Imprimantes.

• 1 Fax.

1.7.2 Moyens logiciels

Les outils et applications de gestion utilisée par la direction :
3COH : La mise en œuvre de ce logiciel a débuté en janvier 2010 par le MSPFH (Ministère
de la Santé, de la Population et de la Réforme Hospitalière). Ce système est basé sur l’utilisation
du logiciel de gestion triple comptabilité hospitalière qui assure la prise en charge de tous les
systèmes de gestion de l’établissement :

• Gestion des achats et de la relation fournisseurs.

• Gestion des stocks.

• Gestion des immobilisations.

• Système de facturation.

8
Chapitre 1. Contexte d’étude et recueil des besoins

• Gestion des consommations.

• Suivi budgétaire.

• Gestion de la trésorerie.

• Comptabilité générale.

• Comptabilité analytique.

• États financiers.

La figure suivante illustre le tableau de bord du logiciel 3COH. Ce tableau de bord fournit
une vue d’ensemble et des informations visuelles sur les données et les indicateurs clés du
système.

Fig. 1.3 : Le tableau de bord du logiciel 3COH.

EPIPHARM : Ce logiciel est une propriété du Ministère de la santé et de la population

et a été mis en œuvre à partir de 1994. EPIPHARM est un logiciel de gestion de produits
pharmaceutiques. Il permet de gérer entièrement les stocks de médicaments et produits phar-
maceutiques d’un établissement, de faire leur suivi et leur répartition par service ainsi d’une
analyse des consommations et des prévisions de commandes [13].
Grâce à ce logiciel le pharmacien gestionnaire peut :

• Connaître l’état du stock des médicaments et produits pharmaceutiques.

• Vérification des produits qui sont périmés.

9
Chapitre 1. Contexte d’étude et recueil des besoins

• Faire des inventaires sur les médicaments et produits en stock.

• Faire des évaluations et bilans des consommations des produits.

• Faire des prévisions de commandes.

• Gérer la distribution détaillée vers les services d’hospitalisations.

• Gestion de la trésorerie.

• Comptabilité générale.

• Comptabilité analytique.

• États financiers.

La figure ci-dessus présente l’interface d’accueil du logiciel EPIPHARME, offrant une vue
visuelle de la première page ou de l’écran principal du logiciel.

Fig. 1.4 : L’interface d’EPIPHARM.

10
Chapitre 1. Contexte d’étude et recueil des besoins

Comparaison entre logiciels

Le tableau suivant présente une comparaison entre ces deux logiciels :

Logiciel Technologie Plate-forme Avantages Inconvénients

Delphin Windows -La gestion en -Utilisation limitée.
3COH vista temps réel. -Aucune maintenance.
Windows 7 -La gestion
transparente.
DOS Windows -Engendrer des -Temps de réponse long.
xp. rapports. -Manque de fonctionnalités
EPIPHARM
-Les fonctionnalités -Aucune maintenance.
répondent aux besoins. -Utilisation uniquement
des imprimantes matricielles.

Tab. 1.2 : Comparaison entre les deux logiciels

1.7.3 Moyens humains

Les profils des membres de l’équipe dirigeante

Unité Membres de l’équipe dirigeante

Consommable 3 pharmaciens 3 préparateurs
Médicament 2 pharmaciens 1 préparateur
Laboratoire 1 pharmacien
Ostéosynthèse 1 informaticien

Tab. 1.4 : Profils des membres de l’équipe dirigeante.

1.8 Objectifs et missions de la pharmacie principale

La sous-direction a pour rôle de garantir la disponibilité des médicaments et produits phar-
maceutiques nécessaires au bon fonctionnement de l’établissement de santé. Voici quelques
missions :

• Gestion de stock : Elle doit s’assurer que les stocks sont suffisants pour répondre aux
besoins des patients et des services de soins.

• Approvisionnement : Elle doit identifier les besoins, passer des commandes auprès des
fournisseurs et s’assurer que les délais de livraison sont respectés.

• Distribution : Elle doit s’assurer que les produits sont livrés aux patients et services
en temps et en heure, en respectant les règles d’hygiène et de sécurité.

11
Chapitre 1. Contexte d’étude et recueil des besoins

• Contrôle de qualité : Elle doit effectuer des contrôles qualité sur les produits et
s’assurer qu’ils respectent les normes en vigueur.

• Gestion des déchets : Elle doit s’assurer que les déchets sont collectés, triés et éliminés
de manière sécurisée et respectueuse de l’environnement.

1.9 Étude des documents

1.9.1 Le dossier médical établit par médecin

Le certificat médical : Le certificat médical contenu dans le dossier permet de confirmer
le diagnostic ou la présence d’une maladie chez le patient. Ce document comprend des informa-
tions détaillées sur l’état de santé du patient, les symptômes observés, les résultats des examens
médicaux. Il constitue une pièce essentielle qui permet de suivre l’évolution de la maladie du
patient au fil du temps et de garantir une prise en charge médicale efficace et adaptée à son
état de santé.

L’ordonnance de patient : Une ordonnance est un document médical prescrit par un

professionnel de santé, généralement un médecin où un dentiste qui indique les médicaments
à prendre, leur posologie (dose), leur forme galénique (comprimés, capsules, sirop, etc.), ainsi
que la durée du traitement. En pharmacie, une ordonnance permet de fournir les médicaments
nécessaires pour le traitement du patient. Elle peut également contenir des instructions parti-
culières ou des précautions à prendre en compte.
Les détails contenus dans l’ordonnance médicale sont répertoriés dans le tableau 1.3 :

12
Chapitre 1. Contexte d’étude et recueil des besoins

informations
Nom du médecin traitant.
Informations concernant le médecin
Prénom du médecin traitant.
Spécialité du médecin traitant.
Information concernant le service et l’établissement Nom du service où le patient
fait la consultation et le nom de
l’établissement hospitalier.
Nom du patient.
Informations concernant le patient
Prénom du patient.
Âge où date de naissance du pa-
tient.
Les médicaments prescrits au
Informations concernant le traitement patient, ainsi que les doses.
la quantité et/ou la durée de
traitement de chaque médica-
ment ainsi que la posologie re-
commandée.
Les instructions d’utilisation et
la durée de traitement.

Tab. 1.6 : L’ensemble des informations d’une ordonnance.

1.9.2 Les informations nécessaires pour la gestion de stock

Le tableau 1.4 montre les informations nécessaires pour la gestion de stock :

13
Chapitre 1. Contexte d’étude et recueil des besoins

informations
-Numéro de bon de commande.
-Date de bon de commande.
-Le fournisseur a qui commandé.
Informations contenues dans les bons de commandes
-L’unité commandante.
-Les références du produit com-
mandé, qui permettent d’identifier
clairement l’article commandé.
-La quantité commandée, le prix
unitaire de chaque produit et le
montant total.
-Numéro de bon de livraison.
-Numéro de bon de commande à le-
quel on fait la livraison.
Informations contenues dans les bons de livraisons -Date de bon de livraison.
-Le fournisseur livreur.
-L’unité à laquelle on fait la livrai-
son.
-Les références du produit livré, qui
permettent d’identifier clairement
l’article livré.
-La quantité reçue, le prix unitaire
de chaque produit et le montant to-
tal.

Tab. 1.8 : L’ensemble des informations pour la gestion de stock.

1.10 Fonctionnement de la direction au quotidien

Dans notre projet, nous nous sommes intéressés à l’unité de distribution des médicaments
à titre ambulatoire, où nous avons étudié le fonctionnement quotidien de la distribution de ces
médicaments aux patients :

• Prescription : Le médecin prescrit le traitement au patient, en mentionnant le médica-

ment, la posologie et la durée du traitement.

14
Chapitre 1. Contexte d’étude et recueil des besoins

• Validation : Le pharmacien valide la prescription, en vérifiant la conformité de l’ordon-

nance et le dossier médical contenant le certificat.

• Préparation : Le pharmacien prépare le traitement en sortant les médicaments et en les

regroupant, puis il établit une copie de l’ordonnance :

– En ce qui concerne la disponibilité des médicaments en stock, les mesures suivantes

sont mises en œuvre :
∗ Si la quantité à servir correspond à la quantité disponible, l’ordonnance est
servie intégralement.
∗ Si la quantité à servir est inférieure à la quantité disponible, l’ordonnance est
servie partiellement.
∗ Dans le cas contraire, l’ordonnance n’est pas servie.
– En ce qui concerne les médicaments à titre ambulatoire, le pharmacien effectue un
enregistrement manuel des coordonnées du patient (nom, prénom, âge, sexe, numéro
de téléphone) dans le registre des médicaments à titre ambulatoire. De plus, il indique
la quantité servie, la date de délivrance, la durée du traitement et fixe un rendez-vous
pour les patients résidant uniquement dans le secteur médical du CHU.

• délivrance : Le traitement est remis au patient par le pharmacien, qui lui explique la
posologie, durée du traitement, les éventuels effets secondaires et les prochains rendez-
vous s’ils y en ont.

• Poursuite : Dans le cas où l’ordonnance est servie partiellement, le patient revient au

lieu pour compléter la suite du traitement jusqu’à qu’elle soit servie complète.

Le processus de distribution des médicaments plus précisément à titre ambulatoire est donc
très organisé et implique la participation de plusieurs acteurs clés. La coordination et la com-
munication efficaces entre ces acteurs sont essentielles pour garantir la sécurité et la qualité des
soins.

1.11 Discussion
Dans la suite, nous aborderons le contexte du projet en examinant les problématiques et en
proposant des solutions.

1.11.1 Problématique
Durant notre stage au niveau de la pharmacie principale du CHU de Béjaia, et d’après les
interviews que nous avons menées à la pharmacie principale, nous avons constatées et recensées
un ensemble d’insuffisances qui se résument comme suit :

• Prescription et vérification manuelle de la conformité des ordonnances avec les dossiers

médicaux.

• L’enregistrement manuel des informations par le pharmacien dans un registre peut conduire
à des erreurs de saisie ou des oublis.

15
Chapitre 1. Contexte d’étude et recueil des besoins

• Processus de distribution des médicaments long qui engendre des défis tels que les temps
d’attente prolongés et les erreurs de communication entre les acteurs peuvent avoir un
impact sur l’efficacité du processus.

• Nombre important d’informations à renseigner dans les registres qui engendrent une dif-
ficulté de l’accessibilité et le stockage.

• La sécurité insuffisante des informations relatives aux patients entraîne une protection
inadéquate des données médicales et personnelles, ce qui expose les patients à des risques
de violation de la confidentialité et d’utilisation abusive des données.

• Une gestion inefficace des rendez-vous peut entraîner des retards dans la prise en charge
des patients et une inefficacité dans la coordination des activités au sein de l’établissement.
De plus, l’absence d’intégrité des données peut compromettre la fiabilité et la précision
des informations, entraînant des conséquences préjudiciables.

1.11.2 Solutions proposées

L’objectif de notre travail est de proposer une application web qui assure une gestion amé-
liorée des ordonnances et du stock de médicaments, répondant ainsi aux besoins des médecins
et des pharmaciens. Cette application web vise les objectifs suivants :

• Utiliser un système de prescription électronique où le médecin peut saisir l’ordonnance

directement dans le système. Cela réduit les erreurs de prescription, facilite la communi-
cation avec la pharmacie et permet une traçabilité plus précise des prescriptions.

• Enregistrer et stocker les informations du patient de manière précise et accessible. Cela

permet de réduire les erreurs de saisie et facilite la recherche ultérieure des informations.

• Assurer une protection renforcée des données des patients et leurs ordonnances pour
garantir leur sécurité et maintenir des journaux d’activité appropriés.

• Mettre en place un système informatisé de gestion de stock qui surveille automatique-

ment le stock des médicaments disponibles. Le système peut alerter lorsque le stock est
insuffisant, permettant ainsi de prendre des mesures appropriées, telles que la commande
de nouveaux médicaments.

Pour répondre aux problématiques de sécurité des informations, de mauvaise gestion des rendez-
vous et de prescription/vérification manuelle, nous proposons la mise en place d’une application
web. Cette application permettra la gestion en temps réel des rendez-vous, la numérisation des
prescriptions et la vérification automatique des interactions médicamenteuses, tout en garantis-
sant une sécurité renforcée des informations grâce à l’utilisation d’un système d’authentification
sécurisé. En utilisant cette solution, la pharmacie pourra améliorer considérablement l’effica-
cité de la gestion des patients, et améliorer la satisfaction des patients en offrant un service de
qualité.

16
Chapitre 1. Contexte d’étude et recueil des besoins

1.12 Conclusion
En conclusion, nous avons étudié de manière approfondie la pharmacie principale, en met-
tant en évidence sa structure, ses ressources, ses objectifs et missions et son fonctionnement.
Nous avons également identifié la problématique actuelle liée à la distribution des médicaments
et présenté des solutions pour y remédier.

17
Chapitre 2

Méthodologie de conception et
spécification des besoins

2.1 Introduction
Dans ce chapitre, nous allons présenter la méthodologie de conception et la spécification
des besoins pour notre système. La première partie sera consacrée à la méthode agile Scrum
[6], nous expliquerons comment nous appliquons Scrum dans notre projet. Nous avons égale-
ment abordé l’utilisation du langage de modélisation UML (Unified Modeling Language) pour
représenter les différentes composantes de notre système.
Ensuite, nous aborderons l’architecture MVC (Modèle-Vue-Contrôleur) de notre système. Nous
expliquerons comment cette architecture divise notre système en trois composantes distinctes
Dans la deuxième partie, nous nous concentrerons sur la spécification des besoins et des exi-
gences de notre système. Nous mettrons l’accent sur les avantages de la méthode Scrum en
termes de productivité et d’efficacité.
Ce chapitre nous permettra de poser les bases de notre projet, en utilisant une méthodologie
de conception agile et en spécifiant les besoins et les exigences de notre système.

2.2 Méthodologie de conception

Pour l’élaboration de notre projet nous avons fait recours aux méthodes de conceptions
agiles et langage de modélisation unifié UML.

2.2.1 Méthodes agiles

Les méthodes agiles [7] sont des approches de gestion de projet qui mettent l’accent sur
la flexibilité, la collaboration et l’adaptation aux changements. Contrairement aux méthodes
traditionnelles, qui suivent un processus linéaire et prédictible, les méthodes agiles favorisent
une approche itérative.
Les méthodes agiles reposent sur plusieurs principes clés :

• Priorité à la satisfaction du client : L’objectif principal des méthodes agiles est

de satisfaire les besoins du client en livrant continuellement des logiciels fonctionnels et

18
Chapitre 2. Méthodologie de conception et spécification des besoins

utiles. Les clients sont impliqués activement dans le processus de développement et ont la
possibilité de donner leur avis et de fournir des retours fréquents. Cela permet d’ajuster
les fonctionnalités et les priorités du projet en fonction de leurs besoins changeants.

• Acceptation des changements de besoins : Les méthodes agiles reconnaissent que

les besoins et les exigences des clients peuvent évoluer tout au long du projet. Au lieu
de suivre un plan rigide, les équipes agiles sont prêtes à accueillir les changements et
à s’adapter en conséquence. Cela permet de répondre de manière flexible aux nouvelles
informations et aux nouvelles exigences, tout en maintenant un rythme de développement
soutenu [7].

• Collaboration étroite : Les méthodes agiles encouragent une collaboration étroite entre
les membres de l’équipe de projet et avec le client. Les équipes travaillent ensemble de
manière auto-organisée et interdisciplinaire, ce qui favorise une meilleure communication
et une compréhension mutuelle des objectifs du projet. Le client est impliqué dès le début
du processus et a un rôle actif dans la prise de décision [7].

• Évaluation régulière et adaptation : Les méthodes agiles reposent sur une évaluation
régulière de l’avancement du projet. Les équipes se réunissent fréquemment pour revoir les
progrès, identifier les problèmes et ajuster les plans en conséquence. Cette approche ité-
rative permet de détecter les obstacles rapidement et de les surmonter, tout en s’assurant
que le projet reste sur la bonne voie [7].

Les méthodes agiles populaires comprennent Kanban, Extreme Programming (XP) et Scrum
que nous avons opté pour la gestion de notre projet.

2.2.2 Méthode Scrum

Scrum est une méthode de développement agile itérative et incrémentale qui met l’accent
sur la gestion de projet, la gestion d’équipe et adapté pour un projet de moyenne a longue durée
comme le cas de notre projet d’où nous avons opté pour cette méthode. Elle se concentre sur la
planification des sprints, des réunions quotidiennes de stand up (Daily Scrum) afin de partager
l’état d’avancement, les succès et les obstacles entre les membres et une rétrospective de sprint
pour améliorer continuellement le processus de développement. Après plusieurs itérations une
livraison de release qui comporte toutes les fonctionnalités développées et testées prête pour les
livrer au client [6].

19
Chapitre 2. Méthodologie de conception et spécification des besoins

Fig. 2.1 : Les principaux composants de la méthode scrum[6].

La figure précédente présente les principaux composants de la méthode scrum.

• Les parties prenantes La méthode scrum regroupe trois acteurs : le Product Owner
qui représente l’utilisateur ou le client, le Scrum Master qui joue le rôle d’un facilitateur
et il a pour mission de tout mettre en œuvre pour que l’équipe travaille dans de bonnes
conditions et se concentre sur l’objectif du projet et enfin l’équipe de développement
regroupant tous les rôles traditionnels : architecte, développeur, testeur, administrateur,
etc.

• Product-backlog (carnet de produit) : est une liste priorisée des fonctionnalités

ou exigences du produit, sous forme de courtes descriptions appelées ”user stories” Il
représente l’ensemble des besoins du client ou des utilisateurs finaux pour le produit, et
est maintenu et priorisé par le Product Owner.

• Sprint : est une période de temps fixe, généralement de 1 à 4 semaines, pendant laquelle
l’équipe de développement travaille à la réalisation d’un ensemble de fonctionnalités sé-
lectionnées à partir du backlog produit. Les fonctionnalités à réaliser sont définies lors de
la planification du sprint, et l’équipe s’engage à les compléter dans la durée du sprint. À
la fin du sprint, une version fonctionnelle du produit est prête à être évaluée ou livrée au
client.

• Release : est une livraison planifiée de fonctionnalités fonctionnelles et testées du produit,

qui a pour but de répondre aux besoins des utilisateurs finaux ou du client. Elle est le fruit
du travail de l’équipe Scrum durant plusieurs itérations. En outre, la méthode Scrum offre
une grande flexibilité pour gérer les changements et les imprévus qui peuvent survenir au
cours du projet.

2.2.3 Langage de modélisation UML

Durant notre étude nous avons opté pour le langage UML (unified Modeling language )(en
français langage de modélisation unifie) est un langage de modélisation orienté objet utilisé

20
Chapitre 2. Méthodologie de conception et spécification des besoins

pour modéliser et représenter visuellement les différents aspects et composants d’un système
logiciel, tels que la structure du système, les comportements des objets et les interactions entre
eux, les cas d’utilisation, les séquences d’actions, les classes et les composants. UML fournit
des éléments visuels et des notations standardisées qui permettent une communication efficace
entre les développeurs et concepteurs sur les exigences et les fonctionnalités donc il offre une
grande flexibilité [3].
Il existe deux types de vues de système : Les Diagrammes structurels et les diagrammes
comportementaux comme montre la figure suivante.

Fig. 2.2 : les différents diagrammes UML.

2.3 Architecture MVC

Le modèle MVC connu sous le nom Model-View-Controller est un modèle d’architecture
utilisé pour créer la structure d’une application qui consiste à séparer l’application en trois
couches dépendantes et connectées : couche présentation (UI : User Interface), couche métiers
(BBL : Business Logic Layer) et couche d’accès aux données (DAL : Data Access Layer). Cette
architecture aide à la réutilisation du code et au développement parallèle ; ainsi les modifications
effectuées sur n’importe quelle couche de l’application n’affectent pas les autres couches [4].
La figure 2.3 illustre les interactions entre les trois couches (Modèle, Vue et Contrôleur)
ainsi qu’avec l’utilisateur :

21
Chapitre 2. Méthodologie de conception et spécification des besoins

Fig. 2.3 : L’architecture MVC.

• Couche modèle : Cette couche représente la structure des données de l’application,

également appelée ”back-end”. Elle contient le logique métier, les règles de traitement
des données et les opérations de persistance. Le modèle est responsable de la gestion des
données et de la manipulation des informations indépendamment de l’interface utilisateur
ou de l’affichage. Il peut interagir avec la couche d’accès aux données pour récupérer et
stocker les données nécessaires.

• Couche vue : Cette couche correspond à l’interface utilisateur, également appelée ”front-
end” ou ”GUI” (Graphical User Interface). Elle est chargée de présenter les données au
client sous une forme visuelle ou graphique. La vue utilise les informations fournies par le
modèle pour générer une représentation visuelle de l’application, telle qu’une page HTML,
une interface utilisateur graphique ou un résultat XML. La vue est généralement passive
et n’effectue pas de traitement complexe des données.

• Couche contrôleur : Le contrôleur agit comme un intermédiaire entre la vue et le

modèle. Il reçoit les requêtes des utilisateurs à partir de l’interface utilisateur (vue) et
les traites en conséquence. Le contrôleur est responsable de la coordination des actions
de l’application, de l’interaction avec le modèle pour récupérer les données nécessaires et
de l’ordonnancement de la vue pour afficher les résultats au client. Il gère la logique de
l’application et les règles métier, en manipulant les données provenant du modèle et en
les adaptant pour répondre aux besoins spécifiques de l’interface utilisateur.

22
Chapitre 2. Méthodologie de conception et spécification des besoins

2.4 Pilotage du projet avec scrum

2.4.1 Rôle et user stories

Pour notre projet, les rôles sont répartis comme suit :

Rôle SCRUM Personnes affectés

Product Owner Pharmacie principale CHU Bejaïa
Scrum Master Mr. ZERARGA Loutfi
Equipe de développement Mlle MEZIANI Keltoum et Mlle CHALAL Rosa

Tab. 2.2 : La répartition des rôles pour la réalisation de projet.

2.4.2 User-Stories
Nous présentant sur la figure suivante des user stories qui sont utilisées pour capturer les
besoins et les exigences des utilisateurs finaux du produit et les décomposer en tâches concrètes
et réalisables pour l’équipe de développement [11].

En tant que médecin, je veux gérer mes En tant médecin, je veux gérer mes pa-
ordonnances, prescrire de nouvelles ordon- tients et consulter le suivit de leur traitement.
nances aux nouveaux patients, les imprimés
et consulter la liste des médicaments que je
puisse prescrire.
En tant que pharmacien, je veux recher- En tant que pharmacien, je veux consul-
cher les ordonnances selon les patients, les ter le stock des médicaments, établir des bons
servir et consulter les médecins prescrivant de commande et faire la réception pour rem-
et leur service. plir le stock.
En tant que pharmacien chef, gérer les En tant que pharmacien chef, je veux
patients, les archiver, ajouter de nouvelles consulter le stock des médicaments, consul-
ordonnances venant des établissements ex- ter les bons de commande, consulter les bons
ternes de CHU Béjaia et ajouter les médecins de réception et ajouter de nouveau médica-
prescrivant et archiver les ordonnances. ments à la liste.
En tant qu’un administrateur, je veux En tant qu’un administrateur, je veux
gérer les comptes des utilisateurs. gérer les services et spécialités

Tab. 2.4 : L’ensemble des User-Stories.

23
Chapitre 2. Méthodologie de conception et spécification des besoins

2.4.3 Identification des acteurs

Un acteur est l’idéalisation d’un rôle joué par une personne, un processus ou une entité
externe qui interagit avec le système. Autrement dit, 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.
Les différents acteurs de notre système :

• Administrateur : Responsable de la gestion et l’administration de cette application,

prend en charge tout ce qui concerne la gestion des comptes utilisateurs, la gestion des
droits d’accès, la gestion des services et des spécialités

• Pharmacien chef : Est responsable de la gestion et de la supervision des opérations

pharmaceutiques au sein de l’établissement et la gestion des ordonnances externes de
CHU, dispose d’un compte dans notre application.

• Médecin : Est un professionnel de la santé qui est formé pour diagnostiquer, traiter et
prévenir les maladies chez les patients, dispose d’un compte dans notre application.

• Pharmacien : Est un professionnel de la santé spécialisé dans la préparation, la déli-

vrance et l’utilisation des médicaments, dispose d’un compte dans notre application.

2.4.4 Diagramme de contexte

Il s’agit d’un diagramme statique qui représente l’environnement général dans lequel un
système est conçu pour opérer [3].

Fig. 2.4 : Diagramme de contexte.

24
Chapitre 2. Méthodologie de conception et spécification des besoins

2.4.5 Diagramme de cas d’utilisation global

Le diagramme de cas d’utilisation est un diagramme UML qui représente les interactions
entre les acteurs avec le système en question. Les acteurs peuvent être des acteurs internes qui
ont un rôle à jouer dans le fonctionnement du système, comme les acteurs cités auparavant, ou
des acteurs externes qui se trouvent en dehors du système et qui interagissent avec lui [3].
Le diagramme de cas d’utilisation suivant présente le comportement fonctionnel du sys-
tème logiciel qui est décomposé en plusieurs sprints constituant le backlog product (carnet de
produit).

Fig. 2.5 : Diagramme de cas d’utilisation global.

25
Chapitre 2. Méthodologie de conception et spécification des besoins

2.4.6 Planification des releases

Un plan pour plusieurs sprints est créé pendant la planification des releases comme les
présentent les schémas ci-dessous avec ordre de priorité :

Fig. 2.6 : Planification des releases.

2.5 Backlog-Product (carnet de produit)

Chaque user-storie (histoire utilisateur) est caractérisée par une priorité dénie par le Pro-
duct Owner. Le backlog de notre futur système est le suivant :

Sprints Items En tant que Je veux... Priorité

Authentification Administrateur M’authentifier 1
Authentification Médecin M’authentifier 1
Authentification Pharmacien M’authentifier 1
1
Authentification Pharmacien Chef M’authentifier 1
Gérer les comptes Administrateur Créer, valider (activer /désac- 1
tiver), modifier et rechercher
un compte
Gérer les services Administrateur Ajouter, modifier et rechercher 1
un service
Gérer les spécialités Administrateur Ajouter, modifier et rechercher 1
une spécialité
2 Gérer les DCIs et les Pharmacien chef Ajouter une nouvelle DCI ou 2
noms commerciaux un nouveau nom commercial et
rechercher un médicament

26
Chapitre 2. Méthodologie de conception et spécification des besoins

Gérer les ordon- Médecin Prescrire, modifier, rechercher 3

3 nances et imprimer une ordonnance
Gérer les patients Médecin Ajouter, rechercher et modifier 3
un patient
Consulter la liste Médecin Rechercher un médicament 3
des médicaments
Consulter les ordon- Pharmacien Rechercher et servir une or- 4
nances et les servir donnance
4
Consulter la liste Pharmacien Rechercher un patient 4
des patients
Consulter la liste Pharmacien Rechercher un médecin 4
des médecins
Consulter la liste Pharmacien Rechercher un service ou une 4
des services et spé- spécialité
cialités
Gérer les bons de Pharmacien Ajouter, rechercher, modifier 5
commande et réceptionner un bon de com-
5 mande
Consulter la liste Pharmacien chef rechercher un bon de com- 5
des bons de com- mande
mandes
Gérer les bons de ré- Pharmacien Remplir le stock, ajouter et re- 5
ceptions chercher un bon de réception
Consulter la liste Pharmacien chef rechercher un bon de réception 5
des bons de récep-
tions
Consulter le stock Pharmacien Rechercher un médicament 5
des médicaments
Consulter le stock Pharmacien-chef Rechercher un médicament 5
des médicaments
Gérer les Ordon- Pharmacien chef Ajouter, modifier et archiver 6
nances externes une ordonnance externe
6
Gérer les médecins Pharmacien chef Ajouter,modifier et rechercher 6
externes un médecin externe
Gérer les patients Pharmacien chef Ajouter,modifier et rechercher 6
externes un patient externe
Gérer les ordon- Pharmacien chef Rechercher, archiver une or- 6
nances donnance

27
Chapitre 2. Méthodologie de conception et spécification des besoins

Tab. 2.6 : Le carnet de produit.

2.6 Charte graphique

La charte graphique peut être définie comme étant l’identité visuelle d’une application,d’une
entreprise où d’une marque, c’est un guide qui détermine tous les éléments graphiques(logo,
couleur, police, typographie et maquette), leurs utilisations et leurs caractéristiques. Elle permet
de donner une cohérence afin de donner à l’utilisateur des repères et lui faciliter sa visite [1].

2.6.1 Logotype

Un logo est une représentation graphique qui a pour but d’identifier de manière unique et
directe une marque, une entreprise ou une application.
La Figure suivante présente l’apparence du logo de notre application, qui reflète un symbole
de la croix médicale. Ce symbole représente le domaine de la santé et les pharmacies.

Fig. 2.7 : Le logo de OrdoTrack.

2.6.2 Les couleurs dominantes

Notre choix est porté sur 4 couleurs pour attirer l’intention de l’utilisateur avec une certaine
douceur. Les nuances de ce vert que nous avions choisies sont liées aux couleurs utilisées par le
personnel médical.
La Figure suivante présente la palette de couleurs que nous avions choisie :

Fig. 2.8 : La palette des couleurs d’OrdoTrack.

28
Chapitre 2. Méthodologie de conception et spécification des besoins

2.7 Conclusion
Dans ce chapitre, nous avons présenté un aperçu de la méthode Scrum, ainsi que ses diffé-
rents composants. Nous avons également mentionné quelques notions du langage de modélisa-
tion UML. Ensuite, nous avons spécifié les besoins et les exigences de notre système à travers
le diagramme de contexte et de cas d’utilisation,
Cette phase nous a permis de nous familiariser avec la méthode Scrum et de décrire de
manière globale les besoins de nos utilisateurs dans le backlog product, et le fonctionnement
désiré du système à développer afin d’en faciliter la réalisation et la maintenance.
Le chapitre suivant concerne le premier release nous entamerons une phase très importante
dans laquelle nous décrirons de manière détaillée comment ces besoins seront réalisés dans notre
système.

29
Chapitre 3

Release 1

3.1 Introduction
Dans ce chapitre, nous allons présenter le travail effectué lors du premier release, qui com-
prend le sprint 1 espace administrateur. Nous commencerons par décrire les diagrammes de cas
d’utilisation, suivis des descriptions textuelles et des diagrammes d’interaction correspondants
à ce sprint.

3.2 Étude du sprint 1 : Espace administrateur

Ce sprint s’est étalé sur 3 semaines, il comprend 3 items qui sont :
Authentification : Est le processus de vérification de l’identité d’un utilisateur ou d’un sys-
tème afin de garantir que l’accès aux ressources ou aux informations est accordé uniquement
aux personnes ou aux entités légitimes.
Gérer les comptes : Fait référence à l’ensemble des actions et fonctionnalités permettant
de gérer les comptes d’utilisateurs, Cela inclut les tâches suivantes : Création de compte pour
le médecin le pharmacien et le pharmacien chef, modification de compte, gestion des droits
d’accès, activation et désactivation des comptes.
Gérer les services et les spécialités : Ajout et modification

30
Chapitre 3. Release 1

3.2.1 Diagramme de cas d’utilisation du sprint 1

Le diagramme de cas d’utilisation suivant présente de manière générale les cas d’utilisation
constituant les items du premier sprint :

Fig. 3.1 : Diagramme de cas d’utilisation administrateur.

3.3 Cas d’utilisation ”s’authentifier”

3.3.1 Description textuelle du cas d’utilisation ”s’authentifier”

La figure 3.1 présente la description textuelle de cas d’utilisation ”s’authentifier” pour admi-
nistrateur ; c’est le même fonctionnement pour l’authentification de médecin, pharmacien chef
et pharmacien.

31
Chapitre 3. Release 1

CU : S’authentifier.
BUT : Ce cas permet à l’administrateur de système de se connecter.
Acteur principale : Administrateur.
Acteur secondaire : /
Pré-conditions : L’administrateur dispose déjà d’un compte.
Scénario nominal :
1. L’administrateur demande l’authentification.
2. Le système affiche le formulaire de connexion.
3. L’administrateur saisit son nom d’utilisateur et son mot de passe.
4. L’administrateur valide la connexion.
5. Le système vérifier les champs du formulaire.
6. Le système afficher son tableau de bord.
Enchaînement alternatif :
5.a Si une erreur est produite, le système affiche un message d’erreur.
Reprendre à partir de 2.
Post-condition : L’administrateur accède à son espace avec succès.

Tab. 3.2 : Description textuelle du cas d’utilisation ”s’authentifier”.

3.3.2 Diagramme d’interaction de cas d’utilisation ”s’authentifier”

La figure 3.2 présente le diagramme d’interaction de cas d’utilisation d’authentification de
l’administrateur. C’est le même traitement pour l’authentification de médecin, pharmacien chef
et pharmacien.

32
Chapitre 3. Release 1

Fig. 3.2 : Diagramme d’interaction ”S’authentifier”.

3.4 Cas d’utilisation ’Ajouter compte’

3.4.1 Description textuelle de cas d’utilisation ajouter compte

La figure suivante présente la description textuelle de cas d’utilisation ’ajouter compte’ :

CU : Ajouter compte.
BUT : Ce cas permet à l’administrateur de créer un compte pour les utilisateurs
(pharmacien-chef, médecin et pharmacien).
Acteur principale : Administrateur.
Acteur secondaire : /
Pré-conditions : L’administrateur est déjà connecté à son espace.
Scénario nominal :
1. L’administrateur demande le formulaire de création

33
Chapitre 3. Release 1

2. Le système affiche le formulaire

3. L’administrateur remplit le formulaire.
4. L’administrateur valide la syntaxe.
5. Le système vérifie le formulaire.
6. Le système crée le nouveau compte.
Enchaînement alternatif :
5.a Si le formulaire est mal remplit, le système affiche un message d’erreur.
Reprendre à partir de 2.
Post-condition : Le compte est ajouté avec succès.

Tab. 3.4 : Description textuelle du cas d’utilisation ajouter compte.

3.4.2 Diagramme d’interaction de cas d’utilisation ’Ajouter un comp-

te’
La figure suivante présente le diagramme d’interaction de cas d’utilisation ’Ajouter un comp-
te’ :

Fig. 3.3 : Diagramme d’interaction ’Ajouter un compte.

34
Chapitre 3. Release 1

NOTE :
-Requête 1: Envoi de requête d’insertion au modèle users.
-Requête 2: Envoi de requête d’insertion au modèle médecins.
-Requête 3: Envoi de requête d’insertion au modèle pharmacien.
-Requête 4: Envoi de requête d’insertion au modèle Pharmacien chef.

3.5 Cas d’utilisation ’modifier spécialité’

3.5.1 Description textuelle de cas d’utilisation modifier spécialité

La figure suivante présente la description textuelle de cas d’utilisation ’modifier spécialité’ :

CU : Modifier spécialité.
BUT : Ce cas permet à l’administrateur de modifier les spécialités.
Acteur principale :Administrateur.
Acteur secondaire : /
Préconditions : L’administrateur est déjà connecté à son espace.
Scénario nominal :
1. L’administrateur rechercher la spécialité avec son nom.
2. Le système retourne la spécialité trouvée.
3. Le système affiche le formulaire des informations de spécialité.
4. L’administrateur saisit les modifications.
5. L’administrateur valide la syntaxe.
6. Le système vérifié le formulaire.
7. Le système modifie la spécialité.
Enchaînement alternatif :
6.a Si le formulaire est mal remplit, le système affiche un message d’erreur.
Reprendre à partir de 3.
Post condition : La spécialité est modifiée avec succès.

Tab. 3.6 : Description textuelle du cas d’utilisation modifier spécialité.

35
Chapitre 3. Release 1

3.5.2 Diagramme d’interaction de cas d’utilisation modifier spécia-

lité
La figure suivante présente le diagramme d’interaction de cas d’utilisation modifier spécia-
lité :

Fig. 3.4 : Diagramme d’interaction modifier spécialité.

3.6 Conclusion
Dans ce chapitre, nous avons travaillé sur la production du premier sprint ”Espace adminis-
trateur” qui a été présenté lors d’une réunion de fin de livraison. Maintenant dans le chapitre
suivant, nous allons produire le deuxième livrable qui comprend des fonctionnalités telles que
la prescription des ordonnances, les servir, établir des bons de commande et les réceptionné,
gestion des patients

36
Chapitre 4

Release 2

4.1 Introduction
Dans ce chapitre, nous allons discuter du travail effectué lors de deuxième release du projet.
Ce release est constitué de plusieurs sprints qui ont été réalisés successivement.
Ces sprints sont :
Sprint 2 : Médicaments.
Sprint 3 : Espace médecin.
Sprint 4 : Servir ordonnance.
Sprint 5 : Stock des médicaments.
Sprint 6 : Ordonnances externes.
Pour chacun de ces sprints, nous avons élaboré des diagrammes de cas d’utilisation, des
descriptions textuelles et des diagrammes d’interaction pour illustrer les différentes fonction-
nalités et interactions du système. Ces artefacts fournissent une compréhension détaillée du
fonctionnement de l’application et servent de référence lors du développement et des tests.

4.2 Etude de sprint 2 : Médicaments

Dans ce sprint, une base de données complète des médicaments a été intégrée à l’application.
Le pharmacien chef peut rechercher des médicaments par leur nom, leur classe thérapeutique
ou leur code. Comme le pharmacien chef peut aussi ajouter de nouveau médicaments (DCI) ou
de nouveaux noms commerciaux.
Ce sprint s’est étalé sur 2 semaines, il comprend l’item : Gérer les DCIS et noms commerciaux

4.2.1 Diagramme de cas d’utilisation du sprint 2

Le diagramme de cas d’utilisation suivant présente les cas d’utilisation constituant les items
du deuxième sprint :

37
Chapitre 4. Release 2

Fig. 4.1 : Diagramme de cas d’utilisation de pharmacien chef pour la gestion des médicaments.

4.2.2 Description textuelle de cas d’utilisation ’Ajouter une DCI’

La figure suivante présente la description textuelle de cas qui permet d’ajouter une DCI :

CU : Ajouter une DCI.

BUT : Ce cas permet au pharmacien chef d’ajouter une nouvelle DCI.
Acteur principale : Pharmacien chef.
Acteur secondaire : /
Préconditions : Le pharmacien chef est déjà connecté à son espace.
Scénario nominal :
1. Le pharmacien chef demande le formulaire d’ajout.
2. Le système affiche le formulaire.
3. Le pharmacien chef remplit le formulaire.
4. Le pharmacien chef valide la syntaxe.
5. Le système vérifie le formulaire.
6. Le système ajoute la nouvelle DCI.
Enchainement alternatif :
5.a Si le formulaire est mal remplit, le système renvois un message d’erreur.
Reprendre à partir de 2.
Post condition : La DCI est ajoutée avec succès.
.
Tab. 4.2 : Description textuelle du cas d’utilisation ’ajouter une DCI’

38
Chapitre 4. Release 2

4.2.3 Diagramme d’interaction de cas d’utilisation ’Ajouter une DCI’.

La figure 4.2 présente le diagramme d’interaction de cas d’utilisation ’Ajouter une DCI’ par
le pharmacien chef :

Fig. 4.2 : Diagramme d’interaction ’Ajouter une DCI’.

4.3 Etude de sprint 3 : Espace médecin

Dans ce sprint Le médecin peut ajouter et rechercher des patients par leur nom, prénom
ou identifiant. Il peut également gérer les ordonnances en les ajoutant, les modifiant et les
imprimant pour les patients. De plus, le médecin a accès à une liste des médicaments disponibles
pour obtenir des informations pertinentes lors de la prescription. Ce sprint s’est étalé sur 2
semaines, il comprend les items :
Gérer les ordonnances.
Gérer les patients.
Consulter la liste des médicaments.

39
Chapitre 4. Release 2

4.3.1 Diagramme de cas d’utilisation du sprint 3

Ce diagramme de cas d’utilisation présente de manière générale les cas d’utilisation consti-
tuant les items du troisième sprint

Fig. 4.3 : Diagramme de cas d’utilisation de médecin.

4.3.2 Diagramme d’interaction de cas d’utilisation ’Rechercher pa-

tient’
La figure 4.4 présente le diagramme d’interaction de cas d’utilisation ’Rechercher patient’ :

40
Chapitre 4. Release 2

Fig. 4.4 : Diagramme d’interaction ’Rechercher patient’.

4.3.3 Diagramme d’interaction de cas d’utilisation ’Ajouter patient’

La figure suivante présente le diagramme d’interaction de cas d’utilisation ’Ajouter patient’ :

Fig. 4.5 : Diagramme d’interaction ’Ajouter patient’.

41
Chapitre 4. Release 2

4.3.4 Diagramme d’interaction de cas d’utilisation ’Rechercher mé-

dicament’
La figure suivante présente le diagramme d’interaction de cas d’utilisation ’Rechercher mé-
dicament’.

Fig. 4.6 : Diagramme d’interaction ’Rechercher médicament’.

4.3.5 Description textuelle de cas d’utilisation ’Prescrire une ordon-

nance’
La figure suivante présente la description textuelle de cas qui permet de prescrire une or-
donnance.

CU : Prescrire une ordonnance.

BUT : Ce cas permet au médecin de prescrire une ordonnance pour le patient.
Acteur principale : Médecin.
Acteur secondaire : /
Préconditions :
1. Le médecin doit être connecté à son compte.
2. Le patient doit être ajouté à la liste.
3. Le médicament doit être disponible dans la liste.

42
Chapitre 4. Release 2

Scénario nominal :
1. Le médecin demande le formulaire de prescription d’une ordonnance.
2. Le système affiche le formulaire.
3. Le médecin sélection le patient de la liste des patients.
4. Le médecin sélection les médicaments à prescrire en mentionnant la posologie et la durée
de traitement.
5. Le médecin valide la syntaxe.
6. Le système vérifier les champs du formulaire.
7. Le système ajoute la nouvelle ordonnance.
Enchainement alternatif :
5.a Si aucun patient n’est sélectionner, le système renvois un message d’erreur (veuillez
sélectionner un patient).
5.b Si aucun médicament n’est sélectionner, le système renvois un message d’erreur (veuillez
sélectionner un médicament).
5.c Si le formulaire est mal remplit, le système renvois un message d’erreur (veuillez remplir
les champs).
Reprendre à partir de 2.
Post condition : L’ordonnance est ajoutée avec succès.

Tab. 4.4 : Description textuelle du cas d’utilisation ’Prescrire une ordonnance’.

4.3.6 Diagramme d’interaction de cas d’utilisation ’Prescrire une

ordonnance’
La figure 4.7 présente le diagramme d’interaction de cas d’utilisation ’Prescrire une ordon-
nance’ par le médecin :

43
Chapitre 4. Release 2

Fig. 4.7 : Diagramme d’interaction ’Prescrire une ordonnance’.

NOTE :
-Requête1: Envoi de requête d’insertion au modèle ordonnances.
-Requête2: Envoi de requête d’insertion au modèle Ordonnance détaille.

4.4 Etude de sprint 4 : Servir ordonnance

L’objectif de ce sprint était de créer un espace dédié aux pharmaciens. Cet espace permet
aux pharmaciens de se connecter, de consulter les ordonnances des patients, de les servir et de
consulter les informations de chaque patient, médecin et service.
Ce sprint s’est étalé sur 3 semaines, il comprend 4 items :
Servir les ordonnances.
Consulter liste des patients.
Consulter liste des médecins.
Consulter liste des services.

4.4.1 Diagramme de cas d’utilisation de sprint 4

Ce diagramme de cas d’utilisation présente les cas d’utilisation constituant les items du
quatrième sprint :

44
Chapitre 4. Release 2

Fig. 4.8 : Diagramme de cas d’utilisation pharmacien pour les ordonnances.

4.4.2 Diagramme d’interaction de cas d’utilisation ’Rechercher or-

donnance’
La figure 4.9 présente le diagramme d’interaction de cas d’utilisation ’Rechercher ordon-
nance’ par le pharmacien.

45
Chapitre 4. Release 2

Fig. 4.9 : Diagramme d’interaction ’Rechercher ordonnance’.

4.4.3 Description textuelle de cas d’utilisation ’Servir ordonnance’

La figure suivante présente la description textuelle pour ’Servir une ordonnance’ :

CU : Servir ordonnance.
BUT : Ce cas permet au pharmacien de servir une ordonnance pour le patient.
Acteur principale : Pharmacien.
Acteur secondaire : /
Préconditions : L’ordonnance existe déjà dans la table.
Scénario nominal :
1. Le pharmacien demande la liste des ordonnances.
2. Le système affiche la liste des ordonnances.
3. Le pharmacien sélection l’ordonnance correspondante.
4. Le pharmacien saisit la quantité à servir.
5. Le pharmacien valide la syntaxe.
6. Le système vérifier les champs du formulaire .
7. Le système ajoute les nouvelles données.
Enchainement alternatif :

46
Chapitre 4. Release 2

4.a Si la quantité demandée est supérieure à la quantité disponible en stock, le pharmacien

saisit une date pour un prochain rendez-vous.
6.a Si le formulaire est mal remplit, le système affiche un message d’erreur (veuillez remplir
les champs).
Reprendre à partir de 4
Post condition : l’ordonnance est servie avec succès.

Tab. 4.6 : Description textuelle du cas d’utilisation ’Servir ordonnance’.

4.4.4 Diagramme d’interaction de cas d’utilisation servir ordonnance

La figure suivante présente le diagramme d’interaction de cas d’utilisation ’Servir ordon-
nance’ par le pharmacien :

Fig. 4.10 : Diagramme d’interaction ’Servir ordonnance’.

NOTE :

Requête 1: Envoi de requête d’insertion au modèle Ordonnance a servir.

Requête 2: Envoi de requête de modification au modèle ordonnance détaille.
Requête 3: Envoi de requête de modification au modèle noms commerciaux.

47
Chapitre 4. Release 2

Requête 4: Envoi de requête de modification au modèle Ligne bon de réception.

Requête 5:Envoi de requête de modification au modèle médicament ambulatoire.

4.5 Etude de sprint 5 : Gestion de stock

Ce sprint était axé sur la gestion des stocks de médicaments. Un système de suivi des stocks
a été mis en place, permettant de connaître la quantité de chaque médicament disponible. Les
pharmaciens peuvent vérifier la disponibilité d’un médicament avant de le servir, et le système
met à jour automatiquement les stocks en fonction des dispensations. Des bons de commandes
sont établis dans le cas d’un manque de médicament et les bons de livraisons sont réceptionnés
en fonction de chaque bon de commande.
Ce sprint s’est étalé sur 2 semaines, il comprend 3 items :
Gérer les bons de commandes.
Gérer les bons de réceptions.
Consulter le stock des médicaments

4.5.1 Diagramme de cas d’utilisation du sprint 5

Ce diagramme de cas d’utilisation présente les cas d’utilisation constituant les items du
cinquième sprint (figure 4.11) :

48
Chapitre 4. Release 2

Fig. 4.11 : Diagramme de cas d’utilisation de pharmacien pour la gestion de stock.

4.5.2 Description textuelle de cas d’utilisation ’Établir un bon de

commande’

CU : Ajouter bon de commande.

BUT : Ce cas permet au pharmacien d’ajouter un bon de commande des médicaments.
Acteur principale : Pharmacien.
Acteur secondaire : /
Pré-conditions :
- L’ordonnance existe déjà dans la table.
- Le médicament à commander existe déjà dans la table.
Scénario nominal :
1. Le pharmacien demande le formulaire pour ajouter un bon de commande.

49
Chapitre 4. Release 2

2. Le système affiche le formulaire.

3. Le pharmacien demande la liste des médicaments.
4. Le système affiche la liste des médicaments.
5. Le pharmacien sélection les médicaments et saisit la quantité a commandé de chaque
médicament.
6. Le pharmacien valide la syntaxe.
7. Le système vérifié le formulaire.
8. Le système ajoute le bon de commande à la base de données et affiche un message de
succès.
Enchaînement alternatif :
7.a aucun médicament n’est sélectionner, le système affiche un message d’erreur (veuillez
sélectionner un médicament).
7.b Si le formulaire est mal remplit, le système affiche un message d’erreur (veuillez remplir
les champs).
Reprendre à partir de 2.
Post condition : Bon de commande ajouter avec succès.

Tab. 4.8 : Description textuelle du cas d’utilisation ’Établir un bon de commande’.

4.5.3 Diagramme d’interaction de cas d’utilisation ’Établir un bon

de commande’
La figure suivante présente le diagramme d’interaction de cas d’utilisation ’Établir un bon
de commande’ par pharmacien :

50
Chapitre 4. Release 2

Fig. 4.12 : Diagramme d’interaction ’Établir un bon de commande’.

NOTE :
Requête 1: Envoi de requête d’insertion au modèle Bon de commandes.
Requête 2: Envoi de requête d’insertion au modèle Ligne bon de commandes.

4.5.4 Description textuelle de cas d’utilisation ’ajouter bon de ré-

ception’
La figure suivante présente la description textuelle de cas qui permet d’ajouter un bon de
réception :

CU : Ajouter un bon de réception.

BUT : Dans ce cas, le pharmacien peut ajouter un bon de réception en réceptionnant un
bon de commande afin de remplir le stock des médicaments.
Acteur principale : Pharmacien.
Acteur secondaire : /
Pré-conditions : Le bon de commande à réceptionner existe déjà dans la table.
Scénario nominal :
1. Le pharmacien demande la liste des bons de commandes.

51
Chapitre 4. Release 2

2. Le système affiche la liste des bons de commandes.

3. Le pharmacien sélection le bon de commande à réceptionner.
4. Le système remplir le formulaire avec les détails contenus dans le bon de commande.
5. Le pharmacien sélection pour chaque médicament commandé le nom commercial reçu.
6. Le pharmacien saisit les quantités reçues de chaque médicament, N° de lot et date pé-
remption.
7. Le système affiche pour chaque médicament la quantité restante à recevoir s’il n’a pas
reçu toute la quantité commandée.
8. Le pharmacien valide la syntaxe.
9. Le système vérifié le formulaire.
10. Le système ajoute le bon de réception à la base de données et affiche un message de
succès.
Enchaînement alternatif :
7.b le formulaire est mal remplit, le système affiche un message d’erreur (veuillez remplir les
champs).
Reprendre à partir de 4.
Post condition : Bon de réception ajouté avec succès.

Tab. 4.10 : Description textuelle du cas d’utilisation ’Ajouter bon de réception’.

52
Chapitre 4. Release 2

4.5.5 Diagramme d’interaction de cas d’utilisation ’Ajouter bon de

réception’
La figure suivante présente le diagramme d’interaction de cas d’utilisation ’Ajouter bon de
réception’ par pharmacien :

Fig. 4.13 : Diagramme d’interaction ’Ajouter bon de réception’.

NOTE :
Requête 1: Envoi de requête d’insertion au modèle Bon de réception.
Requête 2: Envoi de requête d’insertion au modèle Ligne bon de réception.

53
Chapitre 4. Release 2

4.6 Etude de sprint 6 : Ordonnance externe

Le dernier sprint de ce release était consacré à la gestion des ordonnances externes. Le
pharmacien chef dispose désormais de la capacité d’enregistrer des ordonnances provenant de
l’extérieur du CHU de Béjaïa en spécifiant les détails de l’ordonnance ainsi que ceux du pres-
cripteur.
Ce sprint s’est étalé sur 2 semaines, il comprend 3 items :
Gérer les ordonnances.
Gérer les patients.
Gérer les médecins externes.

4.6.1 Diagramme de cas d’utilisation du sprint 6

Ce diagramme de cas d’utilisation représente de manière générale les cas d’utilisation consti-
tuant les items du dernier sprint :

Fig. 4.14 : Diagramme de cas d’utilisation de pharmacien chef pour la gestion des ordonnances.

54
Chapitre 4. Release 2

4.6.2 Diagramme d’interaction ’Rechercher médecin externe’

La figure suivante présente le diagramme d’interaction ’Rechercher médecin externe’ :

Fig. 4.15 : Diagramme d’interaction ’Rechercher médecin externe’.

4.6.3 Diagramme d’interaction ’Ajouter médecin externe’

La figure suivante présente le diagramme d’interaction ’Ajouter médecin externe’ :

55
Chapitre 4. Release 2

Fig. 4.16 : Diagramme d’interaction ’Ajout médecin externe’.

4.6.4 Description textuelle de cas d’utilisation ajouter une ordon-

nance externe
La figure suivante présente la description textuelle de cas qui permet d’ajouter une ordon-
nance externe :

CU : Ajouter ordonnance externe.

BUT : Ce cas permet au pharmacien chef d’ajouter une ordonnance pour le patient venant
d’autres établissements.
Acteur principale : Pharmacien chef.
Acteur secondaire : /
Préconditions :
- Le pharmacien chef soit connecté à son compte.
- Le patient doit exister dans la liste.
- Le médecin externe doit exister dans la liste.
Scénario nominal :
1. Le pharmacien chef demande le formulaire d’ajout d’une ordonnance.
2. Le système affiche le formulaire.
3. Le pharmacien chef sélection le patient de la liste des patients.
4. Le pharmacien chef sélection le médecin prescrivant de la liste des médecins externe.

56
Chapitre 4. Release 2

5. Le pharmacien chef sélection les médicaments prescrits en mentionnant les quantités et la

durée de traitement.
6. Le pharmacien chef valide la syntaxe.
7. Le système vérifier les champs du formulaire.
8. Le système ajoute la nouvelle ordonnance
Enchainement alternatif :
7.a Si aucun patient n’est sélectionner, le système affiche un message d’erreur (veuillez sé-
lectionner un patient) .
7.b Si aucun médecin n’est sélectionner, le système affiche un message d’erreur (veuillez
sélectionner un médecin).
7.c Si aucun médicament n’est sélectionner, le système affiche un message d’erreur (veuillez
sélectionner un médicament).
7.d Si le formulaire est mal remplit, le système affiche un message d’erreur (veuillez remplir
les champs) .
Reprendre à partir de 2.
Post condition : L’ordonnance est ajoutée avec succès.

Tab. 4.12 : Description textuelle du cas d’utilisation ’Ajouter une ordonnance externe’.

4.6.5 Diagramme d’interaction de cas d’utilisation ’Ajouter une or-

donnance externe’
La figure suivante présente le diagramme d’interaction de cas d’utilisation ’Ajouter une
ordonnance externe’ par le pharmacien chef :

57
Chapitre 4. Release 2

Fig. 4.17 : Diagramme d’interaction ’Ajouter une ordonnance externe’.

NOTE :
Requête1: Envoi de requête d’insertion au modèle ordonnances.
Requête2: Envoi de requête d’insertion au modèle Ordonnance détaille.

4.7 Conclusion
Après avoir effectué les sprints et développé les fonctionnalités correspondantes, nous avons
réussi à produire un incrément répondant aux besoins du client.
Dans le chapitre suivant, nous aborderons la phase de réalisation du projet en mettant
l’accent sur l’environnement de développement et les outils utilisés. De plus, nous présenterons
quelques interfaces de l’application afin d’illustrer les fonctionnalités qui ont été réalisées.

58
Chapitre 5

Conception de la base de données

5.1 Introduction
Après avoir mené une analyse approfondie et spécifié les besoins dans les sprints Scrum
précédents, nous consacrons ce chapitre à l’exploration des règles de gestion. Ces règles de
gestion jouent un rôle crucial dans la conception et l’établissement de divers artefacts tels que
le diagramme de classes, le dictionnaire de données et le modèle relationnel.

5.2 Règles de gestion

Pour créer notre diagramme de classe compréhensible, cohérent et conforme aux besoins du
système, voici quelques règles de gestion que nous avons suivies :

• Un utilisateur peut être l’administrateur, le pharmacien chef, un médecin et un pharma-

cien,

• Un médecin a une spécialité et il est affecté à un seul service,

• Plusieurs médecins peuvent avoir la même spécialité,

• Plusieurs médecins peuvent appartenir au même service,

• Un médicament possède plusieurs noms commerciaux,

• Un médicament est classé en plusieurs classes thérapeutiques selon les spécialités,

• Un nom commercial appartient à un seul médicament,

• Un patient est ajouté une seule fois soit par un médecin où par le pharmacien-chef,

• Une ordonnance est prescrite soit par un médecin du CHU ou par un médecin externe au
CHU,

• Une ordonnance est délivrer au nom d’un seul patient et un patient peut avoir plusieurs
ordonnances,

• Une ordonnance comporte un ou plusieurs médicaments,

59
Chapitre 5. Conception de la base de données

• Un médicament peut être prescrit dans plusieurs ordonnances,

• Une ordonnance peut être servie plusieurs fois,

• Un pharmacien établit un ou plusieurs bons de commande et un bon de commande est

établit par un seul pharmacien,

• Un médicament peut être commandé dans plusieurs bons de commandes,

• Un bon de commande comporte plusieurs médicaments,

• Un bon de réception concerne plusieurs bons de commandes,

• Un médicament peut être réceptionné dans plusieurs bons de réceptions.

5.3 Diagramme de classe

Un diagramme de classe est un type de diagramme de modélisation utilisé en génie logiciel
pour représenter la structure statique d’un système ou d’une application. Il montre les classes du
système, leurs attributs, leurs méthodes et leurs relations avec d’autres classes. Les diagrammes
de classe aident à visualiser la structure du système, à identifier les classes clés, leurs attributs et
leurs relations, et à faciliter la communication entre les membres de l’équipe de développement.
Ils servent également de base pour l’implémentation du code source, en fournissant un guide
clair pour la construction des classes et de leurs fonctionnalités [3].
Dans ce contexte la notation XOR (ou Exclusif OR) est utilisée pour représenter une relation
de choix exclusif entre deux classes. Elle indique qu’un objet peut être associé soit à une classe,
soit à une autre, mais pas aux deux en même temps [12] [2]. Voici le diagramme de classe de
notre projet :

60
Chapitre 5. Conception de la base de données

Fig. 5.1 : Diagramme de classe.

61
Chapitre 5. Conception de la base de données

5.4 Dictionnaire de données

Table Les données Attribut Type Observation

Identifiant de l’utilisateur id_user BigInteger

Nom de l’utilisateur username BigInteger
Mot de passe password Varchar(50)
Utilisateur
Rôle de l’utilisateur role Char(1) A/P/C/M

L’état de compte active Booléen 0/1

Date de création created_at Date

Date de la dernière modification updated_at Date

Chef Identifiant de pharmacien chef id_chef Varchar(25)

Pharmacien Identifiant pharmacien id_pharmacien Varchar(25)

Identifiant de Médecin id_medecin Varchar(25)
Nom de médecin nom Varchar(50)
Médecin Prénom de médecin prenom Varchar(50)
Email de médecin email Varchar(100)
Numéro de téléphone de médecin numTel Varchar(50)
Date de la dernière modification updated_at Date
Identifiant de service id_service Varchar(25)
Nom de service nomService Varchar(50)
Service
La griffe griffe Varchar(50)
Date de création created_at Date
Date de modification updated_at Date
Identifiant de spécialité id_specialite Varchar(25)
Nom de spécialité nomSpecialite Varchar(50)
Spécialité
La spécialité de médecin metier Varchar(50)
Date de création created_at Date
Date de la dernière modification updated_at Date

62
Chapitre 5. Conception de la base de données

Identifiant du patient id_patient Varchar(25)

Nom de patient nomPatient Varchar(50)
Prénom du patient prenomPatient Varchar(50)
Age du patient age Integer
Sexe du patient sexe char(1) M/F

Patient Poids du patient poids float

Commune résidence commune_resi Varchar(50)
Daïra résidence daira_resi Varchar(50)
Wilaya résidence wilaya_resi Varchar(50)
Numéro téléphone du patient num_tel Varchar(50)
Antécédents antecedent Varchar(50)
Date de création created_at Date
Date de la dernière modification updated_at Date
Identifiant de Médecin Externe id_med_externe Varchar(25)

Médecin Nom de médecin nom Varchar(50)

Externe Prénom de médecin prenom Varchar(50)

Service service Varchar(50)
Spécialité specialité Varchar(50)
Etablissement etablissement Varchar(50)
Date de création created_at Date
Date de la dernière modification updated_at Date
Identifiant du l’ordonnance id_ord Varchar(25)
L’état de l’ordonnance etat Varchar(10)
Ordonnance
Image de l’ordonnance image Varchar(50)
Date de création created_at Date
Date de la dernière modification updated_at Date
Identifiant de la DCI id_medic BigInteger

Médicament La DCI dci Varchar(50)

_ambu La forme forme Varchar(50)

63
Chapitre 5. Conception de la base de données

Le dosage dosage Varchar(50)

Quantité en stock total quantite_stock Integer
Quantité minimale quantite_min Integer
Date de création created_at Date
Date de la dernière modification updated_at Date
Identifiant du médicament id_commerc Varchar(25)

Nom Nom commercial nomCommerc Varchar(50)

commercial
Quantité en stock quantite_stock Integer
Date de création created_at Date
Date de la dernière modification updated_at Date
Quantité à prendre de médicament quantite Integer

Ordonnance Posologie posologie Varchar(50)

détaillé
Durée de traitement duree Varchar(50)
Quantité restante a servir quantite_restante Varchar(50)
Date de la dernière modification updated_at Date
Identifiant de l’ordonnance servie id_ord_serv Integer

Ordonnance Quantité servie du médicament quantite_servir Integer

servie
Rendez vous rdv date
Date de création created_at Date
Date de la dernière modification updated_at Date
Identifiant bon de commande id_bc BigInteger
Bon de
commande Date de création created_at Date
Date de la dernière modification updated_at Date
Quantité commandée de médicament qnt_commande Integer
Ligne bon Quantité restante à recevoir quantite_restante Integer

commande Date de la dernière modification updated_at Date

Identifiant bon de réception id_br BigInteger

Bon de Identifiant de bon de livraison id_bl Varchar(30)

réception
Date de bon de livraison datebl date

64
Chapitre 5. Conception de la base de données

Date de création created_at Date

Date de modification updated_at Date
Quantité reçue de médicament quantite_recue Integer

Ligne bon Numéro de lot n_lot Varchar(30)

reception
Date de péremption date_peremtion Date
Quantité restante à consommer quantite_ Integer

consomme
Date de la dernière modification updated_at Date

5.5 Schéma relationnel

5.5.1 Les règles de passage du diagramme de classe vers modèle

relationnel
Lors du passage du diagramme de classe vers le modèle relationnel, certaines règles doivent
être suivies pour garantir une représentation cohérente et correcte des données. Voici les règles
générales à prendre en compte :

• Classe vers Table : Chaque classe du diagramme de classe est généralement représentée
par une table dans le modèle relationnel. Le nom de la table est généralement le même
que celui de la classe.

• Attributs vers Colonnes : Chaque attribut d’une classe est généralement représenté
par une colonne dans la table correspondante. Le nom de la colonne est généralement le
même que celui de l’attribut.

• Clé primaire : L’identification de la clé primaire est essentielle pour chaque table. Dans
le modèle relationnel, les attributs qui forment la clé primaire de la table sont définis
comme clés primaires.

• Relations un-à-un : Si une relation un-à-un existe entre deux classes dans le diagramme
de classe, cela peut être représenté en incluant la clé primaire d’une classe comme clé
étrangère dans l’autre classe. Cela établit une relation entre les deux tables correspon-
dantes.

• Relations un-à-plusieurs : Si une relation un-à-plusieurs existe entre deux classes, cela
peut être représenté en incluant la clé primaire de la classe ”un” comme clé étrangère
dans la classe ”plusieurs”. Cela permet à la classe ”plusieurs” de faire référence à la classe
”un”.

• ‘Relations plusieurs-à-plusieurs : Si une relation plusieurs-à-plusieurs existe entre

deux classes, cela nécessite généralement une table de jointure supplémentaire. Cette
table de jointure contient les clés primaires des deux classes en tant que clés étrangères,
ce qui permet d’établir une relation entre les enregistrements des deux tables.

65
Chapitre 5. Conception de la base de données

• Transformation de l’héritage Trois décompositions sont possibles pour traduire une asso-
ciation d’héritage en fonction des contraintes existantes :

– Décomposition par distinction : Il faut transformer chaque sous-classe en une

relation, la clé primaire de la surclasse, migre dans la relation issue de la sous-
classe(s) et devient à la fois clé primaire et clé étrangère.
– Décomposition descendante : S’il existe une contrainte de totalité ou de partition
sur l’association d’héritage, il est possible de ne pas traduire la relation issue de la
surclasse. Il faut alors faire migrer tous ses attributs dans la (les) relation(s) issue(s)
de la (des) sous-classe(s).
– Décomposition ascendante : Il faut supprimer la relation issue de la sous-classe
et faire migrer les attributs dans la relation issue de la surclasse.

5.5.2 Modele relationnel

Dans le contexte de notre conception, nous avons obtenu le schéma relationnel suivant :

• Utilisateur (id_user, username, password, role, active,created_at,update_at).

• Pharmacien chef (id_chef, #id_user).

• Pharmacien (id_pharmacien, #id_user).

• Service (id_service, service, griffe,created_at,update_at).

• Spécialité (id_specialite, specialite, metier,created_at,update_at).

• Médecin (id_medcin, #id_user, nom_med, prenom_med, email, numel, created_at, up-

date_at, #id_service, #id_specialite, ).

• Médecin externe (id_med_ext, nom, prenom, service, specialite, etablissement, crea-

ted_at, update_at).

• Patient (id_patient, nom_patient, prenom_patient, age, poids, sexe, commune_resi,

daira_resi, wilaya_resi, num_tele, antecedent, chef_id, medecin_id, created_at, up-
date_at, ).

• Médicament (id_medic, dci, forme, dosage, quantite_stock, quantite_minimale, crea-

ted_at, update_at).

• Classe_thera(#id_medic, #id_specialite).

• Nom commercial (id_commerc, nom_commercial ,quantite_stock_medic, created_at,

update_at, #id_medic).

• Ordonnance (id_ord, etat, image_ord, created_at, update_at, #id_medecin, #id_medecin_ext,

#id patient).

• Ordonnance_detaille (#id_ord, #id_commerc, quantite, posologie, duree, update_at) .

• Ordonnance_a_servir (id_ord_servie, quantite_servi, date_servi, quantite_restante, crea-

ted_at, update_at, #id_ord, #id_commerc).

66
Chapitre 5. Conception de la base de données

• BonCommandes (id_bc, created_at, update_at, #id_user)

• Ligne_BonCommande (#id_medic, #id_bc, quantite_commande, quantite_restante,

update_at).

• Bon_Reception (id_br, created_at, id_bl, data_bl, quantite_consomme, created_at,

update_at, #id_bc).

• Ligne_BonReception (#id_br, #id_quantite_recu, n_lot, date_peremption, update_at).

5.6 Conclusion
En conclusion, les règles de gestion, le diagramme de classes, le dictionnaire de données
et le modèle relationnel ont joué un rôle fondamental dans la création de notre application.
Ces outils ont permis une conception précise et structurée, en garantissant sa cohérence et sa
conformité aux besoins spécifiés.

67
Chapitre 6

Réalisation

6.1 Introduction
Dans ce chapitre, nous aborderons la réalisation de l’application, en mettant l’accent sur
l’environnement de développement et les outils utilisés. Nous présenterons également des in-
terfaces de l’application pour illustrer les fonctionnalités implémentées, offrant ainsi une vision
concrète de son apparence et de son fonctionnement.

6.2 Langages, environnement et outils de développement

HTML CSS

HTML1 (le langage de balisage hypertexte) et CSS (feuilles

de style en cascade) sont deux des technologies de base pour la
construction de pages web. HTML fournit la structure de la page,
CSS la mise en page (visuelle et auditive) pour une variété d’ap-
pareils. En plus des graphiques et du script, HTML et CSS sont
la base de la création de pages web et d’applications web. Fig. 6.1 : Logo de HTML
CSS.

Bootstrap

Bootstrap2 est un framework CSS (et JavaScript) open-source

largement utilisé pour le développement web. Il fournit une collec-
tion de styles prédéfinis, de composants réutilisables et de scripts
JavaScript pour faciliter la création de sites web réactifs, esthé-
tiques et conviviaux.

Fig. 6.2 : Logo de Boots-

trap.
1
[Link] (visité le 15/05/2023).
2
[Link] (visité le 15/05/2023).

68
Chapitre 6. Réalisation

Javascript

JavaScript3 est un langage de programmation utilisé pour

créer des fonctionnalités interactives sur les sites web. Il permet
de manipuler le contenu de la page, de réagir aux actions des
utilisateurs et d’effectuer des opérations complexes côté client.

Fig. 6.3 : Logo de Javas-

[Link] cript.

[Link] 4 est un framework JavaScript pour la création d’inter-

faces utilisateur interactives. Il permet de construire des applica-
tions web à l’aide d’un modèle de programmation déclaratif basé
sur des composants. Le principal objectif de [Link] de fournir une
approche intuitive et efficace pour la gestion de l’état de l’applica-
tion et la manipulation du DOM. Il utilise les standards HTML,
CSS et JavaScript existants, ce qui facilite l’apprentissage et l’in- Fig. 6.4 : Logo de Vue js.
tégration dans des projets existants. Il permet aussi de créer des composants réutilisables et
modulaires. Chaque composant encapsule sa propre logique, son état et son rendu, ce qui facilite
la maintenance et la compréhension du code. [Link] prend également en charge la réactivité
des données, ce qui signifie que les modifications apportées aux données sont automatiquement
reflétées dans l’interface utilisateur, sans nécessiter de manipulation directe du DOM.

PHP

Php5 (Hypertext Preprocessor) est un langage de program-

mation côté serveur très populaire, largement utilisé pour le dé-
veloppement web. Il est principalement conçu pour générer du
contenu dynamique et interagir avec des bases de données, mais
il peut également être utilisé pour développer des applications en
ligne de commande.
Fig. 6.5 : Logo de PHP.
Laravel

Laravel6 est un framework open source de développement

d’applications web écrit en PHP. Laravel suit le modèle de
conception MVC (Modèle-Vue-Contrôleur) et offre une large
gamme de fonctionnalités pour faciliter le développement web.
Voici quelques caractéristiques clés de Laravel :
3
Fig. 6.6 : Logo de Laravel.
[Link] (visité le 17/05/2023).
4
[Link] (visité le 17/05/2023).
5
[Link] (visité le 20/05/2023).
6
[Link] (visité le 20/05/2023).

69
Chapitre 6. Réalisation

• Syntaxe élégante et expressive : Laravel propose une syntaxe claire et concise, ce qui
facilite la lecture et l’écriture du code. Il met l’accent sur la simplicité et la lisibilité du
code.

• Architecture MVC : Laravel suit le modèle de conception MVC, ce qui permet de sé-
parer le logique métier (Modèle), la présentation (Vue) et la gestion des requêtes (Contrô-
leur). Cela favorise une meilleure organisation et une maintenance plus aisée du code.

• Système de routage : Laravel offre un système de routage flexible qui permet de définir
facilement les différentes routes de l’application, et d’associer ces routes à des actions
spécifiques.

• Gestion des sessions et de l’authentification :cLaravel propose des fonctionnalités

intégrées pour gérer les sessions utilisateur et l’authentification. Il facilite la mise en
place de l’authentification avec des fonctionnalités telles que l’inscription, la connexion,
la réinitialisation des mots de passe, etc.

• Cryptage des cookies et des sessions : Laravel prend en charge le cryptage des cookies
et des sessions, ce qui garantit que les informations sensibles stockées sur le client ou le
serveur sont sécurisées et ne peuvent pas être facilement compromises.

[Link]

[Link] 7 est une bibliothèque JavaScript qui permet de

construire des applications web avec une expérience utilisateur
fluide et sans rafraîchissement de page, tout en conservant les
avantages d’une architecture côté serveur. Voici un résumé des
principales caractéristiques d’Inertia :
Fig. 6.7 : Logo de Inertia js.
• Sans rafraîchissement de page : Inertia permet de créer des applications web avec
une navigation sans rafraîchissement de page, ce qui signifie que les utilisateurs peuvent
interagir avec l’application sans subir de chargements de page longs et désagréables.

• Utilisation des frameworks côté serveur : Inertia est conçu pour fonctionner avec les
frameworks côté serveur populaires tels que Laravel, Rails, Django, etc. Il utilise le modèle
de rendu côté serveur pour générer les vues initiales et gérer les actions côté serveur.

• Communication via JSON : Les requêtes d’Inertia sont effectuées via AJAX en uti-
lisant JSON comme format de communication. Les réponses JSON contiennent le rendu
des composants et les données nécessaires pour mettre à jour la page côté client. Pro-
grammation déclarative : Inertia encourage une programmation déclarative en utilisant
des composants réutilisables. Vous pouvez créer des composants Inertia qui représentent
différentes parties de votre application et les utiliser pour gérer l’état et l’interaction
utilisateur.

7
[Link] (visité le 22/05/2023).

70
Chapitre 6. Réalisation

• Interopérabilité avec les frameworks front-end : Inertia s’intègre avec les frame-
works front-end populaires tels que [Link], React, Svelte, etc. Vous pouvez continuer à
utiliser vos outils et bibliothèques préférés pour la partie front-end de votre application.

En résumé, Inertia est une solution qui permet de construire des applications web monopages
sans rafraîchissement de page, en utilisant des frameworks côté serveur existants et en tirant
parti de la programmation déclarative et de l’interopérabilité avec les frameworks front-end.
Cela permet de créer des applications web plus fluides et réactives avec une expérience utilisa-
teur améliorée.

MySQL

MySQL8 est un système de gestion de bases de données rela-

tionnelles (SGBDR). Il est conçu pour stocker, gérer et récupérer
efficacement de grandes quantités de données. Il utilise le langage
de requête structuré (SQL) pour effectuer des opérations telles
que la création, la modification et la consultation de données dans
les bases de données. Fig. 6.8 : Logo de MySQL.

MAMP

MAMP9 est une solution logicielle qui permet de créer un en-

vironnement de développement local sur votre ordinateur. L’acro-
nyme MAMP signifie Macintosh, Apache, MySQL et PHP, qui
sont les composants principaux inclus dans le package. Avec
MAMP, vous pouvez installer facilement un serveur web Apache,
une base de données MySQL et le langage de programmation
PHP sur votre machine. Cela vous permet de développer, tester Fig. 6.9 : Logo de MAMP.
et déployer des sites web et des applications web localement sans
avoir besoin d’une connexion Internet.

Visual Studio Code

VSCode10 (Visual Studio Code) est un éditeur de code source

léger et puissant développé par Microsoft. Il offre une interface
utilisateur conviviale et une prise en charge étendue de nombreux
langages de programmation. Grâce à sa flexibilité et à son éco-
système d’extensions riche, VS Code permet aux développeurs de
personnaliser leur environnement de développement selon leurs
Fig. 6.10 : Logo de Visual
besoins.
Studio Code .
8
[Link] (visité le 20/05/2023).
9
[Link] (visité le 20/05/2023).
10
[Link] (visité le 25/05/2023).

71
Chapitre 6. Réalisation

GitHub

GitHub11 Desktop est une application de bureau développée

par GitHub qui facilite la gestion et la collaboration sur des pro-
jets hébergés sur la plateforme GitHub. C’est une interface gra-
phique conviviale qui simplifie les tâches courantes liées à Git,
telles que la création, le clonage, la gestion des branches, le suivi
des modifications et la gestion des conflits.
Fig. 6.11 : Logo de GitHub
Desktop .
Scrumblr

Scrumblr12 est une plateforme qui facilite la gestion de projets

basée sur la méthodologie Scrum, offrant des fonctionnalités spé-
cifiques pour la planification, le suivi et la collaboration. Elle aide
les équipes à adopter une approche agile dans leur développement
logiciel, la gestion des backlogs et des user stories,favorisant ainsi
l’efficacité et la livraison.
Fig. 6.12 : Logo de Scrum-
blr .
Visual Paradigm

Visual Paradigm 13 Online est une plateforme de modélisation

et de conception en ligne qui permet aux équipes de travailler de
manière collaborative sur des diagrammes et des modèles visuels.
Cette plateforme offre un large éventail d’outils de modélisation,
tels que les diagrammes UML, les diagrammes de flux, les dia-
grammes ER, les diagrammes de cas d’utilisation, les diagrammes
Fig. 6.13 : Logo de Visual
de classes, et bien plus encore. Avec Visual Paradigm Online, les
Paradigmr .
utilisateurs peuvent créer, éditer et partager des diagrammes di-
rectement dans leur navigateur web. La plateforme propose une
interface utilisateur conviviale et intuitive, facilitant la création
et la modification de modèles visuels.

Figma

Figma 14 est une plateforme de conception d’interfaces utili-

sateur (UI) basée sur le cloud. Elle permet aux designers et aux
équipes de collaborer efficacement sur la création, la conception et

11
[Link] (visité le 25/05/2023).
12
[Link] (visité le 30/05/2023).
13
[Link] (visité le 30/05/2023).
Fig. 6.14 : Logo de Figma.
14
[Link] (visité le 01/06/2023).

72
Chapitre 6. Réalisation

le prototypage d’interfaces utilisateur interactives pour des appli-

cations web, mobiles et autres. Illustrateur permet aussi de créer
des prototypes interactifs, ce qui facilite la démonstration des in-
teractions entre les différentes interfaces et fonctionnalités. Les
concepteurs peuvent ajouter des transitions, des animations et
des liens interactifs pour simuler l’expérience utilisateur réelle.

Illustrator

Illustrator 15 est un logiciel de création graphique vectorielle

développé par Adobe. Il est largement utilisé par les designers,
les graphistes et les professionnels de la création pour la concep-
tion de logos, d’illustrations, d’infographies, de typographies et
Fig. 6.15 : Logo de Illustra-
d’autres éléments graphiques.
tor.

6.3 Sécurité de l’application grâce à l’authentification et

l’autorisation

Fig. 6.16 : Schéma représente les fonctionnalités de la sécurité.

• L’authentification : Vise à vérifier l’identité d’un utilisateur en lui demandant de fournir

des informations d’identification spécifiques. Cela permet de s’assurer que la personne
prétendant être un utilisateur donné est effectivement cette personne.

• L’autorisation : Le processus par lequel un système ou une application vérifie les per-
missions d’un utilisateur authentifié pour accéder à certaines pages, ressources ou fonc-
tionnalités.

15
[Link] (visité le 01/06/2023).

73
Chapitre 6. Réalisation

• L’authentification par session : Des cookies sont souvent utilisés pour stocker les
informations de session côté client, c’est-à-dire dans le navigateur de l’utilisateur. Ces
cookies sont utilisés pour maintenir l’identifiant de session, qui est ensuite envoyé avec
chaque requête pour permettre au serveur d’authentifier l’utilisateur.

6.4 Présentation des interfaces

Dans ce qui suit, nous présentons quelques interfaces de notre application ”OrdoTrack”

74
Chapitre 6. Réalisation

6.4.1 Interface de login

La figure suivante présente l’interface le login de notre application web :

Fig. 6.17 : Interface de connexion.

6.4.2 Interface de tableau de bord

La figure suivante présente l’interface le tableau de bord de pharmacien chef :

Fig. 6.18 : Interface de tableau de bord.

75
Chapitre 6. Réalisation

6.4.3 Interface de la liste des services

La figure suivante présente la liste des services du CHU :

Fig. 6.19 : Interface liste des services.

6.4.4 Interface d’ajout d’un compte

La figure suivante présente l’interface de création de compte pharmacien chef :

Fig. 6.20 : Interface créer un compte pharmacien chef.

76
Chapitre 6. Réalisation

La figure suivante présente l’interface de création de compte pharmacien :

Fig. 6.21 : Interface créer un compte pharmacien.

La figure suivante présente l’interface de création de compte médecin :

Fig. 6.22 : Interface créer un compte médecin.

77
Chapitre 6. Réalisation

6.4.5 Interface d’ajout des médicaments

L’interface ci-dessous présente l’ajout de nouvelle DCI :

Fig. 6.23 : Interface ajouter une DCI.

6.4.6 Interface d’ajout d’un patient

La figure ci-dessous présente l’interface d’ajout d’un nouveau patient :

Fig. 6.24 : Interface ajouter un patient.

78
Chapitre 6. Réalisation

6.4.7 Interface d’ajout d’une ordonnance

Les figures suivantes présentent les étapes d’ajout d’une nouvelle ordonnance
La figure suivante présente l’interface de sélectionne de patient et médicaments :

Fig. 6.25 : Interface sélectionne de patient et médicaments pour l’ordonnace.

La figure suivante présente l’interface de remplissage des champs posologie et durée de

traitement :

Fig. 6.26 : Interface de remplissage des champs pour l’ordonnance.

79
Chapitre 6. Réalisation

6.4.8 Interface d’impression d’une ordonnance

La figure suivante présente l’interface de l’impression d’une ordonnance :

Fig. 6.27 : Interface imprimer une ordonnance.

6.4.9 Interfaces liste des ordonnances

La figure suivante présente les listes des ordonnances :

Fig. 6.28 : Interface de la liste des ordonnances.

80
Chapitre 6. Réalisation

6.4.10 Interfaces de servir une ordonnance

La figure suivante présente l’interface pour servir une ordonnance :

Fig. 6.29 : Interfaces de servir une ordonnance.

La figure suivante présente les détails de la délivrance :

Fig. 6.30 : Interface des détails de la délivrance de l’ordonnance.

81
Chapitre 6. Réalisation

6.4.11 Interfaces des bons de commandes.

Les figures suivantes présentent l’ajout d’un bon de commande et l’affichage de ses détails.

La figure suivante présente l’interface d’ajout d’un bon de commande :

Fig. 6.31 : Interface ajouter un bon de commande.

La figure suivante présente l’interface d’affichage de bon de commande :

Fig. 6.32 : Interface afficher un bon de commande.

82
Chapitre 6. Réalisation

6.4.12 Interface des bons de réceptions

Les figures suivantes présentent la réception d’un bon de commande et l’affichage de bon
de réception.

La figure suivante présente l’interface pour réceptionner un bon de commande :

Fig. 6.33 : Interface réceptionner un bon de commande.

La figure suivante présente l’interface d’affichage de bon de réception :

Fig. 6.34 : Interface afficher un bon de réception

83
Chapitre 6. Réalisation

6.4.13 Interface d’affichage de stock des médicaments

La figure suivante présente l’interface d’affichage des quantités en stock des DCIs et noms
commerciaux :

Fig. 6.35 : Interface afficher stock des médicaments

La figure suivante présente l’interface d’affichage des quantités en stock pour chaque lot
d’un nom commercial :

Fig. 6.36 : Interface afficher état de stock

84
Chapitre 6. Réalisation

6.4.14 Interface d’ajout d’un médecin externe

La figure ci-dessous illustre l’interface permettant d’ajouter un médecin d’un établissement

externe :

Fig. 6.37 : Interface ajouter un médecin externe.

6.4.15 Interface d’ajout d’une ordonnance externe

La figure suivante présente l’interface d’ajout une ordonnance externe :

Fig. 6.38 : Interface détails de l’ordonnance externe.

85
Chapitre 6. Réalisation

6.5 Conclusion
Dans ce chapitre, nous avons abordé les aspects pratiques liés à la création de notre appli-
cation web. Nous avons discuté des outils et des langages de développement nécessaires pour
garantir le bon fonctionnement de l’application. Et nous avons présenté des exemples concrets
des interfaces graphiques de notre application ’OrdoTrack’, permettant d’illustrer visuellement
les fonctionnalités mises en place.

86
Conclusion et perspectives

Conclusion générale
Notre projet consiste à réaliser une application web appelée ”OrdoTrack” pour la gestion et
le suivi des ordonnances au sein du CHU Bejaia, plus précisément à la pharmacie principale.
Nous avons réussi à concevoir cette application de qualité grâce à l’utilisation de la méthodologie
Agile, notamment la méthode SCRUM, pour la gestion de notre projet. Les besoins fonctionnels
ont été définis par le responsable du produit sous forme d’un backlog de produit que nous avons
réparti en sprints. De plus, nous avons utilisé le langage UML pour modéliser les différents
aspects et fonctionnalités de l’application.
La solution que nous avons réalisée permet aux médecins du CHU de Béjaia d’enregistrer
les coordonnées des patients et de leurs délivrer facilement des ordonnances électroniques. Elle
offre également aux pharmaciens la possibilité de sauvegarder les détails de chaque délivrance,
y compris la quantité fournie de chaque médicament, la date de la délivrance, ainsi que les infor-
mations relatives aux rendez-vous éventuels. Cela permet un accès rapide à ces informations en
cas de besoin. Ainsi, notre application garantit un mécanisme de gestion et de réapprovision-
nement des stocks. Enfin, ”OrdoTrack” offre également la fonctionnalité au pharmacien-chef
d’enregistrer les ordonnances provenant de médecins externes au CHU.
Bien que nous ayons atteint les objectifs initiaux, il existe des perspectives pour enrichir
davantage notre application. Parmi celles-ci, on peut mentionner :

• Ajouter un système de notifications et de messagerie entre les médecins et la pharmacie.

• Améliorer la gestion du stock des médicaments en incluant les prix et les fournisseurs
externes.
• Intégrer un système d’archivage de données.
• Intégrer le numéro de sécurité sociale de la Carte Chiffa pour améliorer l’identification
des patients et la gestion des données médicales.

Nous tenons à souligner l’importance de cette réalisation, qui répond à un besoin concret dans le
domaine de la santé en améliorant la gestion des ordonnances et en contribuant à une meilleure
prise en charge des patients.
La réalisation d’OrdoTrack a été une expérience très intéressante et enrichissante pour nous.
Elle nous a permis d’appliquer les connaissances et compétences que nous avons acquises tout au
long de notre parcours, notamment dans les domaines de la conception, de la programmation
et de l’application de méthodes de travail. Bien que cela ait parfois été difficile, nous avons
pu apprendre de nouvelles choses qui seront certainement utiles dans notre future carrière
professionnelle.

87
Bibliographie

[1] Kim Colard. Une charte graphique : qu’est-ce que c’est et à quoi ça sert ? fr. 2020. url :
[Link]
(visité le 24/03/2023).
[2] Kirill Fakhroutdinov. UML Constraint. en. 2009. url : [Link]
org/[Link] (visité le 10/03/2023).
[3] Jim Rumbaugh Grady Booch et Jackobson. Uml : Unified modeling language. 1997.
[4] Rafael Hernandez. The Model View Controller Pattern MVC Architecture and Frame-
works Explained. en. Avr. 2021. url : [Link]
model-view-controller-pattern-mvc-architecture-and-frameworks-explained/
(visité le 03/03/2023).
[5] Historique du CHU de béjaia. fr. 2014. url : [Link]
_CR (visité le 27/02/2023).
[6] Jeff Sutherland Ken Schwaber. The Scrum Guide. en. Nov. 2020.
[7] Sarah Laoyan. What is Agile methodology ? en. Oct. 2022. url : [Link]
resources/agile-methodology (visité le 15/03/2023).
[8] Missions et valeurs. fr. 2014. url : https : / / www . chubejaia . dz / MetV (visité le
27/02/2023).
[9] Organigramme du CHU de bejaia. fr. 2014. url : https : / / www . chubejaia . dz /
OrganigrammeCHU (visité le 27/02/2023).
[10] Jean François Pillou. CHU - Centre hospitalier universitaire - Définition. fr. 2016.
url : [Link] [Link]/faq/17626- chu- centre-
hospitalier-universitaire-definition (visité le 24/02/2023).
[11] Max Rehkopf. User stories avec des exemples et un modèle. fr. url : [Link]
[Link]/fr/agile/project-management/user-stories (visité le 28/04/2023).
[12] Stéphane Crozat (Contributions : Benjamin Lussier Antoine Vincent). “Expression de
contraintes avancées”. fr. In : Medium (), p. 30.
[13] [Link]. EPIPHARMLogiciel de gestion des médicaments et produits pharmaceu-
tiques. fr. 1998, p. 71.

88
Annexes

89
Annexe A

Structure du CHU de Béjaia

A.1 La structure du CHU

Le CHU de Bejaia est reparti sur trois unités qui sont dirigées par des organes de décision
et de consultation.
Le CHU comprend une direction générale, un secrétariat général, conseil scientifique, comité
consultatif et 3 unités. Chaque unité comprend un ensemble de directions et sous directions.

A.1.1 Organes de décision et consultatif

La direction générale

Est chargée d’assurer la gestion de l’hôpital. Elle représente l’hôpital dans tous les actes de
la vie civile, elle est le représentant exclusif de l’hôpital auprès des instances civiles, judiciaires
et administratives.

Le secrétariat général

Est chargé de gérer les différentes sous directions et les différents bureaux. C’est lui qui
récolte et transmet les informations à la direction générale.

Le conseil scientifique

Propose toutes mesures de nature à améliorer l’organisation et le fonctionnement des ser-

vices de soins et de prévention, la répartition des personnels, en relation avec les activités des
services, l’élaboration des programmes de formation et de recherche en science médicales et
évalue l’activité des services en matière de soins, de formation et de recherche. Le conseil scien-
tifique peut être saisi par le directeur général du centre hospitalo-universitaire de toute question
à caractère médical, scientifique ou de formation.

Comité consultatif

Est composé de trois commissions notamment

90
Annexe A. Structure du CHU de Béjaia

• Commission des affaires économiques et budgétaires.

• Commission des évacuations sanitaires.

• Commission chargée de la question d’organisation médicale.

A.1.2 Les unités et leurs services

Nous présentons ci-dessus la liste des services offerts par chaque unité du CHU.

L’unité Khelil Amrane :

Comporte les services suivants

Anesthésie et réanimation, cardiologie, chirurgie générale, épidémiologie et médecine pré-
ventive, gastro-entérologie, laboratoire central, maladies infectieuses, médecine interne, neuro-
chirurgie, orthopédie rhumatologie et urgence médicales.

L’unité Frantz Fanon :

Comporte les services suivants

Anatomie pathologique, maxillo-faciale, médecine de travail, médecine légale, oto-rhino-
laryngologie, néphrologie hémodialyse et psychiatrie.

L’unité Targua Ouzemmour Clinique (Mère-Enfant) :

Offre les services de pédiatrie et gynécologie obstétrique.

A.2 Les Directions du CHU

Le CHU est composé des différentes directions et sous directions :

A.2.1 La direction des activités médicales et paramédicales

Elle est composée de trois sous-directions :

La sous-direction des activités médicales

Bureau de l’organisation et de l’évaluation des activités médicales a pour mission

de :

• Accompagnement des équipements médicaux des services dans l’amélioration de l’orga-

nisation des activités.

91
Annexe A. Structure du CHU de Béjaia

• Recensement mensuel du relevé de toutes les activités médico-chirurgicales des services,

ainsi que celles d’exploration (biologie, imagerie médicale).

• Faire une exploitation trimestrielle et annuelle des activités qui sont adressées à la direc-
tion de la santé de la wilaya et au MSPRH.

Bureau de la programmation et du suivi des étudiants a pour mission de :

• Prendre en charge les étudiants en médecine, en collaboration avec les départements

respectifs de la faculté de médecine de l’université de Bejaïa.

• La répartition et la programmation des gardes des internes, qui se déroule au niveau des
trois unités composantes le CHU et dans les différents services, y compris les pavillons
des urgences de médecine, de chirurgie et de pédiatrie.

Bureau des gardes et des urgences : S’occupe du suivi des gardes, telles qu’elles sont
organisées par les chefs des différents services. Un comité des gardes et des urgences se réunit
régulièrement, conformément à la réglementation en vigueur, pour régler les divers problèmes
qui peuvent se poser et pour améliorer la prise en charge des urgences médico-chirurgicales.

La sous-direction des activités paramédicales

Elle se compose de 3 bureaux :

Bureau de la programmation et du suivi des étudiants : Il a pour tâche de programmer

et de répartir les étudiants de l’école de formation paramédicale. Ces etudiants sont repartis au
cours de leur formation dans les services médico-chirurgicaux et dans les différents laboratoires,
pour des stages pratiques, ainsi que pour un stage de fin de cursus vue de la préparation
du mémoire de fin d’étude. Ces étudiants sont encadrés accessoirement par des paramédicaux
(tuteur) dans l’exercice quotidien de leurs tâches sous la supervision des PEPM (professeurs de
l’enseignement paramédical).

Bureau des soins infirmiers : Il collecte des données statistiques sur les soins infirmiers
dispensés dans les services et assure le suivi des rotations des gardes.

Bureau de l’évaluation et de l’organisation de l’activité paramédicale : Il se charge

de l’accompagnement des surveillants médicaux dans l’organisation de leurs équipes soignantes,
et de l’évaluation de l’organisation, avec pour objectif une amélioration constante (performance
collective) visant la démarche qualité.

La sous-direction de la gestion administrative du malade

Elle est composée de deux bureaux :

92
Annexe A. Structure du CHU de Béjaia

Bureau des entrées (admissions) s’occupe de :

• L’accueil et des admissions des malades.

• La tenue et l’exploitation des divers registres (état civil, comptabilité des journées d’hos-
pitalisations, mouvement des malades…).

• La comptabilité financière (décompte des frais d’hospitalisation, de consultations externes,

de prélèvements, d’analyses, des examens d’imagerie médicale…).

• Le Suivi du contentieux.

• L’évaluation et exploitation de la fiche navette.

Bureau de l’accueil, de l’orientation et des activités socio thérapeutiques a pour

mission de :

• Accueillir les malades et les parents de malades.

• Fournir des renseignements concernant les malades (service d’hospitalisation…).

• Prendre en charge des cas sociaux et des malades hospitalisés nécessitant une prise en
charge à l’étranger par les assistantes sociales.

A.2.2 Direction des ressources humaines

La sous-direction des personnels

La sous-direction des personnels a pour mission de déterminer les besoins en personnel et

d’opérer les recrutements nécessaires aux différents services. Ses finalités sont autant écono-
miques que sociales, puisqu’elle concerne principalement l’homme dans l’organisation.
Elle se compose de trois bureaux :

• Le bureau de la gestion des carrières des personnels administratifs, techniques et de

service.

• Le bureau de la gestion des personnels médicaux, paramédicaux et psychologues.

• Le bureau des effectifs, de la régulation et de la solde.

La sous-direction de la formation et de la documentation

Elle est créé en 1999, suite à l’application du nouvel organigramme initié par le ministère
de la santé.
En termes de ressources humaines, la sous-direction de la formation et de la documentation
comprend : un sous-directeur, un chef de bureau, un chef de bureau de documentation, un
chargé des moyens matériels, un chargé de secrétariat, un chargé du suivi scolaire des enfants
hospitalisés, trois bibliothécaires et quatre agents de service.

93
Annexe A. Structure du CHU de Béjaia

La sous-direction de la formation et de la documentation endosse plusieurs activités de

formations et de formations continues : médicale, paramédicale, administrative, technique, per-
fectionnement, recyclage, formation de courte durée à l’étranger, encadrement et suivi des
stagiaires de différents instituts, suivi et formations des enfants hospitalisés, organisation des
manifestations scientifiques.

A.2.3 La direction des finances et du contrôle

La direction des finances et contrôles comprendles deux sous-directions :

La sous-direction budget et comptabilité (finances)

Elle comporte les deux bureaux suivants :

• Le bureau du budget et de la comptabilité : qui a pour but de repartir, par chapitre

et parties, les crédits budgétaires, assurer le suivi de l’exécution du budget à travers la
comparabilité des engagements et des paiements.

• Le bureau des recettes et des caisses : qui a pour mission de prendre en charge, par
le biais de la régie et des différentes sous régies, l’ensemble des recettes réalisées par
l’établissement.

La sous-direction de calcul des coûts

Elle comporte les deux bureaux suivants :

• Le bureau de la facturation : qui est chargé de recueillir les données relatives aux actes et
prestations prodiguées aux malades hospitalisés sur la base de la fiche navette et établir
le décompte des frais d’hospitalisations individualisés à ces malades.

• Le bureau de l’analyse et la maîtrise des coûts : qui est chargée de déterminer le coût
par unité d’œuvre (journée d’hospitalisation, consultation, séance de dialyse, examen, …)
et par service selon le découpage de l’établissement en centres des responsabilités aussi
recueillir les données relatives à l’activité des différents services (hospitalisation, examens
biologiques et radiologiques, séances de dialyse, consultation, etc.)

A.2.4 La direction des moyens matériels

La direction des moyens matériels comprend les trois sous-directions :

La sous-direction des services économiques

Qui comporte les bureaux suivants

• Le bureau des approvisionnements.

• Le bureau de la gestion des magasins, des inventaires.

• Le bureau de la restauration et de l’hôtellerie.

94
Annexe A. Structure du CHU de Béjaia

La sous-direction des infrastructures, des équipements de la maintenance

Qui comporte les bureaux suivants :

• Le bureau des infrastructures.

• Le bureau des équipements.

• Le bureau de la maintenance.

La sous-direction des produits pharmaceutiques

Qui comporte les unités suivantes :

• Unité des médicaments.

• Unité des consommables.

• Unité réactive de laboratoire.

• Unité de l’instrumentation.

A.3 Effectif de personnel du CHU

En ce qui concerne l’effectif du personnel du CHU jusqu’en février 2023, il se compose de
2039 personnes réparties comme suit, selon les données internes du CHU :

• Personnel médical (médecins) : un total de 126 médecins dont, (13) médecins généralistes,
(53) spécialiste praticien, (60) Hospitalo-Universitaires.

• Personnel paramédical : composé de 919 paramédicaux (infirmiers diplômés d’état, aides-

soignants, infirmiers principaux, infirmiers brevetés).

• Personnels administratifs et techniciens : 672 personnes.

• Résidents : 322 résidents

95
Annexe B

Documents

B.1 Ordonnances

B.1.1 Ordonnance interne

La figure suivante présente une ordonnance interne (du CHU de Béjaïa) pour un patient
qui prend des médicaments ambulatoires :

Fig. B.1 : Ordonnance interne.

96
Annexe B. Documents

B.1.2 Ordonnance externe

La figure suivante présente une ordonnance externe (hors CHU de Béjaia) pour un patient
qui prend des médicaments ambulatoires :

Fig. B.2 : Ordonnance externe.

97
Annexe B. Documents

B.2 Bons

B.2.1 Bon de commande

La figure suivante présente un bon de commande émis par la pharmacie principale pour
l’unité de médicaments :

Fig. B.3 : Bon de commande.

98
Annexe B. Documents

B.2.2 Bon de livraison

La figure suivante présente un bon de livraison pour la commande précédente :

Fig. B.4 : Bon de livraison.

99
Annexe B. Documents

B.2.3 Bon de réception

La figure suivante présente un bon de réception pour la livraison précédente :

Fig. B.5 : Bon de réception.

100
Résumé
Ce travail a été réalisé dans le cadre d’un projet de fin de cycle visant à obtenir un diplôme
de Master professionnel en Génie logiciel. L’objectif de ce projet était de concevoir et de réaliser
une application web appelée OrdoTrack, permettant la gestion des ordonnances et le stock des
médicaments à titre ambulatoire, spécifiquement pour la pharmacie principale du CHU Bejaïa.
Cette application vise à simplifier les tâches des utilisateurs et à leur faire gagner du temps.
Pour mettre en œuvre notre solution, nous avons adopté le processus de développement SCRUM
et le langage de modélisation unifié (UML). Nous avons choisi de programmer l’application
en utilisant les framework [Link](JavScript), Laravel (PHP) et la librairie Inertia. En ce qui
concerne la gestion des données, nous avons utilisé MySQL comme système de gestion de bases
de données relationnelles (SGBDR).

Mots clés : E-santé, Application web, ordonnances, gestion de stock, médicament à titre
ambulatoire, pharmacie principale du CHU de Bejaia, SCRUM, UML.

Abstract
This work was carried out as part of an end-of-cycle project aimed at obtaining a profes-
sional Master’s degree in Software Engineering. The objective of this project was to design and
develop a web application called OrdoTrack, which enables the management of prescriptions
and outpatient medication stock specifically for the main pharmacy of CHU Bejaia.
This application aims to simplify tasks for users and save them time.
To implement our solution, we adopted the SCRUM development process and used the Uni-
fied Modeling Language (UML) for modeling. We chose to program the application using
[Link](JavaScript), Laravel (PHP), and the Inertia library. Regarding data management, we
used MySQL as relational database management system (RDBMS).

Keywords : E-health, Web application, prescriptions, stock management, outpatient me-

dication, main pharmacy of the CHU of Bejaia, SCRUM, UML.