DEDICACE

A
Nos Familles

1
 REMERCIEMENTS
De nombreuses personnes ont contribué scientifiquement, intellectuellement,
techniquement, spirituellement et financièrement à la réussite de ce parcours et de ce projet,
et nous tenons sincèrement à leur exprimer ici notre gratitude et notre profonde
reconnaissance. Nous saisissons donc cette opportunité pour remercier particulièrement :

 Les membres du jury, qui n’ont ménagé aucun effort à accepter d’évaluer notre
travail : nous nous sentons honorés ;
 Pr. MOUANGUE Ruben, Directeur de l’École Nationale Supérieure Polytechnique
de Douala pour son dynamisme et l’abnégation au travail bien fait ;
 Dr MATANGA Jean Jacques et M. MIMBEU Yves, Nos encadreurs académiques
pour leurs très grande disponibilité, encouragements, conseils, orientations, rigueurs
et le soutien inconditionnel qui nous a permis d’améliorer ce travail et nos capacités ;
 Nos enseignants de l’ENSPD et en particulier ceux du Département de TTIC, qui
ont toujours cultivés en nous la quête de l’amélioration et ont toujours sus répondre en
temps opportun à nos diverses interpellations et qui ont assuré notre formation durant
tout ce cycle ;
 M. ATEMKENG Aurélien et M. KUETCHE Platini, Nos Encadreurs
professionnels pour le suivi professionnel, la disponibilité et le cadre de travail
agréable qu’ils nous ont fourni.
 Nos camarades de promotion, pour les échanges de documentations ayant ainsi
facilité l’élaboration de notre travail et aussi pour avoir cultivé un esprit de solidarité
et de fraternité avec nous, facilitant ainsi notre insertion dans le milieu éducatif.
 Notre gratitude à tous ceux qui nous ont soutenus de près ou de loin dans cette œuvre
et dont les noms restent anonymes mais plutôt prestigieusement considérés.

2
 AVANT-PROPOS

L’École Nationale Supérieure Polytechnique de Douala (ENSPD), né de la transformation

de l’Ex-Faculté de Génie Industriel, ayant vu le jour par le décret présidentiel N2020/272 du
11 Mai 2020, est l’une des institutions de l’Université de Douala. Elle a pour mission
principale de former des citoyens aptes à diriger des travaux d’art ou d’industrie, en vue de
donner un nouveau souffle à son développement technologique et de lutter contre le sous-
développement. Elle offre les domaines de formations suivants :

Cursus Ingénieur dans les spécialités suivantes :

 Génie Qualité-Hygiène-Sécurité-Environnement industriel ;

 Génie informatique et télécommunication ;
 Génie maritime et portuaire ;
 Génie des procédés ;
 Génie civil ;
 Génie énergétique ;
 Génie automobile et mécatronique ;
 Génie mécanique ;
 Génie physique et technologie biomédicale ;
 Génie électrique et système intelligent.

Cursus des sciences de l’ingénieur (Licence-Master-Doctorat) dans les spécialités suivantes :

 Mécanique et matériaux ;
 Géophysique, eau et environnement ;
 Electronique, électrotechnique, automatisme et télécommunication ;
 Energie ;
 Chimie appliquée ;
 Science des données et intelligence artificielle
 Cursus de masters professionnels dans les spécialités suivantes :
 Hydrocarbures et développement durable ;
 Géotechnique et infrastructure ;
 Construction métallique et mécanique ;

3
  Génie industriel et maintenance ;
 Ingénierie thermique et énergie ;
 Génie informatique option ingénierie logiciel ;
 Mécatronique et gestion technique des équipements.

Les diplômes suivants y sont délivrés pour les différents cursus :

 Ingénieur de conception pour le cursus Ingénieur ;

 Licence, master et doctorat en science de l’ingénieur pour le cursus sciences de
l’ingénieur ;
 Master professionnel pour le cursus master professionnel.

Les étudiants y sont admis par voie de concours en 1ère année et en 3ème année pour le
cursus d’ingénieur et 1ere année pour le cursus des sciences de l’ingénieur et sur étude de
dossier pour le master professionnel. Les enseignements y sont organisés en cours
magistraux, travaux dirigés, travaux pratiques, travaux personnels, visites d’entreprise et
stages techniques.

Les études sont effectuées en trois cycles : Les enseignements du 1er cycle s’étalent sur six
semestres et ont pour principal objectif « d’initier les étudiants aux techniques industrielles »
afin d’assister les ingénieurs. La validation de toutes les Unités d’Enseignement (UE) du 1er
cycle correspondant au quota requis donne droit à une admission au 2nd cycle et à l’obtention
d’une Licence en science de l’ingénieur pour le cursus science de l’ingénieur.

Le second cycle s’étend sur quatre semestres dit de « spécialisation ». Les étudiants ayant
choisi leur filière en fin de premier cycle se spécialisent en choisissant un axe pour
l’élaboration d’un profil particulier et personnel. En effet, l’étudiant a un quota d’unités
d’enseignements obligatoires et des optionnelles au choix en fonction de son profil. Les
objectifs du 2nd cycle sont :

 Donner à l’étudiant les connaissances professionnelles, technologiques et

managériales de pointes pour une compétence efficiente en entreprise ;
 D’initier l’étudiant à la recherche. Les études du 2nd cycle sont sanctionnées par la
validation de tous les stages et Unités d’Enseignement correspondant au nombre de
crédits indiqués et, l’obtention du Diplôme d’Ingénieur de l’École Nationale
Supérieure Polytechnique de Douala pour le cursus d’ingénieur, celui de master 2 en

4
 science de l’ingénieur pour le cursus science de l’ingénieur donnant lieu au passage
au 3eme cycle et celui de master 2 professionnel pour le cursus master professionnel.

RESUME

Le présent travail de mémoire de fin d’étude est consacré à la conception et la réalisation

d’une plateforme SaaS qui pourra aider les pharmacies dans leur prise de décision. En effet
beaucoup de systèmes informatiques utilisés dans les pharmacies ne sont pas capables
d’utiliser les données que ces dernières génèrent pour améliorer leurs performances
opérationnelles et la prise de décisions dans celles-ci. Dans l’optique de résoudre ce problème
et de palier à ces manquements, l’entreprise SPACEKOLA a mise sur pied le projet
MEDOCLAB. Il s’agit d’une plateforme SaaS (Software As a Service) qui se connecte
directement au système existant pour extraire et traiter les données en fonction des besoins
des pharmacies grâce à un ETL; puis les stockent dans un data warehouse. Il permet ainsi de
connaitre les informations telles que le stock de produits, les produits les plus vendus, les
clients favoris et l’évolution des ventes. Il permet également une gestion efficace des activités
au sein de la pharmacie en facilitant la répartition et le suivi des tâches entre le personnel de
celle-ci. Ce projet été réalisé en utilisant la méthodologie agile Scrum et le langage de
modélisation UML (Unified Modeling Language) pour la conception; ainsi que les outils et
Framework tels que Talend, Vuejs et Devups adossé au SGBD (Système de Gestion de Base
de Données) MYSQL PHPMyAdmin pour la réalisation.

Mots clés : plateforme SaaS, Optimisation, Pharmacie, data warehouse, ETL

5
 ABSTRACT

This end-of-study dissertation is devoted to the design and implementation of a SaaS

platform that can help pharmacies in their decision-making. Indeed, many computer systems
used in pharmacies are not able to use the data that they generate to improve their operational
performance and decision-making in them. In order to solve this problem and overcome these
shortcomings, the SPACEKOLA company has set up the MEDOCLAB project. It is a SaaS
(Software As a Service) platform that connects directly to the existing system to extract and
process data according to the needs of pharmacies through an ETL; then store them in a data
warehouse. It thus makes it possible to know information such as the stock of products, the
best-selling products, the favorite customers and the evolution of sales. It also allows efficient
management of activities within the pharmacy by facilitating the distribution and monitoring
of tasks between the staff of the latter. This project was carried out using the agile Scrum
methodology and the UML (Unified Modeling Language) modeling language for the design;
as well as tools and Framework such as Talend, Vuejs and Devups backed by the DBMS
(Database Management System) MYSQL PHPMyAdmin for the realization.

Key words: SaaS platform, Optimisation, Pharmacy, data warehouse, ETL

6
 LISTE DES FIGURES
Figure 1. 1: Schémas d’un IAAS [4]..........................................................................................4
Figure 1. 2: Schémas d’un PAAS [4].........................................................................................4
Figure 1. 3: Schémas d’un SAAS [4].........................................................................................5
Figure 1. 4: Pyramide du Cloud Computing [5]........................................................................5
Figure 1. 5: Modèle de développement en cascade [8]..............................................................6
Figure 1. 6: Modèle de développement en V [8]........................................................................6
Figure 1. 7: Le modèle de développement itératif [8]................................................................7
Figure 1. 8: Architecture de Devups..........................................................................................9
Figure 1. 9: Organigramme de SPACEKOLA.........................................................................11
Figure 1. 10: Diagramme de Gantt...........................................................................................22

Figure 2. 1: une itération selon la méthode Scrum…………………………………………...

23
Figure 2. 2: : Architecture de Medoclab...................................................................................29
Figure 2. 3: modèle en constellation de la vente......................................................................34
Figure 2. 4: Formalisme d’un diagramme de cas d’utilisation.................................................34
Figure 2. 5: Diagramme de cas d’utilisation global.................................................................35
Figure 2. 6: Diagramme du cas d’utilisation gestion des comptes...........................................36
Figure 2. 7: Diagramme du cas d’utilisation gestion des tâches..............................................36
Figure 2. 8: Diagramme de séquence pour l’inscription..........................................................37
Figure 2. 9: Diagramme de séquence d’authentification.........................................................38
Figure 2. 10: Diagramme de classe..........................................................................................39
Figure 2. 11: Logo de Vuejs.....................................................................................................40
Figure 2. 12: Logo de Devups..................................................................................................40
Figure 2. 13: Logo de Visual Studio Code...............................................................................41
Figure 2. 14: Page d’Accueil de Google Chrome....................................................................41
Figure 2. 15: Logo d’Apache...................................................................................................42
Figure 2. 16: Logo de Git.........................................................................................................42
Figure 2. 17: Logo de Postman [18].........................................................................................42
Figure 2. 18: Logo de Talend...................................................................................................43

7
Figure 3. 1: Migration de la table pharmacie 44
Figure 3. 2: Migration de la table inventaire............................................................................45
Figure 3. 3: Orchestration et Automatisation des migrations dans Talend...............................45
Figure 3. 4: Automatisation de la Mise à jour du data Warehouse...........................................46
Figure 3. 5: Page d’inscription.................................................................................................46
Figure 3. 6: Page d’authentification.........................................................................................47
Figure 3. 7: Page de visualisation des tâches...........................................................................48
Figure 3. 8: Menu de détails d’une tâche.................................................................................48
Figure 3. 9: Page de consultation des produits.........................................................................49
Figure 3. 10: Page de consultation des clients.........................................................................50
Figure 3. 11: Tableau de bord de l’administrateur...................................................................50
Figure 3. 12: Page de gestion des utilisateurs..........................................................................51
Figure 3. 13: Modale de création d’un utilisateur....................................................................51

8
 LISTE DES TABLEAUX
Tableau 1. 1: Identité de SPACEKOLA...................................................................................10
Tableau 1. 2: Services de SPACEKOLA..................................................................................10
Tableau 1. 3: Avantages et limites de l’existant.......................................................................15
Tableau 1. 4: Acteurs du projet.................................................................................................21

Tableau 2. 1: Identification de l'acteur "Pharmacien"………………………………………..26

Tableau 2. 2: Identification de l'acteur "Administrateur".........................................................27
Tableau 2. 3: Identification de l'acteur "Gérant"......................................................................27
Tableau 2. 4: Identification de l'acteur "Personnel".................................................................28
Tableau 2. 5: Table de dimension client...................................................................................29
Tableau 2. 6: Table de dimension produit................................................................................30
Tableau 2. 7: Table de Dimension fournisseur.........................................................................30
Tableau 2. 8: Table de dimension pharmacien.........................................................................30
Tableau 2. 9: Table de dimension du médecin.........................................................................31
Tableau 2. 10: Table de dimension de la remise.......................................................................31
Tableau 2. 11: Table de dimension de date...............................................................................31
Tableau 2. 12: Table de dimension de dateliv..........................................................................31
Tableau 2. 13: Table de fait commander..................................................................................32
Tableau 2. 14: Table de fait stock.............................................................................................32

Tableau 3. 1: Coût du matériel utilisé ………………………………………………………..52

Tableau 3. 2: Tableau des formules de calculs de l'effort pour chaque type de projets...........53
Tableau 3. 3: Tableau du coût total du projet...........................................................................54

9
 LISTES DES ABREVIATIONS
AFNOR : Association Française de Normalisation
AJAX : Asynchronous JavaScript and XML
API : Application Programming Interface
AWS : Amazon Web Service
BI : Business Intelligence
COCOMO : Constructive Cost Model
CTO : Chief Technical Officer
EJD : ESSEC Junior Développement
ENSPD : École Nationale Supérieure Polytechnique de Douala
ETL : Extraction Transformation Loading
IA : Intelligence Artificielle
IAAS : Infrastructure As A Service
IDE : Environnement de Développement Intégré
KLS : Kilo Ligne Source
MVC : Modele-Vue-Controlleur
NIST : National Institute of Standards and Technology
OMG : Object Management Group
ORM : Object-Relational Mapping
PAAS : Plateform As A Service
PHP : Hypertext Preprocessor
SAAS : Software As A Service
SGBD : Système de Gestion de Base de Données
TIC : Technologie de l’Information et de la Communication
UML : Unified Modeling Language

10
 TABLE DES MATIÈRES
DEDICACE................................................................................................................................i

REMERCIEMENTS..................................................................................................................ii

AVANT-PROPOS.....................................................................................................................iii

RESUME....................................................................................................................................v

ABSTRACT..............................................................................................................................vi

LISTE DES FIGURES............................................................................................................vii

LISTE DES TABLEAUX.........................................................................................................ix

LISTES DES ABREVIATIONS................................................................................................x

TABLE DES MATIÈRES.........................................................................................................xi

INTRODUCTION GENERALE...............................................................................................1

CHAPITRE 1 : ETAT DE L’ART ET CONTEXTE..................................................................2

1.1 Etat de l’art..................................................................................................................2

1.1.1 Définition et problématique de gestion des pharmacies......................................2

1.1.2 Le cloud................................................................................................................2

1.1.2.1 Les différents types de cloud............................................................................3

1.1.2.2 Les différents modèles de service cloud...........................................................4

1.1.3 Notion de Base du génie logiciel.........................................................................5

1.1.3.1 Méthodes de développement............................................................................5

1.1.3.2 Langage de modélisation..................................................................................7

1.1.3.3 Data warehouse (Entrepôt de donnée)..............................................................8

1.1.3.4 ETL (Extraction, Transformation, Loading).....................................................8

1.1.3.5 Devups..............................................................................................................8

1.2 Contexte du projet.......................................................................................................9

1.2.1 Présentation de l’entreprise SPACEKOLA..........................................................9

1.2.1.1 Fiche d’identité...............................................................................................10

11
 1.2.1.2 Service de SPACEKOLA...............................................................................10

1.2.1.3 Organigramme................................................................................................11

1.2.2 Perspectives de croissance des Saas de pharmacie en France............................12

1.2.3 Etude de l'existant..............................................................................................12

1.2.3.1 Présentation des différents acteurs.................................................................13

1.2.3.2 Critique de l'existant.......................................................................................14

1.2.3.3 Solution...........................................................................................................16

1.2.4 Cahier de Charge................................................................................................16

1.2.4.1 Contexte et Problématique.............................................................................16

1.2.4.2 Objectifs.........................................................................................................17

1.2.4.3 Description fonctionnelle...............................................................................18

1.2.4.4 Les contraintes du projet................................................................................19

1.2.4.5 Les acteurs du projet.......................................................................................21

1.2.4.6 Planification du projet....................................................................................21

1.2.4.7 Les Livrables..................................................................................................22

CHAPITRE 2 : ANALYSE ET CONCEPTION......................................................................23

2.1 Méthodologie.............................................................................................................23

2.1.1 Les acteurs dans un projet Scrum.......................................................................23

2.1.2 Les artefacts de Scrum.......................................................................................24

2.2 Analyse des fonctionnalités.......................................................................................24

2.2.1 Analyse des besoins métiers du data warehouse................................................24

2.2.1.1 Identification des parties prenantes................................................................24

2.2.1.2 Exigences........................................................................................................25

2.2.1.3 Source de données..........................................................................................25

2.2.2 Analyse des fonctionnalités de l’application......................................................26

2.3 Conception.................................................................................................................28

2.3.1 Architecture du système.....................................................................................28

12
 2.3.2 Modélisation dimensionnelle du data warehouse..............................................29

2.3.2.1 Table de dimension.........................................................................................29

2.3.2.2 Table de fait....................................................................................................32

2.3.2.3 Le modèle physique........................................................................................33

2.3.3 Modélisation de l’application.............................................................................34

2.3.3.1 Diagrammes de cas d’utilisation....................................................................34

2.3.3.2 Diagramme de séquence.................................................................................37

2.3.3.3 Diagramme de classe......................................................................................38

2.4 Technologies et outils de développement..................................................................39

2.4.1 Technologies de développement........................................................................39

2.4.1.1 Les langages de programmation.....................................................................39

2.4.1.2 Les Framework...............................................................................................40

CHAPITRE 3 : RESULTATS ET DISCUSSION....................................................................44

3.1 Résultats du data warehouse......................................................................................44

3.1.1 Migration des tables...........................................................................................44

3.1.1.1 Migration de la table pharmacie.....................................................................44

3.1.1.2 Inventaire........................................................................................................44

3.1.2 Orchestration et Automatisation des tâches.......................................................45

3.1.3 Automatisation de la Mise à jour du data wharehouse......................................45

3.2 Présentation de quelques interfaces...........................................................................46

3.2.1 Interfaces de la partie cliente..............................................................................46

3.2.1.1 Page d’inscription des pharmacies.................................................................46

3.2.1.2 Page d’authentification...................................................................................47

3.2.1.3 Page de gestion des tâches..............................................................................47

3.2.1.4 Interface de consultation des produits............................................................49

3.2.1.5 Interface de consultation des clients...............................................................49

3.2.2 Les interfaces en back-office..............................................................................50

13
 3.2.2.1 Interfaces d’accueil.........................................................................................50

3.2.2.2 Page de gestion des utilisateurs......................................................................51

3.3 Evaluation financière du projet.................................................................................51

3.3.1 Estimation du coût des équipements..................................................................52

3.3.2 Le coût de prestation des ingénieurs..................................................................52

3.3.3 Estimation du coût total du projet......................................................................54

CONCLUSION GENERALE..................................................................................................56

REFERENCES BIBLIOGRAPHIQUES.................................................................................57

14
 INTRODUCTION GENERALE
Actuellement, le monde connaît une avancée technologique considérable dans tous les
secteurs et cela grâce à l'informatique qui est une science étudiant les techniques du
traitement automatique de l'information. Elle joue un rôle important dans le développement
de l'entreprise et d'autres établissements notamment les pharmacies.

L’utilisation des outils logiciels dans les pharmacies facilite la gestion des opérations au
sein de celle-ci, elle permet des gains de temps et d’énergie et d’accroitre sa rentabilité.
Cependant avec l’augmentation de la production de médicaments et des ventes de produits,
ces pharmacies produisent de grandes quantités de données, mais la plupart des outils
logiciels utilisés ne permettent pas l’exploitation. Par ailleurs avec l’augmentation des
effectifs au sein de ces entreprises, il est de plus en plus difficile d’organiser et de suivre
l’évolution du travail du personnel. C’est pour apporter un début de solution à ces problèmes
que la plateforme MEDOCLAB a été pensée. En effet basée sur le cloud elle vient en
complément au système existant. Elle permettra à une pharmacie d’exploiter ses données de
façon optimale, facilitera l’observation statistique et améliorera la prise de décision dans

celle-ci. Elle apportera une valeur ajoutée significative en améliorant l'efficacité

opérationnelle et la rentabilité des pharmacies par des décisions plus éclairées.

Dans le cadre donc de la réalisation du projet, nous avons divisé notre travail en trois (03)
chapitres. De prime abord, le premier chapitre fait l’état de l’art sur les solution logicielle
cloud du domaine pharmaceutique, on y aborde également les notions du génie logiciel, nous
présentons le projet dans son cahier de charge, ainsi que l’entreprise d’accueil. Ensuite on
fera une analyse et conception de notre solution dans le second chapitre. Dans le dernier
chapitre, enfin on échouera sur les résultats et l’évaluation financière de la plateforme.

1
 CHAPITRE 1 : ETAT DE L’ART ET CONTEXTE

Dans ce chapitre il sera question de faire une étude sur les logiciels de gestion de
pharmacies existants ; nous présenterons quelques notions sur le génie logiciel. Puis nous
présenterons l’entreprise d’accueil ainsi que le contexte du projet et son cahier de charge.
1.1 Etat de l’art
L’état de l’art ici fait référence à l’évolution du marché des pharmacies, aux notions
générales du cloud ainsi qu’à quelques notions du génie logiciel.

1.1.1 Définition et problématique de gestion des pharmacies

La pharmacie, ou officine est un local où les médicaments sont préparés, conservés et
distribués au détail par le pharmacien, et où on procède à l'exécution des ordonnances
médicales [1]. Les pharmacies ont pour mission de délivrer des médicaments et des produits
de santé aux patients, ainsi que de les conseiller sur leur utilisation.
Le marché des pharmacies en France et partout dans le monde est un secteur hautement
réglementé, qui fait l'objet d'une forte concurrence. Selon Statista Research Department, il y
avait environ 20 534 pharmacies en France en 2022, employant plus de 100 000 personnes
[2].
Elles sont réparties sur l'ensemble du territoire, avec une densité plus élevée dans les zones
urbaines que dans les zones rurales. Elles sont généralement organisées en groupe ou chaine
pour résister à la concurrence du marché. On peut notamment citer les groupes : Alphega
Pharmacie, Aprium Pharmacie, Leadersanté, Pharmabest et Wellpharma.
Les pharmacies sont également confrontées à des défis réglementaires, tels que la réforme de
la tarification des médicaments et l'augmentation des exigences en matière de sécurité et de
confidentialité des données de santé. Cependant elles ont la possibilité de s'adapter en offrant
de nouveaux services, ainsi qu'en adoptant des solutions technologiques comme celles du
cloud de l’IA (Intelligence Artificielle) ou alors du big data, pour améliorer leur efficacité et
leur productivité.

1.1.2 Le cloud
Selon le groupe Gartner : le Cloud Computing (ou "informatique en nuage" en Français)
regroupe « l’ensemble des disciplines, technologies et modèles d’entreprise utilisé pour
fournir des capacités informatiques (logiciels, plates-formes, matériels) à la manière d’un

2
service à la demande, évolutif et élastique. » [3]. C’est un concept qui réfère à la fourniture de
services informatiques, tels que le stockage de données, le traitement de données et les
applications, via internet. Au lieu de stocker ou de traiter des données localement sur un
ordinateur ou un serveur physique, les utilisateurs peuvent accéder à ces services à distance
via des serveurs distants, généralement gérés par des tiers fournisseurs.

1.1.2.1 Les différents types de cloud

Le NIST (National Institute of Standards and Technology) distingue, dans sa définition du
Cloud Computing, 4 types de cloud [3] :
 Le cloud public : les ressources informatiques sont hébergées par un fournisseur tiers
et sont accessibles via internet. Un cloud devient un cloud public lorsque les
environnements sont partitionnés et redistribués entre plusieurs clients. Les
utilisateurs peuvent louer des ressources en fonction de leurs besoins et ne paient que
ce qu'ils utilisent. Les fournisseurs de cloud public offrent souvent une grande
flexibilité et une scalabilité élevée, mais peuvent soulever des préoccupations de
sécurité liées à la confidentialité des données et à la dépendance à l'égard du
fournisseur de services. Comme exemple nous avons Amazon Web Service (AWS),
Microsoft azure.
a. Le cloud privé : les ressources informatiques sont hébergées sur un site ou dans un
centre de données privé géré par l’entreprise elle-même. Les utilisateurs ont un plus
grand contrôle de leurs données et leurs ressources, mais doivent prendre en charge la
gestion et la maintenance de l'infrastructure informatique. Tous les cloud deviennent
des cloud privés lorsque l'infrastructure informatique sous-jacente est spécifique à un
client unique, avec un accès entièrement isolé. Il existe plusieurs fournisseurs de
cloud privé comme open stack, Microsoft azure stack.
b. Cloud hybride: Comme nous venons de le voir avec le Cloud public, certains
problèmes peuvent se poser, liés à la sécurité de l’information. Il est alors possible de
« mélanger » les deux approches du Cloud, privé et public, en débouchant sur une
plateforme hybride. Ce terme n’évoque pas vraiment un Cloud en tant que tel,
puisqu’il s’agit de faire cohabiter et communiquer un Cloud privé et un Cloud public.
Dans le public, on déportera les éléments non sensibles et dans le privé, on gardera les
données, applications sensibles liées au business de l’entreprise.

3
 c. Le cloud communautaire fait référence à une architecture dédiée à une communauté
professionnelle spécifique incluant partenaires, et sous-traitants, pour travailler de
manière collaborative sur un même projet [3].

1.1.2.2 Les différents modèles de service cloud

Il existe trois principaux modèles de services de cloud computing, qui définissent la
manière dont les services de cloud sont fournis et utilisés [3]. Ce sont :
 Infrastructure As A Service (IAAS) : Dans ce modèle, l’infrastructure physique
(le matériel réseau, le matériel serveur, la plateforme de virtualisation, les moyens et
capacités de stockage) est « dématérialisée » et hébergée. Le fournisseur procure
donc une couche matérielle (serveurs, réseau, stockage, hyperviseur, solution de
supervision, solution de management) sur laquelle les clients vont pouvoir déposer
leurs environnements système et leurs applications. Ce service est très similaire aux
ressources informatiques existantes.

Figure 1. 1: Schémas d’un IAAS [4]

 Plateforme As A Service (PAAS) : Il fournit un niveau d’abstraction supplémentaire

par rapport à l’IAAS. Dans cette catégorie, non seulement l’infrastructure est
dématérialisée, mais aussi le système d’exploitation, et la plateforme d’exécution, de
déploiement et de développement d’applications. Le fournisseur procure donc aux
clients développeurs l’infrastructure, le système d’exploitation, les bases de données,
la couche middleware, et une plateforme de développement complète, fonctionnelle et
performante.

4
 Figure 1. 2: Schémas d’un PAAS [4]

 Software As A Service (SAAS): c’est une application fournie comme un service, et

déporté chez un fournisseur, plutôt que comme un programme à installer sur un poste
de travail. C’est plutôt un concept consistant à proposer un abonnement à un logiciel
plutôt que l’achat d’une licence. Cette couche concerne directement l’utilisateur final
[3]. Le fournisseur procure un service prêt à l’emploi, opérationnel et capable de gérer
un nombre important d’utilisateurs. Ce service est accessible via internet et est facturé
à l’usage. Le client n’a aucune tâche d’installation, de maintenance ou de mise à jour
à effectuer. Il n’a pas à se soucier de l’infrastructure sous-jacente à l’application.

Figure 1. 3: Schémas d’un SAAS [4]

Ces trois éléments constituent ce que l’on appelle la pyramide du cloud computing
schématisée comme suit :

5
 Figure 1. 4: Pyramide du Cloud Computing [5]

1.1.3 Notion de Base du génie logiciel

Le génie logiciel est un domaine des sciences de l’ingénieur dont l’objet d’étude est la
conception, la fabrication et la maintenance des systèmes informatiques complexes [6].le
génie logiciel est intéressé par les théories ,les méthodes et les outils de développement de
logiciels professionnels.

1.1.3.1 Méthodes de développement

Selon Grady Booch, une méthodologie est un processus discipliné que génère un ensemble
de modèles décrivant les différents aspects d’un système logiciel, en utilisant une notation
bien définie. Il existe plusieurs méthodes ou modèle de développements logiciels : la méthode
en cascade, la méthode itérative, le modèle en V et la méthode agile.
a. Le modèle en cascade
Considéré comme le modèle, à la fois le plus ancien et le plus simple de tous, ce modèle se
divise en plusieurs phases. Chaque phase a son propre plan et commence après la précédente.
Le résultat de la première phase représentera le point d’entrée de la phase d’après [7].

Figure 1. 5: Modèle de développement en cascade [8]

b. Le modèle de développement en V
Dans ce type de modèle, les différentes phases sont planifiées en parallèle. Les phases de
vérification du logiciel et de sa validation se font parallèlement et en simultané. Le modèle en
V est venu améliorer le modèle en cascade dans la mesure où celui-ci réduit les retour-
arrières en établissant des liaisons entre les différentes étapes de développement, permettant
de passer de l’une vers l’autre en cas de besoin [7].

6
 Figure 1. 6: Modèle de développement en V [8]

c. Le modèle de développement itératif

Le modèle itératif ayant la particularité de fournir, en de brefs délais, un livrable (ou
artefact) fonctionnel de l’application ou projet en cours de développement. Il est subdivisé en
quatre étapes successives et suivies en boucle jusqu’à l’obtention du livrable fonctionnel. En
image, on peut obtenir le schéma suivant :

Figure 1. 7: Le modèle de développement itératif [8]

d. La méthode de développement agile

L’approche AGILE s’organise autour de ce que l’on appelle des itérations. Il s’agit de
produire, pendant un certain temps, plutôt court mais suffisant, une partie du travail à réaliser
et de la communiquer au client ou demandeur en vue d’une validation par ce dernier du
travail ou fonctionnalité réalisé. D’après le manifeste agile cette approche repose sur 12
principes fondamentaux et 4 valeurs. La pratique de la méthode agile au cours des années
s’est diversifiée en différentes méthodes dites agiles. Parmi celle-ci, on peut citer :

 La méthode Scrum (la plus utilisée depuis 1996)

7
  La méthode Extreme Programming ;
 La méthode KANBAN [9].

1.1.3.2 Langage de modélisation

Il existe plusieurs langages de modélisation, cependant UML (Unified Modeling Language)
reste le plus utilisé. Il est couramment utilisé en développement logiciel et en conception
orientée objet. Il est ouvert et n’est la propriété de personne. Il est le résultat de la fusion de
précédents langages de modélisation objet : Booch, OMT, OOSE. Principalement issu des
travaux de Grady Booch, James Rumbaugh et Ivar Jacobson, UML est à présent un standard

adopté par l'Object Management Group (OMG) qui est l'organisation responsable de sa
définition et de son évolution. Il est utilisé pour spécifier, visualiser, modifier et construire les
documents nécessaires au bon développement d'un logiciel orienté objet.

1.1.3.3 Data warehouse (Entrepôt de donnée)

Un data warehouse est une collection de données orientées sujet, intégrées non volatiles et
historisées, organisées pour supporter un processus d’aide à la décision [10]. C’est une base
de données centralisée et intégrée qui stocke des données provenant de différentes sources
pour permettre leur analyse et leur utilisation ultérieure. Les données stockées dans un data
warehouse sont généralement historiques et orientées vers les sujets, ce qui signifie qu'elles
sont organisées autour de thèmes ou de sujets spécifiques, tels que les ventes, les clients, les
produits, les stocks, les finances.

1.1.3.4 ETL (Extraction, Transformation, Loading)

L'ETL est le processus qui permet de charger un data warehouse à partir de données
externes généralement issues de bases transactionnelles. Son rôle est de récupérer ces
données et de les traiter pour qu'elles correspondent aux besoins du modèle dimensionnel
[11].

1.1.3.5 Devups
Devups est un Framework camerounais de développement web open-source écrit en PHP
développe par l’entreprise SPACEKOLA. Il a été créé pour simplifier le processus de
développement web en offrant une structure de base pour les applications web. Il est basé sur
la combinaison de l'OOP/ORM stricte avec la simplicité de l’ORM (Object-Relational
Mapping) et la simplicité du querybuilder(template engine). De plus, il comporte un puissant
form builder, un form filling d'entité, un lazy loading, un data table, une entity collection, un

8
gestionnaire de fichiers et une activité sans état avec AJAX (Asynchronous JavaScript and
XML), ainsi que deux niveaux de modularité. Il dispose également d'un administrateur par
défaut avec une gestion complète des droits et des rôles sur les modules et les entités. Il est
basé sur le design pattern MVC(Modele-Vue-Controlleur) et son architecture se présente
comme suit :

Figure 1. 8: Architecture de Devups

1.2 Contexte du projet

Pour la réalisation de notre projet nous avons travaillé avec l’entreprise SPACEKOLA.
Dans cette section, nous allons présenter SPACEKOLA, puis donner le contexte, les objectifs
et les exigences fonctionnelles dans le cahier de charge du projet.

1.2.1 Présentation de l’entreprise SPACEKOLA

SPACEKOLA est une jeune agence de services informatiques dont le siège est à Yaoundé.
Elle a été fondée en 2014 sous l’initiative d’une équipe à la pointe de la technologie et de
l’innovation. A la base, elle se veut être le premier réseau social camerounais permettant de
s’informer tout en se divertissant ; puis elle étend ses activités dans les TIC (Technologie de
l’Information et de la Communication). Elle propose une offre globale pour tous projets
numériques et également des accompagnements et formations dans différentes technologies
du numérique.

9
Elle a à son actif plusieurs produits notamment : la Marketplace BUYAMSELLAM [12]qui
permet de promouvoir le commerce local et le Framework Devups qui est utilisé pour le
développement des applications au sein de SPACEKOLA.

Sa mission est de contribuer au développement du numérique en Afrique, en général et au

Cameroun en particulier. Pour mener à bien cette mission, SPACEKOLA s’appuie sur des
valeurs telles que le respect de l’éthique, le professionnalisme de son équipe et la satisfaction
du client.

1.2.1.1 Fiche d’identité

L’entreprise SPACEKOLA est une jeune startup qui travaille chaque jour afin d'offrir des
services adaptés aux besoins des clients.

Tableau 1. 1: Identité de SPACEKOLA

Dénomination sociale SPACEKOLA

Statut juridique ETS

Logo

Année de création 2014

Téléphone (+237) 670 103 490 / 691 120 531

Email info@spacekola.com

Adresse 8950, Carrefour MEEC, Yaoundé

Site internet http://spacekola.com

N RCCM RC/YAO/2018/A/172

1.2.1.2 Service de SPACEKOLA

Afin de répondre aux divers besoins des entreprises, SPACEKOLA offre une large gamme de
services dans le domaine des TIC : Site internet, application mobile, conception
infographique et des vidéos, web marketing.

Tableau 1. 2: Services de SPACEKOLA

Services Description

10
 Flyers, logo, Brochures, magazines, Vidéos
Graphisme
publicitaires, Design d’application

Référencement, Email personnalisé,

Service Web
maintenance site, hébergement

Développement d’applications Android et

Développement mobile
iOS

Site vitrine, site de e-commerce, application

Développement Web
web

Message de promotion, message

Vente de SMS
d’authentification, message de campagne

Formation en graphisme et en design, en

Formation /Coaching développement, en montage de projet,
campagne de marketing

Manipulation des données, stratégie de

BI / Big Data Consulting
gestion, technique d’analyse

1.2.1.3 Organigramme
L’équipe de SPACEKOLA est dirigée par 03 ingénieurs partageant la responsabilité
d'associé gérant et d’un staff technique d’environ huit membres.

11
 Figure 1. 9: Organigramme de SPACEKOLA

1.2.2 Perspectives de croissance des Saas de pharmacie en France

D’après une étude réalisée par la fondation ESSEC Junior Développement (EJD), la France
occupait en 2020 la 3eme place des acteurs européens du marché des logiciels SaaS avec 12%
de part de marché. D’autre part, selon une étude menée par Numeum et EY en 2021, le taux
d’adoption des logiciels SaaS en France était de 45% [13]. Tout ceci montre que des
plateformes SaaS de gestion de pharmacie en France présente des perspectives de croissance
intéressantes dans les années à venir, notamment pour plusieurs raisons :
 La numérisation accrue : Avec la pandémie de COVID-19, les pharmacies ont dû
s'adapter rapidement pour répondre aux besoins de leurs clients. De nombreux
consommateurs ont opté pour des achats en ligne, ce qui a stimulé la demande pour
des plateformes SaaS. Les pharmacies cherchent également à numériser leurs
opérations pour améliorer leur efficacité et leur rentabilité.
 La personnalisation : Les plateformes SaaS de gestion de pharmacie offrent des
fonctionnalités de personnalisation qui permettent aux pharmacies de créer des
expériences uniques pour leurs clients. Par exemple, les pharmacies peuvent utiliser
ces plateformes pour envoyer des rappels de renouvellement des prescriptions et des
offres personnalisées aux clients.
 La concurrence croissante : Avec la concurrence croissante dans le secteur de la
pharmacie en France, les pharmacies cherchent à se différencier en offrant des
services plus innovants et personnalisés. Les plateformes SaaS de gestion de

12
 pharmacie peuvent les aider à atteindre cet objectif en leur offrant des outils pour
mieux gérer leur entreprise et améliorer leur service client.

1.2.3 Etude de l'existant

Aujourd’hui beaucoup de pharmacies utilisent des logiciels pour gérer leur activité au
quotidien. La solution cloud est une pratique de plus en plus récurrente dans le secteur
pharmaceutique. En effet les logiciels de gestion de pharmacie SaaS sont des solutions qui
permettent aux pharmacies de gérer efficacement leur activité en utilisant des fonctionnalités
telles que la gestion des stocks, des ventes, des commandes, des dossiers médicaux des
patients, la planification des rendez-vous, la communication avec les patients.

1.2.3.1 Présentation des différents acteurs

Avec l’augmentation du taux d’adoption des solutions cloud, de plus en plus d’acteurs
s’intègrent dans le domaine Pharmaceutique.

a. Winpharma cloud
Winpharma cloud est une version cloud du logiciel de gestion intégré de pharmacie
Winpharma qui est hébergée sur le cloud. Winpharma cloud offre toutes les
fonctionnalités du logiciel Winpharma à savoir:
 La gestion du stock,
 La gestion des ventes,
 La gestion de l’ordonnance,
 La gestion des clients,
 La gestion des fournisseurs.
Les coûts d'acquisition de Winpharma Cloud varient en fonction de la taille et de la
complexité de votre organisation. Voici quelques-uns des facteurs qui peuvent influer sur le
coût: le nombre d'utilisateurs, la quantité de données stockées, etc. Les frais d’abonnements
se font de façon mensuelle et annuelle. Par exemple, une petite organisation comptant 10
utilisateurs et 1 To de données peut payer quelques milliers de dollars par an pour
Winpharma Cloud. Une grande organisation avec 1 000 utilisateurs et 10 To de données peut
payer des dizaines de milliers de dollars par an.
b. NextPharm

13
 NextPharm cloud est un système de gestion intégré de pharmacie basé sur le cloud, conçu
pour permettre aux pharmacies de gérer leur activité de manière efficace et rentable.
NextPharm offre plusieurs fonctionnalités à savoir:
 La gestion de stock,
 La gestion de vente,
 La gestion des ordonnances ;
 La gestion des clients ;
L’intégration à d'autres systèmes devient plus facile avec NextPharm cloud. Il fournit des
données et des informations en temps réel sur les activités de la pharmacie. Cela peut vous
aider à prendre de meilleures décisions et à améliorer les services rendus aux patients.
Les frais d'abonnement à NextPharm cloud sont basés sur le nombre d'utilisateurs et la
quantité de données analysées. Le prix commence à 10 000 dollars par an pour un seul
utilisateur et 100 Go de données. Pour un plus grand nombre d'utilisateurs et de données, le
prix augmente.

c. PioneerRx cloud
PioneerRx cloud est un système de gestion de pharmacie basé sur le cloud proposé par
PioneerRx, une entreprise spécialisée dans les logiciels de gestion de pharmacie. Il aide les
pharmacies indépendantes à rationaliser leurs opérations, à améliorer les soins aux patients et
à gérer efficacement leur pharmacie. Il offre une suite complète de fonctionnalités,
notamment :
 La gestion des stocks;
 La gestion des formulaires de suivi des commandes et des factures;
 La gestion des réclamations.
Les frais d'abonnement à PioneerRx varient en fonction de la taille de la pharmacie et des
fonctionnalités sélectionnées. Les frais d'abonnement de base pour une petite pharmacie
commencent à 50 $ par utilisateur et par mois. Des fonctionnalités supplémentaires, telles que
la prescription électronique et la vérification des interactions médicamenteuses, peuvent
augmenter le coût.

d. Id (ex LGPI)
Id est un logiciel de gestion de pharmacie SaaS conçu par la société Pharmagest Interactive.
Il aide les pharmaciens à gérer efficacement leurs activités notamment à travers :
 La gestion de stocks;

14
  La gestion des ventes et des commandes;
 La gestion des dossiers médicaux des patients et la planification des rendez-vous.
Les tarifs d'abonnement d’Id dépendent de plusieurs facteurs, tels que le nombre
d'utilisateurs, les fonctionnalités sélectionnées et la durée de l'abonnement. Les tarifs varient
également en fonction de la région géographique où se trouve la pharmacie.

1.2.3.2 Critique de l'existant

Bien qu'étant populaire et efficace chaque acteur présente de nombreuse critique sur plan
technique et financier.

Tableau 1. 3: Avantages et limites de l’existant

plateforme avantages limites

Winpharm -Assistance : Winpharma offre une -Coût : Le coût de Winpharma

cloud assistance 24h/24 et 7j/7 pour aider les peut être un obstacle pour
pharmacies à tirer le meilleur parti du certaines pharmacies.
système. - Peut nécessiter une formation
- Dispose d'une interface intuitive et pour une utilisation optimale.
facile à utiliser.

NextPharm -Interface utilisateur conviviale : -Coût : Le coût de NextPharm

cloud l'interface utilisateur de NextPharm est peut être un obstacle pour
intuitive et facile à utiliser, ce qui peut certaines pharmacies.
aider les utilisateurs à s'adapter -Courbe d'apprentissage : En
rapidement au système raison de la complexité de
-Gestion de stock en temps réel : certaines fonctionnalités, il peut
NextPharm offre une gestion de stock en y’avoir une courbe
temps réel, ce qui permet aux pharmacies d'apprentissage plus longue pour
de surveiller leurs niveaux de stock et de les utilisateurs de NextPharm
commander des médicaments en
conséquence.

15
 PioneerRx -Mises à jour automatiques : PioneerRx -Limitations de stockage :
cloud Cloud est mis à jour automatiquement, ce PioneerRx Cloud peut avoir des
qui garantit que les pharmacies utilisent limitations en termes de
toujours la dernière version du logiciel stockage.
avec les fonctionnalités les plus récentes -Complexité de l'interface : La
et les corrections de bogues. complexité de l'interface peut
poser des problèmes pour les
-Sécurité : PioneerRx Cloud utilise des utilisateurs, ce qui peut
mesures de sécurité avancées pour nécessiter une formation
protéger les données sensibles des supplémentaire.
patients et respecter les réglementations
HIPAA.

Id(ex - Interface utilisateur intuitive et facile à - Coût : Le coût du système de

LGPI) utiliser. pharmacie Id peut être un
- la personnalisation du logiciel pour obstacle pour certaines
répondre aux besoins spécifiques de pharmacies.
chaque pharmacie. - Ne dispose pas de
Fonctionnalités pour la
communication avec le patient
-

1.2.3.3 Solution
Les technologies de l’internet connaissent actuellement un bouleversement radical : l’accès
classique au web via des ordinateurs de bureau et portables n’est plus seulement complété,
mais de plus en plus remplacé par l’usage de dispositifs du cloud. Toutes les études récentes
et les rapports sur les tendances à propos du développement d’Internet et du cloud s’accorde à
dire que la dématérialisation des ressources non seulement physique mais également logiciel
dans le cloud représente l’avenir pour les entreprises qui se veulent prospères, ambitieuses et
pérennes.
L’étude de l’existant nous a permis de dégager plusieurs anomalies que nous avons détaillées
dans la section précédente. Pour corriger ces anomalies nous proposons de concevoir et
d’implémenter une plateforme Saas intuitive et conviviale. Elle aura pour objectif de se servir

16
des données qui sont générées par l’activité des pharmacies pour optimiser la prise de
décision au sein de celles-ci. Elle viendra se brancher au système existant de la pharmacie et
permettra de conserver la structure de ses données tout en automatisant d’avantage les
processus de la pharmacie dont la gestion des tâches et du personnel.

1.2.4 Cahier de Charge

Le cahier de charges est un document contractuel à respecter lors d’un projet. Il permet au
maître d’ouvrage de faire savoir au maître d’œuvre ce qu’il attend de lui lors de la réalisation
du projet. Nous exprimerons donc les besoins de l’entreprise en respectant la formule « Coût
délai qualité ».

1.2.4.1 Contexte et Problématique

Avec l'avènement du numérique, de nombreux secteurs ont connu des transformations
importantes. Le secteur pharmaceutique n’en n’est pas des moindres, vue qu’il représente un
secteur d’activité cruciale pour notre survie. Dans le contexte actuel de la pandémie de
COVID-19, l'industrie pharmaceutique a été soumise à une forte pression pour produire des
médicaments et des vaccins efficaces dans des délais très courts. Ainsi pour faciliter la
gestion de leurs différentes activités plusieurs pharmacies utilisent des solutions
logicielles telles que : Microsoft Excel, des logiciels web et desktop personnalisés. Ces
solutions leur génèrent un gain de temps, d’énergie et permettent de passer outre les erreurs
humaines.
Cependant, lorsqu’on fait immersion dans leurs fonctionnements, on fait vite de remarquer
que ces logiciels sont incapables d’utiliser les données qui sont générées par ses instituts pour
améliorer les performances opérationnelles et la prise de décision.
Ses manquements montrent pourquoi il est crucial de développer une plateforme nommée
MEDOCLAB, qui permettra aux pharmacies et aux laboratoires médicaux d'optimiser leurs
activités. Grâce à celle-ci, ils pourront analyser et interpréter les données qu’ils collectent, ce
qui leur permettra de prendre des décisions plus éclairées et plus efficaces. De plus, cette
plateforme permettra également une meilleure collaboration et communication entre les
différents secteurs, améliorera ainsi les relations et la coordination entre les pharmacies, les
laboratoires et les professionnels de la santé. En tirant parti de la puissance des données, cette
plateforme pourra aider à améliorer la qualité du système de santé en rendant les informations
concernant la disponibilité des médicaments accessible aux patients.

17
1.2.4.2 Objectifs
De nos jours, la donnée informatique est un élément vital pour toute entreprise qui se veut
prospère et pérenne. Pour cela elle doit être hautement disponible et fiable.

Les pharmacies produisent d’énorme quantités de données lies aux patients, à la grande
quantité de médicaments et produits de santé ainsi qu’aux personnels de celles-ci.

Malheureusement ces données ne sont pas toujours utilisées à bon escient. Il faut donc créer
un cadre dans lequel on pourra utiliser au mieux le potentiel de ces données, tant pour
faciliter la gestion des officines et maximiser leur rentabilité que pour améliorer le suivi des
patients et la qualité du service au sein de celles-ci.

Ainsi donc la plateforme MEDOCLAB a pour objectifs :

 Permettre à un pharmacien d’avoir une vue globale de l’état financier de sa ou ses

pharmacies;
 Permettre un accès en temps réel et sécurisé des informations sur les patients, les
produits et le personnel;
 Optimiser la gestion du stock. On pourra ainsi prévoir quels produits sont les plus ou
les moins vendus et anticiper sur leur rupture en stock;
 Améliorer le suivi du personnel et la planification des taches au sein de la pharmacie;
 Favoriser la communication entre les pharmacies quant à la disponibilité des
médicaments et donc réduire le temps de recherche de ces derniers.

1.2.4.3 Description fonctionnelle

Cette phase consiste à détailler l’ensemble des fonctionnalités que l’application doit fournir.
Ces besoins seront présentés sous forme de besoins fonctionnels et non fonctionnels. Chaque
fonctionnalité étant réalisé par un utilisateur spécifique, il convient de préciser d’abord les
acteurs de notre système.

a. Les acteurs du système

Sur la plateforme MEDOCLAB, on recense divers acteurs dont les principaux sont :
 Les pharmaciens,
 Les gérants
 Le personnel ou employer (un stagiaire, le caissier, les conseillers en santé)
 Les administrateurs de l’ensemble du système.

18
b. Besoin fonctionnel
Encore appelés besoins utilisateur, les besoins fonctionnels sont les fonctionnalités du
système qui répondent directement aux exigences exprimées par le client et dont l’exécution
aidera à résoudre un sous problème identifié. Ils induisent les qualités fonctionnelles
attendues en termes des services offerts.
Pour aider les utilisateurs dans leur démarche, l’application offrira un certain nombre de
services via un espace personnel accessible depuis internet. Ce sont :
 L’authentification : le système doit permettre à un utilisateur de s’inscrire et de se
connecter pour accéder à son espace.
 La gestion des comptes et la supervision : le système doit permettre aux administrateurs
de gérer, et valider les inscriptions d’un pharmacien et une pharmacie sur la plateforme.il
doit aussi permettre de gérer les différents comptes utilisateurs et l’attribution des droits
aux utilisateurs.
 La gestion des tâches : le système permettra au pharmacien ou au gérant de gérer
efficacement la planification, l’attribution et le suivis des tâches au sein de sa ou ses
pharmacies.il pourra avoir une vision globale sur l’état d’avancement des différentes
tâches suivant le statut de celles-ci ou alors leur priorité. Un personnel (stagiaire,
pharmacien adjoint…) pourra aussi être notifié des tâches qui lui sont attribués et les
consulter dans son espace.
 La gestion du personnel : le système doit permettre au pharmacien ou au gérant de
visualiser l’effectif de son personnel, la répartition ainsi que l’évolution de ses équipes
dans sa ou ses pharmacies. Il pourra suivre les présences de son personnel ainsi que
l’impact sur son chiffre d’affaire des différentes proportions de ses équipes.
 L’abonnement : le pharmacien pourra souscrire à un abonnement sur la plateforme qui
lui donnera certains privilèges en fonction de la formule achetée.

c. Besoin non fonctionnel

Les besoins non fonctionnels permettent l'amélioration de la qualité logicielle de notre
système. Elles sont généralement des besoins non exprimés par le client mais qui agissent
comme des contraintes sur des solutions. Leur prise en considération fait éviter plusieurs
incohérences dans le système :
 L’ergonomie : ce sont l’ensemble des contraintes liées à l’adaptation entre les
fonctionnalités de l’application, les interfaces et leur utilisation. Pour respecter ces

19
 contraintes, les interfaces doivent être simples et compréhensible avec le respect du
code de couleurs ; les informations doivent être organisée en rubrique sous des
onglets afin de rendre l’application intuitive et attrayante.
 La fiabilité : l’application doit fonctionner de façon cohérente sans erreurs
(l’utilisateur doit avoir confiance en la qualité du système).
 L’accessibilité : les utilisateurs doivent avoir accès au système, 24h/24
 La maintenabilité : le code doit être maintenable pour faciliter toute opération
d’amélioration ou d’optimisation.
 La sécurité : La plateforme doit être sécurisée et doit pouvoir contrer les attaques
informatiques les plus basiques.
 L’interopérabilité : notre application doit fonctionner de façon optimale et sans
restriction sur un environnement contenant d’autres applications.

1.2.4.4 Les contraintes du projet

Les contraintes font référence à des limitations ou des restrictions qui sont imposées au
projet et qui peuvent affecter sa portée, son budget, sa qualité ou son calendrier.

a. Les contraintes de délais

L’application devra être livrée en respectant les délais établis entre le maitre d’œuvre et le
maitre d’ouvrage.

b. contraintes de qualité
Selon l'AFNOR (Association Française de Normalisation) de juillet 1982 : "La qualité est
l'ensemble des caractéristiques intrinsèques d'une entité qui lui confèrent l'aptitude à satisfaire
des besoins exprimés ou implicites". Pour qu’un logiciel ou une application soit de qualité,
celui-ci doit intégrer des caractéristiques bien définies afin de répondre aux attentes du client.
On en distingue principalement deux : les critères de qualité externes (coter utilisateur) et les
critères de qualité interne (coter concepteur).
Comme critères de qualité externe on doit avoir :
 La Conformité ou Validité : c’est la capacité du logiciel à répondre aux besoins des
Utilisateurs tels que les conventions préétablies soient respectées.
 La convivialité c’est l’aisance avec laquelle les utilisateurs pourront apprendre à
utiliser le logiciel. D’une manière générale, elle renvoie à l’ergonomie visant à
l’adaptation des machines et logiciel à l’homme (dans tous ses aspects physiologique,

20
 psychologique…) pour une utilisation avec un maximum de confort. Elle recouvre
également la facilité d’installation, d’opération et de contrôle.
 Sécurité : cela renvoie au respect de la confidentialité et de l’intégrité des données
ainsi qu’à la gestion des droits d’accès ou privilèges.
 Fiabilité : tolérance aux pannes ou à certains manquements. Autrement dit, le logiciel
doit être capable d’assurer la continuité dans les services qu’elle vient rendre.
 Performance : le logiciel doit répondre dans les délais court aux requêtes, avoir un
bon débit, fluidité etc.
 Efficacité : c’est la capacité qu’aura le logiciel à remplir ou à retourner le résultat
exact des tâches lui ayant données naissance avec une utilisation minimale de
ressources avec lesquelles il doit interagir.
Comme critères de qualité interne on doit avoir :
 Modularité : Aptitude d’un logiciel à être structuré en composants ou modules
indépendants. Ceci revient à juger la pertinence de la fonction de chaque module et de
ses interactions avec les autres modules.
 Portabilité : facilité avec laquelle des produits logiciels peuvent être transférés d’un
environnement logiciel ou matériel à l’autre.
 Robustesse : capacité qu’offrent des systèmes logiciels à réagir de manière appropriée
lorsqu’une condition anormale (fausse manipulation de la part de l’utilisateur)
survient.
 La réutilisabilité : c’est la capacité des éléments logiciels à servir à la construction de
plusieurs autres applications différentes.
 L’extensibilité ou flexibilité : c’est la facilité d’adaptation des produits logiciels aux
Changements de spécifications.
 Lisibilité : ceci renvoie à la clarté, c’est-à-dire l’organisation donnée au code source
afin qu’il soit compréhensible et facilement modifiable.
 L’interopérabilité c’est la capacité pour un logiciel à pouvoir interagir avec d’autres
entités partageant le même environnement.

1.2.4.5 La ressource humaine du projet

Les acteurs qui participent activement dans la réalisation du projet sont résumés dans le
tableau ci-dessous :
Tableau 1. 4: Ressource humaine du projet

21
 Noms et prénoms Fonction Rôles

M. Aurélien ATEMKENG CTO Maitre d’ouvrage et

superviseur Technique
M. Christian Patrick CTO Maitre d’ouvrage
KUETCHE
M. Arnold Borele KENGNE Etudiant en cinquième année Concepteur et réalisateur du
à l’ENSPD projet
M. Ulrich yvan Tankoua Etudiant en cinquième année Concepteur et réalisateur du
Ntchantchou à l’ENSPD projet

1.2.4.6 Planification du projet

La clé principale de la réussite d’un projet est un bon planning. En effet, le planning aide à
bien subdiviser le travail et séparer les taches à réaliser, il offre une meilleure estimation et
gestion de temps nécessaire pour chaque tâche. Pour notre planification de projet nous avons
utilisé le diagramme de Gantt.
Le diagramme de Gantt, couramment utilisé en planification de projet, est l’un des outils les
plus efficaces pour représenter visuellement l’état d’avancement des différentes
activités(tâches) qui constituent un projet. La colonne de gauche du diagramme énumère
toutes les tâches à effectuer, tandis que les lignes représentent les unités de temps les plus
adaptées au projet (jours, semaines, mois). Chaque tâche est matérialisée par une barre
horizontale, dont la position et la longueur représentent la date de début, la durée et la date de
fin.

22
 Figure 1. 10: Diagramme de Gantt

1.2.4.7 Les Livrables

A la fin des délais fixés pour le développement de cette solution, les éléments qui feront
office de livrables seront les suivants :
 Un dossier d’analyse et de conception
 Le code source de l’application web
 Une documentation utilisateur
 Le plan de déploiement

Dans ce chapitre, il était question de présenter l’état de l’art sur les solutions de gestion des
pharmacies, le contexte dans lequel s’inscrit notre projet ainsi que son cahier de charge. Dans
les prochains chapitres nous aborderons l’analyse et la conception de ce dernier.

CHAPITRE 2 : ANALYSE ET CONCEPTION

Dans ce chapitre il sera question de faire l’analyse et la conception de notre solution. Dans
un premier temps nous aborderons la méthodologie utilisée, l’analyse de notre data
warehouse et de l’application ainsi que leurs différents diagrammes et modélisation. Puis
nous présenterons l’architecture du système. Enfin les différents outils de développements.

23
1.3 Méthodologie
Comme méthode de développement, nous avons opté pour la méthode agile Scrum. Elle est
la plus utilisée et contrairement aux méthodes classiques, c’est une méthode de
développement incluant le client dans la quasi-totalité du projet ; de la conception à la
réalisation en passant par le recueil des besoins et les tests fonctionnels. Cette approche est
largement recommandée car elle permet d’éviter au maximum des résultats non satisfaisants.
Scrum est le cadre de développement agile le plus populaire car il est relativement simple à
mettre en œuvre.

Figure 2. 1: une itération selon la méthode Scrum

Il résout également de nombreux problèmes auxquels les développeurs de logiciel étaient

confrontés dans le passé, tels que les cycles de développement complexes, des plans de
projets rigides et des calendriers de production changeants.

Dans cette méthode, une petite équipe est dirigée par un Scrum master dont la tâche
principale est d’éliminer tous les obstacles pour que le travail soit fait plus efficacement.
L’équipe travaille selon des cycles courts de deux semaines appelés sprints.

1.3.1 Les acteurs dans un projet Scrum

Dans un projet Scrum, l’on identifie trois acteurs : le product owner, le Scrum master
et l’équipe.
 Product owner : il possède l’expertise fonctionnelle et, est capable de réaliser les
arbitrages nécessaires à la priorisation des fonctionnalités à développer. Ce rôle est
assuré conjointement par M. Christian Platini KUETCHE et M. Aurélien
ATEMKENG.
 Scrum master : c’est un membre de l’équipe dont la tâche principale est d’optimiser
la capacité de production de l’équipe en l’aidant à travailler de façon autonome et à

24
 s’améliorer constamment : c’est Mlle. Orchelle Patricia WELEHELA
TAWEUTEU qui assure ce rôle.
 L’équipe : c’est un groupe de personnes chargé du développement du produit
(codage, tests, documentation) sans spécialisation de rôles. Ces rôles sont assurés par
M. Arnold Borele KENGNE et M. Ulrich yvan Tankoua Ntchantchou.

1.3.2 Les artefacts de Scrum

Scrum définit différents artefacts :
 Une user story : qui est une forme simplifiée et faiblement détaillée des cas
d’utilisation et doit se focaliser sur des objectifs métiers du logiciel. Entre autre on
peut avoir la user story s’enregistrer ou se connecter.
 Le product Backlog : il est fondamental à Scrum et décrit la liste des fonctionnalités
du logiciel rédigées sous forme de user stories. Notre product backlog est constitué de
tous les cas d’utilisation du logiciel et des tâches de réalisation du data warehouse.
 Le backlog du sprint : c’est un mini product backlog spécifique aux user stories à
réaliser pendant une période de sprint. Ce dernier dure une a deux semaines.
1.4 Analyse des fonctionnalités
Cette phase nous permettra de recenser les différentes fonctionnalités de notre solution et de
pouvoir structurer notre système.

1.4.1 Analyse des besoins métiers du data warehouse

L'analyse des besoins d'un entrepôt de données est le processus d'identification des besoins
de l'entreprise en matière de cet entrepôt. Cette analyse est essentielle à la réussite de la
conception et de la mise en œuvre d'un entrepôt de données.

1.4.1.1 Identification des parties prenantes

Dans nos pharmacies, les parties prenantes pourraient inclure :
 Les responsables de la gestion des stocks qui ont besoin de données sur les niveaux de
stock, les délais de livraison et les taux de rotation des stocks pour optimiser la
gestion des stocks
 Les responsables du marketing qui ont besoin de données sur les comportements
d'achat des clients et les campagnes publicitaires pour améliorer les stratégies de
marketing.

25
  Les responsables chaîne d'approvisionnement qui ont besoin de données sur les
fournisseurs, les délais de livraison et les coûts pour optimiser la chaîne
d'approvisionnement
 Les analystes financiers qui ont besoin de données sur les marges bénéficiaires, les
coûts et les revenus pour améliorer la rentabilité de l'entreprise.
 Le pharmacien et le gérant seront responsables de toute les données.

1.4.1.2 Exigences
Pour répondre aux besoins métiers de la pharmacie, les exigences métiers pour le data
warehouse incluent les données suivantes :
 Données de vente : Les données de vente peuvent inclure les informations sur les
produits achetés, les quantités, les prix. Ces données peuvent aider les responsables de
la gestion des stocks, les responsables du marketing et les analystes financiers à
comprendre les tendances de vente et à optimiser les stratégies commerciales.
 Données de produit : Les données de produit peuvent inclure les niveaux de stock, les
délais de livraison et les taux de rotation des stocks. Ces données peuvent aider les
responsables de la gestion des stocks et les responsables de la chaîne
d’approvisionnement à optimiser la gestion des stocks et à réduire les coûts.
 Données de fournisseur : Les données de fournisseur peuvent inclure les informations
sur les fournisseurs, les délais de livraison et les coûts. Ces données peuvent aider les
responsables de la chaîne d’approvisionnement à optimiser la chaîne
d’approvisionnement et à réduire les coûts.
 Données de client : Les données de client peuvent inclure les informations sur les
clients, les comportements d’achat, les préférences et les commentaires. Ces données
peuvent aider les responsables du marketing à améliorer les stratégies de marketing et
à personnaliser l’expérience d’achat des clients.
 Données d’ordonnance : les donnée d’ordonnance peuvent inclure les informations
sur le médecin en vue de déterminer la compétence du médecin.

1.4.1.3 Source de données

En effectuant l’identification des sources de données, nous serons en mesure de collecter les
informations nécessaires pour répondre aux exigences métiers du data warehouse. Cela
permettra également de déterminer les processus d'extraction, de transformation et de
chargement (ETL) nécessaires pour intégrer les données dans le data warehouse. Les
différentes sources de données sont :

26
  Système de gestion des ventes : Ce système contient des données sur les ventes de
médicaments et de produits liés à la santé, y compris les quantités vendues, les prix,
les informations de paiement. Les données de vente seront importantes pour répondre
aux exigences métiers liées à l'analyse des ventes, à la gestion des stocks et à la
planification de la demande.
 Système de gestion des stocks : Ce système contient des données sur les niveaux de
stock, les délais de livraison des fournisseurs, les taux de rotation des stocks, les coûts
d'inventaire et les informations sur les produits. Les données de gestion des stocks
seront importantes pour répondre aux exigences métiers liées à la gestion des stocks, à
la commande de réapprovisionnement et à la gestion des coûts.
 Système de gestion des fournisseurs : Ce système contient des données sur les
fournisseurs de médicaments et de produits liés à la santé, y compris les contrats, les
prix, les délais de livraison, les normes de qualité et les informations de contact. Les
données de gestion des fournisseurs seront importantes pour répondre aux exigences
métiers liées à la gestion des relations avec les fournisseurs, à la gestion des coûts et à
la chaîne d'approvisionnement.

1.4.2 Analyse des fonctionnalités de l’application

Dans cette section nous allons présenter les différentes fonctionnalités en fonction des
différents utilisateurs mentionnés dans le cahier des charges :
Tableau 2. 1: Identification de l'acteur "Pharmacien"
Pharmacien
Responsabilités: Délivrer les médicaments, Conseiller les patients, Respecter les
règles de déontologie.
Niveau de Intermédiaire
Compétence :
Fréquence Courte utilisation quotidienne
d’utilisation :
Autorité : C’est Le responsable de l’établissement et occupe donc le plus haut
niveau d’autorité dans l’organisation mais dans notre application son
compte ne possède pas les droits « Administrateur ». Il devra
s’adresser à l’administrateur ou endosser les deux rôles pour
effectuer les actions critiques.
Permissions : En plus des permissions du gérant, Il peut :

27
 -s’inscrire sur la plateforme et enregistrer une pharmacie
-acheter un abonnement

Ce tableau présente l’ensemble des permissions accordées au pharmacien. En effet il a une

courte utilisation quotidienne du logiciel et a de grandes responsabilités au sein de la
pharmacie.
Tableau 2. 2: Identification de l'acteur "Administrateur"
L’administrateur
Responsabilités: Saisir et gérer les comptes des utilisateurs.
Nettoyer le système en fin d’année pour supprimer les données qui
ne sont plus utiles(personnels démissionnaires …)
Niveau de Expert
Compétence :
Fréquence Fréquente
d’utilisation :
Autorité : Le personnel technique ne dépend que du responsable de
l’établissement.
Permissions : L’administrateur a les pleins pouvoirs sur le système et a donc le plus
haut niveau de privilège.

Ce tableau résume les cas d’utilisations de l’administrateur. Il passe beaucoup plus de temps
sur le logiciel et a tous les droits sur le système.
Tableau 2. 3: Identification de l'acteur "Gérant"
Gérant
Responsabilités: Il doit s’occuper de la gestion administrative, financière,
commerciale et de ressources humaines.
Niveau de Intermédiaire
Compétence :
Fréquence Courte utilisation quotidienne
d’utilisation :
Autorité : Dans l’organigramme de la pharmacie le gérant est sous l’autorité du
pharmacien. Dans notre application cette autorité est représentée par
‘administrateur.

28
 Permissions : Il peut :
-consulter les informations de tout le personnel
-gérer les taches (créer, lister, modifier, supprimer) les taches
-visualiser l’évolution de l’effectifs du personnel

Ce tableau présente l’ensemble des droits du gérant de la pharmacie. Il pour responsabilités

de gérer l’ensemble du personnel.

Tableau 2. 4: Identification de l'acteur "Personnel"

Personnel(stagiaire …)
Responsabilités: Effectuer les tâches qui lui sont confiés au sein de la pharmacie
Niveau de Intermédiaire
Compétence :
Fréquence Courte utilisation quotidienne
d’utilisation :
Autorité : Il est sous l’autorité du gérant et du pharmacien
Permissions : Les privilèges qu’ils ont se limite à :
-consulter leur profil personnel,
-planifier leur présence
-consulter les différentes tâches

Ce tableau décrit l’ensemble des droits du personnel. En effet le personnel a une utilisation
courte mais quotidienne du système et est chargé dans la plupart des cas de l’exécution des
tâches.
1.5 Conception
La conception informatique est le processus de création d’un système informatique. Elle
consiste à appliquer les concepts liés aux fonctionnalités du système.

1.5.1 Architecture du système

Notre système se compose principalement de trois parties :
 Le data warehouse qui utilise un ETL pour récupérer les données des pharmacies ;
 L’API (Application Programming Interface) fait en Devups qui récupère les données
du data warehouse et les envoie vers le Frontend;
 Une partie Frontend ou cliente où l’on consulte ses données.

29
 Figure 2. 2: : Architecture de Medoclab

Dans cette architecture nous récupérons les données directement des pharmacies avec
l’ETL. Ce dernier nous permet de transformer ces données en fonction de notre modèle, puis
on stocke ces données dans notre data warehouse qui interagit avec l’API, lui aussi
communiquant avec l’interface client.

1.5.2 Modélisation dimensionnelle du data warehouse

Dans un Data Warehouse, les données et leurs relations sont organisées suivant un modèle
de données spécifique. Le choix du modèle de données structure et définit le design du Data
Warehouse. Il existe trois modélisations possibles: le modèle en étoile, le modèle en flocon et
le model en constellation. Dans n’importe quelle modélisation dimensionnelle, il faut
distinguer deux types de tables. C’est le mode d’interconnexion des tables qui caractérise une
modélisation. Notre modèle comprendra des tables de dimension qui décrivent les aspects
qualitatifs des données et des tables de faits qui contiennent des mesures numériques
quantitatives.

1.5.2.1 Table de dimension

En effet Les tables de dimensions sont utilisées pour décrire les données que l’on souhaite
stocker dans le Data Warehouse. Les tables de dimension sont souvent utilisées pour filtrer et
regrouper les données dans les requêtes, et sont généralement connectées à la table de faits
dans le modèle de données. Comme table de dimension on a :
 Dimension client : Ici nous avons la table de dimension client qui permettra
d’analyser les activités du client au sein de la pharmacie.

Tableau 2. 5: Table de dimension client

30
 Désignation détail

Id_client Identifiant de la dimension client

nom Le nom du client

adresse Adresse du client

Date de naissance Date de naissance du client

Cette table présente les différentes propriétés de l’entité client liée à une pharmacie. On a
entre autre : son nom, son adresse et sa date de naissance.
 Dimension produit : cette dimension est importante car elle va permettre de
connaitre le stock des produits.

Tableau 2. 6: Table de dimension produit

Désignation détail
Id_produit Identifiant de la dimension produit
commander
nom Nom du produit
Quantité Quantité du produit
Prix Point de commande produit
Prix_vente Prix de vente
Date_exp Date d’expiration du produit

Cette table montre les propriétés d’un produit : son id, son nom, la quantité, le prix.
 Dimension fournisseur : Elle est utile car elle permettra de connaitre si le produit
d’un fournisseur est le plus vendu ou le moins vendu.

Tableau 2. 7: Table de Dimension fournisseur

Désignation détail
Id_fournisseur Identifiant du fournisseur
ref Reference de la pharmacie
nom Nom du fournisseur
adresse Adresse du fournisseur
coordonnées Coordonnées du fournisseur

31
Elle précise les propriétés du fournisseur lié à une pharmacie : ses coordonnées, son adresse.
 Dimension pharmacie : Cette table nous permettra de savoir à qui appartient la
pharmacie et les différents employés de pharmacie
Tableau 2. 8: Table de dimension pharmacien
Désignation Détail
Id_pharmacie Identifiant du pharmacien
nom Nom du pharmacien
gérant Nom du gérant
adresse Adresse du pharmacie
Téléphone Téléphone du pharmacie

Cette table présente les différentes propriétés de la pharmacie. Cela permet d’avoir les
différents éléments d’une pharmacie donnée.
 Dimension médecin : Cette dimension permettra d’avoir les informations sur le
médecin qui établit l‘ordonnance d’un client.
Tableau 2. 9: Table de dimension du médecin
Désignation détail
Id_medecin Identifiant de la médecin

nom Le nom du médecin

prénom Prénom du médecins

Elle permet d’identifier le médecin qui prescrit un médicament avec son nom, son prénom.
 Dimension remise : Cette dimension permettra de répertorier les produits ayant eu
une remise et le client concerné pour permettre une analyse.
Tableau 2. 10: Table de dimension de la remise
Désignation détail
Id_remise Identifiant de la remise
Montant Montant de la remise
Type Le type de la remise

Elle donne les différentes propriétés sur une remise liée à un produit telle que le montant de la
remise et le type de remise.

32
  Dimension date : Cette dimension permet de faire ressortir le moment précis où
l’enregistrement a été fait pour permettre l’analyse des différentes informations de
l’entreprise en fonction du temps.
Tableau 2. 11: Table de dimension de date
Désignation Détail
Id Identifiant date
heure Heure de commande
jour Jour de commande
année Année de commande

Cette table donne les propriétés du temps lie chaque entité de la pharmacie : le jour,
l’heure et l’annee.
 Dimension dateliv : Cette dimension permet de faire ressortir le moment précis où
l’enregistrement a été fait pour permettre l’analyse des différentes informations de
l’entreprise en fonction du temps.
Tableau 2. 12: Table de dimension de dateliv
Désignation Détail
Id dates Identifiant date de livraison
heure Heure de la livraison
mois Mois de la livraison
année Année de la livraison

1.5.2.2 Table de fait

Les tables de faits contiennent les données que l’on souhaite voir apparaître dans les
rapports d’analyse, sous forme de métriques. Les données des tables de faits sont agrégées à
partir des tables de dimensions qui leur sont associées. La table de faits se présente sous la
forme d’un ensemble de colonnes stockant les valeurs et les clés étrangères (identifiants)
associées aux tables de dimensions [14]. Dans nos pharmacies, nos tables de faits seront les
tables : commander et inventaire.
 Table de fait commander : Elle va nous permettre d’avoir les informations globales
sur un produit (le client ; le pharmacien …).
Tableau 2. 13: Table de fait commander

33
 Désignation détail
Id_commande Identifiant de la commande
Id_client Identifiant du client
Id_produit_commander Identifiant du produit
Id_medecin Identifiant du médecin
Id_pharmacie Identifiant du pharmacien
Id_date Identifiant de la date de la commande
Id_remise Identifiant de remise

Elle ressort les données spécifiques et utiles sur les produits telles que l’id du client, l’id
de sa pharmacie et sa remise.
 Table de fait inventaire : La table de fait stock permettra de créer une connexion
entre le produit et le fournisseur.
Tableau 2. 14: Table de fait stock
Désignation détail
Id Identifiant
Id_produit Identifiant du produit
Id_fournisseur Identifiant du fournisseur
Id_pharmacien Identifiant du pharmacien
Id_date Identifiant de la date

1.5.2.3 Le modèle physique

Dans un data warehouse, il existe plusieurs types de modèles qui sont utilisés pour
organiser les données et faciliter leur analyse. On a :

 Le modèle en Etoile : c’est un modèle de données largement utilisé dans les data
warehouse. Il est simple, facile à comprendre et à utiliser. Il se compose d'une table de
faits centrale qui est entourée de plusieurs tables de dimensions.
 Le modèle en flocon de neige : c’est une variante du modèle en étoile qui est utilisée
pour réduire la redondance des données dans un data warehouse. Dans ce modèle, les
tables de dimensions sont normalisées pour réduire la répétition de données
descriptives, ce qui crée une structure en forme de flocon de neige plutôt qu'une
structure en étoile.

34
  Le modèle en constellation : c’est un modèle de données utilisé dans les data
warehouse pour gérer des données complexes provenant de plusieurs sources. Dans le
modèle en constellation, plusieurs tables de faits sont reliées entre elles par des tables
de dimensions communes. Les tables de dimensions sont utilisées pour filtrer, trier et
regrouper les données dans les tables de faits.

Pour notre analyse nous utiliserons le modèle en Constellation avec les dimensions et faits
que notre projet décisionnel va utiliser, nous remarquons que ce modèle permet l’analyse de
données depuis plusieurs vues différentes.

Figure 2. 3: modèle en constellation de la vente

Dans ce modèle en constellation de la vente nous avons deux tables de faits qui sont la table
commande et l’inventaire qui vont nous servir de pont pour atteindre les tables dimensions

1.5.3 Modélisation de l’application

Pour la modélisation de notre système, nous avons utilisé le langage UML ; nous
présentons ici quelques-uns des diagrammes de notre système.

1.5.3.1 Diagrammes de cas d’utilisation

Ces diagrammes permettent de modéliser des processus métiers en les découpant en cas
d'utilisation. Ils décrivent les utilisations requises d'un système, ou ce qu'un système est

35
supposé faire. Les principaux concepts de ces diagrammes sont l’acteur, le cas d’utilisation et
l’interaction entre l’acteur et le cas d’utilisation :
 Un acteur est un utilisateur qui a toujours le même comportement vis-à-vis d’un cas
d’utilisation. C’est une entité qui utilise le système à représenter.
 Un cas d'utilisation c’est une fonctionnalité proposée par le système. Il modélise un
service rendu par le système.

Figure 2. 4: Formalisme d’un diagramme de cas d’utilisation

a. Diagramme de cas d’utilisation global

36
 Figure 2. 5: Diagramme de cas d’utilisation global

Dans ce graphe on présente l’ensemble des cas d’utilisation du système et les acteurs
concernés par ces cas d’utilisation.

b. Diagrammes détaillés des cas d’utilisation

37
  Cas d’utilisation gestion des comptes

Figure 2. 6: Diagramme du cas d’utilisation gestion des comptes

Dans ce graphe on présente les fonctionnalités liée au compte , qu’effectuera l’acteur

administrateur dans le système

 Cas d’utilisation gestion des tâches

38
 Figure 2. 7: Diagramme du cas d’utilisation gestion des tâches

Dans ce graphe on présente les fonctionnalités liées à la tâche qu’effectuera les différents
acteurs employer et gérant dans le système.

1.5.3.2 Diagramme de séquence

Le diagramme de séquence permet de représenter les interactions entre objets en indiquant
la chronologie des échanges. Cette représentation peut se réaliser par cas d’utilisation en
considérant les différents scénarios associés.
a. Diagramme de séquence d’inscription
Tout utilisateur qui souhaite accéder aux fonctionnalités de notre application devra fournir
des données à l’inscription dans le but de pourvoir s’authentifier.

39
 Figure 2. 8: Diagramme de séquence pour l’inscription

Dans le diagramme de séquence pour l’inscription, on présente le fonctionnement du système

suite à la demande d’inscription.

b. Diagramme de séquence pour s’authentifier

Tout utilisateur qui souhaite accéder aux fonctionnalités de l’application doit d’abord
s’authentifier. Il saisira donc son login et mot de passe dans le système, si les informations
sont correctes, l’utilisateur accédera à son interface, sinon un message d’erreur sera affiché et
reconduira l’utilisateur à la page authentification.

40
 Figure 2. 9: Diagramme de séquence d’authentification

Dans le diagramme de séquence d’authentification, on présente les interactions authentifié et

la réponse du système suite au information remplis par l’utilisateur.

1.5.3.3 Diagramme de classe

Il permet de spécifier qui intervient à l’intérieur du système. Un diagramme de classes fait
abstraction des aspects dynamiques et temporels du système, il permet de représenter une vue
statique du système d’information. Il s’agit des relations entre les classes, des services rendus
et utilisés par chacune d’elles et de l’articulation de l’ensemble.

41
 Figure 2. 10: Diagramme de classe

Le diagramme de classe permet la description statique du système. On peut voir les données
qui vont circuler et les classes qui encapsule ces données. Ici nous avons principalement sept
(07) classes : payement, tache, abonnement, utilisateur, rôle, présence et pharmacie.

1.6 Technologies et outils de développement

Pour la réalisation de notre plateforme, nous avons utilisé plusieurs types d’outils logiciel et
technologies web.

1.6.1 Technologies de développement

Les technologies de développement regroupent ici l'ensemble des langages et des
Framework utilisés pour créer notre application et ses services web.

1.6.1.1 Les langages de programmation

Nous avons utilisé plusieurs langages de programmation en fonction de nos besoins :
 HTML (HyperText Markup Language) : c’est le langage de balisage utilisé pour
créer la structure et le contenu des pages.
 CSS (Cascading Style Sheets) : c’est le langage de style utilisé pour définir la
présentation et la mise en page des pages.

42
  JavaScript : c’est un langage de programmation de haut niveau utilisé pour créer des

pages web interactives et dynamiques. Utilisé en complément de HTML et CSS il

permet d’ajouter des fonctionnalités interactives à nos pages.
 PHP : langage de programmation de script côté serveur, il permet la manipulation
des données et le dynamisme des pages.

1.6.1.2 Les Framework

Un Framework, est un ensemble cohérent de composants logiciels structurels qui sert à
créer les fondations ainsi que les grandes lignes de tout ou d’une partie d'un logiciel, c'est-à-
dire une architecture. C’est un cadre de travail qui facilite le développement logiciel.
 Vue.js : aussi appelé Vue, c’est un Framework open-source utilisé pour construire des
interfaces utilisateur et des applications web monopages. Il se concentre sur la
création de composants réutilisables pour faciliter le développement, la maintenance

et la mise à l'échelle des applications web. Chaque composant peut être créé avec son
propre modèle, son propre style et son propre comportement, ce qui permet de
construire des interfaces utilisateur complexes à partir de petits éléments modulaires
[15].

Figure 2. 11: Logo de Vuejs

 DEVUPS est un Framework camerounais de développement web open-source écrit en

PHP, développé par l'entreprise Spacekola. Il a été créé pour simplifier le processus de
développement web en offrant une structure de base pour les applications web comme
mentionner dans le chapitre 1.

Figure 2. 12: Logo de Devups

43
1.6.2 Les outils de développement
Pour réaliser notre projet, nous avons utilisé plusieurs outils tels que des éditeurs, des
navigateurs, les outils de versionning, les outils de test, de documentation et d’intégration des
données. Le choix de chaque outil a été justifié par leur performance et les aptitudes que nous
avions déjà quant à leur utilisation.
 Visual Studio Code : c’est un IDE (Environnement de Développement
Intégré) extensible créé par Microsoft pour Windows, Linux et MacOs. Il prend en
charge une grande variété de langages de programmation et dispose d'une interface
utilisateur intuitive qui permet de naviguer facilement dans les fichiers et les dossiers.
On aurait aussi pu utiliser des éditeurs comme Sublime Text, Notepad++, ou
PHPStorm qui offre des fonctionnalités similaires [16].

Figure 2. 13: Logo de Visual Studio Code

 Les Navigateurs : ceux-ci permettent d’accéder aux pages web. Pour le

développement de notre solution, nous avons utilisé principalement Google Chrome.
Afin de s’assurer du respect de l’ergonomie sur les autres navigateurs nous avons
également utiliser Mozilla Firefox et Microsoft Edge.

44
 Figure 2. 14: Page d’Accueil de Google Chrome

 Le serveur web : dans le cadre du projet nous avons utilisé le serveur Apache car
largement utilisé et facile à déployer.

Figure 2. 15: Logo d’Apache

 L’outil de versionning : notre choix s’est penché sur l’outil Git associé à la
plateforme GitHub. C’est un système de contrôle de version distribué pour suivre les
modifications du code source pendant le développement du logiciel [17]. Il est conçu
pour coordonner le travail entre les programmeurs, et pour suivre les modifications
dans n'importe quel ensemble de fichiers d’un projet.

Figure 2. 16: Logo de Git

 Postman : c’est l’outil utilisé pour tester nos différents services web. Il permet
également la documentation de ces derniers [18].

45
 Figure 2. 17: Logo de Postman [18]

 Talend (Talend Open Studio) : c’est un outil d'intégration de données gratuit et

open-source qui permet aux utilisateurs de connecter, transformer et intégrer
facilement des données provenant de différentes sources. Il fournit une interface
graphique pour la conception et le déploiement de jobs d'intégration de données, ce
qui facilite la création et la gestion visuelles des flux de données [19].

Figure 2. 18: Logo de Talend

Comme nous pouvons le constater, l’activité d’analyse et de la conception a facilité la

compréhension de la structure de la plateforme notamment à travers son architecture et sa
modélisation par les différents diagrammes UML. Il nous a également permis de connaitre les
différents outils utilisés pour sa réalisation. Le chapitre suivant sera dédié à la phase de
discussions des résultats.

46
 CHAPITRE 3 : RESULTATS ET DISCUSSION

Maintenant que nous connaissons comment la plateforme fonctionne et les outils qui nous
ont aidés à la réalisation ; nous allons dans ce chapitre présenter quelques interfaces et faire
l’évaluation financière du projet.

1.7 Résultats du data warehouse

Le data warehouse a été mis en place avec l’outil ETL Talend qui a permis la migration des
tables des pharmacies qui sont branchées à notre système ainsi que l’orchestration et
l’automatisation des taches.

1.7.1 Migration des tables

Toutes les tables ont été migrées avec succès et les données ont été transférées. Les données
extraites des tables opérationnelles ont été nettoyées et transformées en utilisant les
composants Talend appropriés (tmap, tdbinput, tdboutput) et des jobs qui permettent la mise
en place de notre flux de données. Les données nettoyées ont été chargées dans le data
warehouse en utilisant les composants Talend pour établir une connexion à la destination de
la base de donnée medoclab de la plateforme. Voici quelques exemples de migration de tables
opérationnelles que nous avons effectuées.

47
1.7.1.1 Migration de la table pharmacie
Ici, nous récupérons les éléments de la pharmacie dans la base de données source, puis nous
migrons ces informations directement dans la table pharmacie de la base de données
medoclab.

Figure 3. 1: Migration de la table pharmacie

Ici on récupère les données de la table pharmacie appartenant à la source que nous faisons
migrer ces données directement dans notre data Warehouse

1.7.1.2 Inventaire
Dans cette étape, nous extrayons les informations des produits à partir de la base de données
source et les intégrons directement dans la table ‘’inventaire’’ de la base de données
medoclab.

Figure 3. 2: Migration de la table inventaire

1.7.2 Orchestration et Automatisation des tâches

L'orchestration et l'automatisation des tâches sont des éléments clés pour garantir
l'efficacité et la fiabilité de la migration des tables opérationnelles vers le data warehouse.
Nous avons utilisé les fonctionnalités Talend pour orchestrer les tâches de migration et les
automatiser autant que possible. Cela a permis d'optimiser les processus de migration, de
réduire les erreurs manuelles. Afin d'assurer la cohérence des données, les jobs s’exécutent de
façon progressive en fonction de la migration des clés étrangères.

48
 Figure 3. 3: Orchestration et Automatisation des migrations dans Talend

L’orchestrateurs des job est le job principal qui lance les autres job, les uns à la suite des
autres et qui va en cas d’erreur executer le composant Die qui arrete directement le processus

1.7.3 Automatisation de la Mise à jour du data wharehouse

Pour mettre à jour notre data warehouse, nous exécutons directement un fichier batch de
planification a l’aide du planificateur des tâches pour l‘exécuter automatiquement toutes les
15 minutes.

Figure 3. 4: Automatisation de la Mise à jour du data Warehouse

49
1.8 Présentation de quelques interfaces
De façon générale l’application possède une partie back-office pour l’administrateur du
système et une partie cliente pour les autres utilisateurs.

1.8.1 Interfaces de la partie cliente

Ce sont entre autre les interfaces de connexion, d’inscription, de gestion de tâches, de
consultation des produits et des clients.

1.8.1.1 Page d’inscription des pharmacies

Pour l’inscription des pharmacies, le pharmacien remplit ces informations, puis après avoir
soumis le formulaire, l’administrateur de la plateforme vérifiera dans le registre des
pharmaciens si ce dernier existe et à la permission d’avoir une pharmacie. Si oui il sera
enregistré dans le système avec sa pharmacie.

Figure 3. 5: Page d’inscription

1.8.1.2 Page d’authentification

L’interface d’authentification permet à chaque utilisateur à l’aide de son email et de son mot
de passe de s’authentifier afin d’accéder à son espace personnel.

50
 Figure 3. 6: Page d’authentification

1.8.1.3 Page de gestion des tâches

Ce module permet à un utilisateur, une fois connecté de visualiser les différentes tâches en
cours et celles qui lui sont attribuées dans un tableau KANBAN.

Figure 3. 7: Page de visualisation des tâches

51
Il permet également de visualiser les détails sur une tâche ainsi que les différentes statistiques
sur les tâches.

Figure 3. 8: Menu de détails d’une tâche

1.8.1.4 Interface de consultation des produits

Elle permet au pharmacien d’avoir une vue globale sur l’ensemble de ces produits : ces
produits les plus vendus, ceux commandes, et l’évolution de ses ventes sur une année.

52
 Figure 3. 9: Page de consultation des produits

1.8.1.5 Interface de consultation des clients

Ici le pharmacien a accès aux statistiques clés concernant sa clientèle: les pourcentages
suivant le sexe de ses clients, les clients les plus réguliers ou qui effectuent le plus d’achats et
une évolution de sa clientèle au cours des années.

Figure 3. 10: Page de consultation des clients.

1.8.2 Les interfaces en back-office

Ces interfaces comprennent entre autre l’interface d’accueil, et de gestion des utilisateurs

53
1.8.2.1 L’ Interface d’accueil
Il s’agit de l’interface de gestion globale de la plateforme. Elle permet à l’administrateur du
système d’accéder à l’ensemble des modules de l’application, de gérer les comptes, de gérer
les tâches ainsi que l’attribution des différents rôles.

Figure 3. 11: Tableau de bord de l’administrateur

1.8.2.2 Page de gestion des utilisateurs

Ici l’administrateur peut consulter, créer, modifier, supprimer les différents utilisateurs

Figure 3. 12: Page de gestion des utilisateurs

Il peut également créer et modifier un utilisateur

54
 Figure 3. 13: Modale de création d’un utilisateur

1.9 Evaluation financière du projet

Il s’agit ici de ressortir les coûts nécessaires au développement de notre solution. La
détermination du cout du projet prendra en compte les éléments suivants : le cout des
équipements et le coût de prestation des ingénieurs.

1.9.1 Estimation du coût des équipements

Parmi les équipements nous avons entre autre : les équipements matériels et les
équipements logiciels.

Tableau 3. 1: Coût du matériel utilisé

Désignation Quantité Prix unitaire Prix Total
Matériel de développement
Ordinateurs Core i5, 02 350 000 700 000
4Go RAM, 500 Go
DD
Hébergement
Nom de domaine 01 10 000 /an 10 000
Hébergement en 01 40 000/an 40 000
ligne
Autres
Connexion internet 4(mois) 25 000 100 000
Box Wifi 4G 01 35 000 35 000

55
 Total 885 000

1.9.2 Le coût de prestation des ingénieurs

Il existe plusieurs méthodes permettant de réaliser cette opération, parmi lesquelles nous
avons la méthode COCOMO (Constructive Cost Model), la méthode Delphi et la méthode
ascendante. Nous utiliserons la méthode COCOMO pour estimer les coûts de notre projet.

COCOMO est un modèle de régression basé sur le nombre de KLS (Kilo Ligne Source). Il
s’agit d’un modèle procédural d’estimation des coûts pour les projets logiciels et souvent
utilisé comme processus de prédiction fiable des divers paramètres associés à la réalisation
d’un projet, tels que la taille, l’effort, le coût, le temps et la qualité. Il a été proposé par Barry
Boehm en 1981 et est divisé en trois modèles, qui affinent l'estimation en prenant en compte
plusieurs paramètres :

 Le modèle de base : il permet d’effectuer un simple calcul de l'effort et de la durée en

fonction du nombre d'instructions que l'application doit contenir et la complexité de
cette dernière. Une ventilation est également possible, permettant de déterminer le
temps de développement et l'effort nécessaire pour chaque partie du cycle de
développement.
 Le modèle intermédiaire : il reprend l'effort et la durée du modèle de base, en
appliquant cette fois-ci des coefficients prenant en compte des facteurs de coût
(compétence de l'équipe, complexité de l'environnement technique, etc.).
 Le modèle détaillé : il reprend les données du modèle intermédiaire en affinant
notamment les facteurs de coût en fonction de chaque phase du cycle de
développement. Ce modèle n'est véritablement nécessaire que pour de très gros
projets.

Cette méthode définit trois types de complexité :

 S (complexité organique) : Ce sont des applications simples, n'ayant que peu de cas
particuliers et de contraintes. Un projet logiciel est dit de type organique si la taille de
l’équipe requise est suffisamment petite, si le problème est bien compris et a été
résolu dans le passé et si les membres de l’équipe ont une expérience nominale du
problème.
 P (complexité semi détachée) : Ce sont des applications intermédiaires, plus
complexes que les applications de type S, elles restent tout de même déterministes,
56
 bien que le nombre de cas particuliers et de tests doivent être plus important que pour
les applications de type S. Ici les caractéristiques vitales telles que la taille de
l’équipe, l’expérience, la connaissance des différents environnements de
programmation se situent entre celles de l’organique et de l’embarqué. Ces projets
demandent plus d’expérience et une meilleure orientation et créativité. Exemple : Les
compilateurs ou différents Systèmes Embarqués peuvent être considérés de type
Semi-Détachés.
 E (complexité embarquée) : Ce sont des applications très complexes, que ce soit au
niveau de leurs contraintes (comme un système temps réel) ou au niveau des données
saisies.

En fonction de l'application, on utilisera différents coefficients prenant en compte les

différentes complexités et forcément les différents efforts à fournir.

Tableau 3. 2: Tableau des formules de calculs de l'effort pour chaque type de projets
Complexité Effort (en Mois Homme) Temps de développement
(en mois)
1 , 05 0 ,38
S Effort =2 , 4 x KLS TDev=2 ,5 x Effort
1 ,12 0 ,35
P Effort =3 x KLS TDev=2 ,5 x Effort
1 ,2 0 ,32
E Effort =3 , 6 x KLS TDev=2 ,5 x Effort

KLS : représente le nombre de milliers d'instructions que contiendra l'application.

Au vu des caractéristiques de notre projet, nous avons opté pour le modèle intermédiaire et de
complexité organique pour l’estimation des coûts.
 Calcul de l’effort : Après décompte le Frontend compte 27 fichiers (pages,
composants, routes et store) avec une moyenne de 300 lignes de code par fichier. Le
Backend est constitué de 35 fichiers (components, data table, modèles, contrôleur)
avec une moyenne de 300 lignes de codes par fichier.
Il découle de ces calculs que le Frontend comptabilise 8100 lignes de code et le
Backend 10500 lignes de code. Il résulte donc un total de lignes d’environ 18600
lignes.
Ainsi l’effort est de :
1 , 05 1.05
Effort =2 , 4 x KLS =2 , 4 x 18 , 6 ≈ 52 M . H

57
  Calculons le temps de développement :
0 ,38 0.38
TDev=2 ,5 x Effort =2, 5 x 52 ≈ 12 Mois

 Cout total du développement

Pour une estimation de la charge M/H (Mois/Homme) d’une personne a 250 000 frcfa
Cout Total de développements=2 x 250 000 x 12=6 000 000 frcfa

1.9.3 Estimation du coût total du projet

Pour récapituler les coûts, nous avons : les coûts du matériel de développements et les
coûts du personnel autre que celui des ingénieurs qui représentent en moyenne 30% de la
somme des coûts susmentionnés.

Tableau 3. 3: Tableau du coût total du projet

Intitulé Montant (FCFA)
Coût du matériel 885 000
Coût de développement 6 000 000
Coût du personnel autre 1 800 000
Total 8 685 000

Dans ce chapitre, il était question pour nous de présenter les différents résultats obtenus
après la réalisation de notre projet au niveau du data warehouse, au niveau de l’API et au
niveau du Frontend. Nous avons également effectué une estimation du coût du projet grâce à
la méthode COCOMO.

58
 CONCLUSION GENERALE

Arriver au terme de notre travail, où il était question du développement d’une plateforme

SaaS pour l’optimisation de la prise de décision dans les pharmacies. Il en ressort que les
pharmacies sont des structures qui génèrent d’énorme quantités de données quotidiennement.
Ces données pourraient servir dans l’optimisation des opérations et la prise de décision au
sein de la pharmacie. C’est dans ce cadre que s’inscrit notre plateforme MEDOCLAB à
travers une gestion et une planification efficace des tâches entre les membres d’une
pharmacie. Notre solution ne modifie pas l’environnement existant et vient se brancher a
celui-ci en complément pour permettre un traitement et une exploitation optimale des
données de pharmacies. Pour mener à bien le projet nous avons utilisé la méthode agile
Scrum et le langage UML pour la modélisation de notre système. Pour sa réalisation nous
avons utilisé des outils tel que Talend pour le data warehouse et des technologies telles que
DEVUPS et VueJs respectivement pour le développement de l’API et la partie Frontend. Ce
projet nous a permis d’être en contact avec les réalités du monde professionnel et d’avoir des
connaissances sur le fonctionnement des pharmacies.il nous a également permis de renforcer
nos connaissances en Business Intelligence(BI).

Toute fois des perspectives d’amélioration restent à prendre en compte notamment la mise à
disposition des stocks de médicaments auprès des patients et des hôpitaux afin de faciliter la
recherche de ceux-ci au travers d’une version mobile de notre solution.la mise en place d’un
système permettant d’optimiser la mise à jour du data warehouse, et d’un autre permettant
d’avoir une statistique générale des stocks pharmacies. L’implémentation d’un système de
haute sécurité pour la plateforme, vu la sensibilité des données manipulées au sein de celle-ci.

L’intégration d‘un modèle d’IA entrainé sur les données des pharmacies qui permettra de
faire des prédictions sur un médicament en fonction d’une période.

L’analyse des données pourra permettre au gouvernement de faire des projections sur les
maladies qui sévissent le plus dans une région donnée pendant telle ou telle période. Ce qui
les aidera pour lancer des campagnes préventives.

59
 REFERENCES BIBLIOGRAPHIQUES

[1] «Définitions : pharmacie - Dictionnaire de français Larousse,» [En ligne]. Available:

https://www.larousse.fr/dictionnaires/francais/pharmacie/60127. [Accès le 13 mai 2023].

[2] «Nombre de pharmacies en Europe 2022 | Statista,» [En ligne]. Available:

https://fr.statista.com/statistiques/513482/nombre-pharmacies-par-pays-europe/. [Accès le 06
juin 2023].

[3] F. Tonic, Livre Blanc - Cloud Computing, 2009 .

[4] B. M. C. Helier, Le Cloud Computing est-il une solution d’avenir pour l’entreprise,Mémoire de
Recherche, ESGI,, 2012.

[5] F. N. Fenohanitra, «IMPLEMENTATION D’UN CLOUD PRIVE IAAS ET ANALYSE BIG DATA DANS UN
SYSTEME DISTRIBUE AU SEIN D’ACM,» ANTANANARIVO, 2019.

[6] D. Boudaa, Cours de Genie Logiciel Boudaa Boudjemaa, Université Ibn Khaldoun de
Tiaret,Algerie, 2020.

[7] «Quelles sont les phases du cycle de développement logiciel ? SDLC,» [En ligne]. Available:
https://www.eurotechconseil.com/blog/cycle-de-vie-developpement-logiciel/. [Accès le 08 juin
2023].

[8] H. Ahmed, «Mise en place d'un site web pour l'institut supérieur des affaires de Tunis,» Tunis,
2017.

[9] C. CABERLON, la methode KANBAN, 2008.

[10] S. KHOURI, THESE pour l’obtention du Grade de DOCTEUR DE L’ESI & DE L’ISAE-ENSMA : Cycle
de Vie Sémantique de Conception de Systèmes de Stockage et Manipulation de Données,
France, 2013.

[11] S. Crozat, Introduction à l'ETL et application avec Oracle, Compiègne,France, 2016.

[12] SPACEKOLA, «Buyamsellam24,» [En ligne]. Available: https://buyamsellam24.com/fr/. [Accès le

09 mai 2023].

[13] «12ème édition du Panorama Top 250 des éditeurs de logiciels français | Numeum,» [En ligne].
Available: https://numeum.fr/actu-informatique/12eme-edition-du-panorama-top-250-des-
editeurs-de-logiciels-francais. [Accès le 13 mai 2023].

[14] G. ABDELAZIZ, Mémoire En vue d’obtention du diplôme de Magister en informatique : Une

Approche Basée Agent Pour le Data Warehousing.

[15] B. Chaponneau, Vue.js : Applications web complexes et réactives, Paris: EYROLLES, 2019.

60
[16] Microsoft, «Visual Studio Code - Code Editing. Redefined,» [En ligne]. Available:
https://code.visualstudio.com/. [Accès le 3 juillet 2023].

[17] D. Demaree, GIT PAR LA PRATIQUE, EYROLLES, 2018.

[18] J. Oliver, Mastering Postman: A Comprehensive Guide to Building End-to-End APIs with Testing,
Integration and Automation, GitforGits.

[19] «Talend Open Studio : ETL open source et intégration de données gratuite | Talend,» [En ligne].
Available: https://www.talend.com/fr/products/talend-open-studio/. [Accès le 2 07 2023].

[20] AWS, «AWS,» [En ligne]. Available: https://aws.amazon.com/fr/types-of-cloud-computing/.

[Accès le 6 juin 2023].

[21] «Quelle place pour la France dans le marché des SaaS pré et post Covid-19 ?,» [En ligne].
Available: https://www.sempai.io/blog/quelle-place-pour-la-france-dans-le-marche-des-saas.
[Accès le 13 mai 2023].

[22] developper, «Conception d'un entrepôt de données (Data Warehouse),» [En ligne]. Available:
https://grim.developpez.com/cours/businessintelligence/concepts/conception-
datawarehouse/#LII. [Accès le 02 06 2023].

[23] «http://www-igm.univ-mlv.fr/~dr/XPOSE2005/entrepot/datawarehouse.html,» [En ligne].

Available: http://www-igm.univ-mlv.fr/~dr/XPOSE2005/entrepot/datawarehouse.html. [Accès
le 20 06 2023].

61