Page 0 sur 59

République Démocratique du Congo

Enseignement Supérieur et Universitaire
Institut Supérieur Pédagogique de Bukavu

B.P. : 854/ Bukavu

Section des Sciences Commerciales, Administratives et Informatique
Département d’Informatique de Gestion

TFC N° : …………

« Gestion de stock d’un Dépôt Pharmaceutique, cas du PRINCE

PHARMA/Bukavu »

Présenté Par MUKAMBA SHUKURU François

Directeur : Guylain MUGARUKA BUDUGE
Chef de Travaux

Année Académique 2022 – 2023

 Page I sur 59

EPIGRAPHE
La technologie au service de la santé ; C’est la santé qui est notre richesse la plus précieuse.

RALPH WALDO Emerson

 Page II sur 59

DEDICACES
A nos très chers parents ; MAMBO MUSILAMU et maman MABI Espérance pour leur contribution
tant morale, matérielle que financière surtout pour leur accompagnement au cours de notre parcours
jusqu’à la réalisation de ce travail.
A nos frères et sœurs MAPENZI NEEMA Françoise, USHINDI KATANGA Espoir, A nos
collègues, amis et connaissances, qui, durant notre parcours de scolarisation ne se sont jamais
fatigués de nous encourager quand bien même nous voulions abandonner suite à de diverses
difficultés.
 Page III sur 59

REMERCIEMENTS
Ce travail est le fruit de la participation de plusieurs personnes qui nous ont soutenues de prêt ou de
loin pour sa réalisation.
A Dieu le Tout Puissant maître de temps et des circonstances pour nous avoir prêté vie au quotidien.
Nous exprimons nos sentiments de gratitudes spécialement au CT Guylain MUGARUKA
BUDUGE qui, malgré ses multiples tâches a accepté de diriger ce travail en mettant à notre portée
ses compétences et connaissances pour la direction de ce travail.
A tous les enseignants de l’ISP-Bukavu ainsi que les administratifs que nous avons connus tout au
long de notre cursus académique pour nous avoir donné le meilleur d’eux-mêmes et une formation
parfaite, afin que nous soyons des professionnels accomplis.
Aux membres de la grande famille MUMUNYA et famille KIMPUTU avec ses Alliés,
particulièrement : Papa KAMALEBO KIMPUTU Tchopard, tante Marguerite, Papa Claude et
toutes ses générations pour leur contribution de tout genre tout au long de notre parcours
académique.
Aux amis et frères à qui nous avons bénéficié de leur attachement dont, FURAHA Chanceline
MUSIWA KININGA Luc, MUGANZA MULONDA Courtois, Bienvenu BAHOGWERE, IMANI
KISUBI Joseph, TOMBO ZAMUKULU, Germaine KUBOTA, LUKOGO Nicole, EZECHIEL
sans oublier les membres de la chambre 210 avec qui on a passé ce bon moment de notre vie
académique ; Christian KABOYI, ACHIZA Charles, USHINDI, Claude, Philipe.
Que tous ceux qui ne sont pas cités par mégarde à la suite de certains impératifs et de qui, quel que
soit la grandeur du monde, nous garderons le souvenir.
Qu’ils se sentent liés toujours à nous.

MUKAMBA SHUKURU François

 Page IV sur 59

SIGLES et ABREVIATIONS
BDD : Base de Données
CU : Cas d’Utilisation
ESU : Enseignement Supérieur et Universitaire
HTML : HyperText Markup Language
http : Hyper Text Transmission Protocol
HTTPS : Hyperactive Text Transfer Protocol security
I.G : Informatique de Gestion
IG : Informatique de Gestion
IP : Internet Protocol
IP : Internet Protocol
ISP : Institut Supérieur Pédagogique de Bukavu
MS : Microsoft
N° : Numéro
P : Page
PHP : Personal Home Page
RDC : République Démocratique du Congo
SCAI : Sciences Commerciales, Administrative et Informatique
SGBD : Système de Gestion de Base des Données
SGBR : Système de Gestion de Base des Données Relationnelles
SQL : Structured Query Language
TCP : Transfer Control Protocol
UML : Unified Modelling Language
UP : Unified Process
URL : Uniform Resource Locator)
VP-UML : Visual Paradigm for Unified Modelling Language
WAMP : Windows Apache MySQL PHP
WWW : Word Wide Web
 Page V sur 59

LISTE DES TABLEAUX

Tableau 1 Identification des acteurs ............................................................................................... 17
Tableau 2 CU Ajouter Client........................................................................................................... 25
Tableau 3 CU Commander Produit ................................................................................................ 26
Tableau 4 CU Gérer les utilisateurs ............................................................................................... 27
Tableau 5 Visualiser les commandes .............................................................................................. 28
 Page VI sur 59

LISTE DES FIGURES

Figure 1 Organigramme du dépôt pharmaceutiqueb) STRUCTURE FONCTIONNELLE ............. 9
Figure 2 Diagramme des flux d’information de la livraison du produit pharmaceutique.............. 11
Figure 3 Diagramme des flux d’information pour la gestion du personnel ................................... 12
Figure 4 La facture.......................................................................................................................... 13
Figure 5 Processus itératif et incrémental ...................................................................................... 19
Figure 6 Cycle de vie du processus unifié ....................................................................................... 21
Figure 7 Diagramme de cas d'utilisation ........................................................................................ 24
Figure 8 Diagramme de séquence Enregistrer les Clients ............................................................. 28
Figure 9 Diagramme de séquence Enregistrer Commande ............................................................ 29
Figure 10 Diagramme de séquence Gérer les utilisateurs.............................................................. 30
Figure 11 Diagramme de séquence Visualiser les commandes ...................................................... 31
Figure 12 Diagramme d'activité Enregistrer client ........................................................................ 32
Figure 13 Diagramme d'activité Enregistrer commandes .............................................................. 32
Figure 14 Diagramme d'activité Visualiser les commandes ........................................................... 33
Figure 15 Diagramme de classe récapitulatif ................................................................................. 35
Figure 16 Diagramme de déploiement ............................................................................................ 35
Figure 17 Image Xampp .................................................................................................................. 36
Figure 18 PhpMyAdmin .................................................................................................................. 37
Figure 19 image Php ....................................................................................................................... 37
Figure 20 image Sql ........................................................................................................................ 37
Figure 21 Image HTML .................................................................................................................. 38
Figure 22 Interface Xampp ............................................................................................................. 39
Figure 23 Table Utilisateurs ........................................................................................................... 39
Figure 24 Table Clients ................................................................................................................... 39
 Page 1 sur 59

0. INTRODUCTION
0.1. PROBLEMATIQUE

De nos jours, l'influence de l'informatique sur le monde est devenue évidente, surtout le monde des
entreprises, pour partager et répartir l'information et la traiter au sein de leurs systèmes
d'information. L’Informatique procure toujours des solutions dans chaque domaine de la vie
dépendamment du besoin des utilisateurs.

Dans notre travail de fin du cycle on a jugé bon de nous orienter sur le problème de gestion
de stock des produits pharmaceutiques sachant que la mise à disposition des médicaments à la
population est un droit fondamental de l’Homme car les médicaments essentiels sauvent des vies et
améliorent la santé. Ils jouent un rôle capital dans de nombreux aspects des soins de santé en offrant
une réponse simple et efficace. Pour cela, ils devraient être disponibles à tout moment dans le cadre
de système de santé fonctionnel, en quantité suffisante, sous une forme appropriée, avec une qualité
assurée, accompagnés d’une information adéquate et à un prix accessible pour les individus et les
communautés.
Le mot « stock » peut être défini comme marchandises ou matériels qu'une entreprise a dans
l'intention de vendre à ses clients dans un but de rentabilité1. C’est également un ensemble des
produits que l’on garde en vue d’une utilisation ultérieure, il est l’élément important dans
l’entreprise car il représente l’investissement financier et peut avoir un impact sur la rentabilité.
Notre système consistera à l’outil ou le logiciel servant à gérer et suivre les stocks de notre entreprise
d’où la gestion de la facturation, l’enregistrement des clients, contrôles des produits en stock,
enregistrement des commandes et l’impression des factures et doit également effectuer le calcul du
montant que doit payer le client après avoir passé sa commande.

Les pharmacies hospitalières, les dépôts pharmaceutiques et celles des dispensaires publics font
partie intégrante des établissements que l'informatique pourra beaucoup aider pour son évolution.
En effet, la mise en place d'une application de gestion rationnelle performante qui répond aux
besoins des utilisateurs or et jusqu'à ce jour, la manière de gérer manuellement est encore dominante
dans quelques entreprises dans la ville de Bukavu. Après les différentes recherches et observations
réalisées on a remarqué que dans la ville de Bukavu des nombreuses pharmacies parcourent les
difficultés dans la gestion de stock des médicaments particulièrement dans le dépôt pharmaceutique
PRINCE PHARMA qui est notre établissement de recherche ; actuellement cette entreprise utilise
une application informatique qui perd beaucoup de temps dans la réalisation d’une opération car
l’application manque quelques fonctionnalités importantes pour une meilleure gestion de ces
produits notamment : la non spécification des articles en stock, des incertitude dans la réalisation
d’une vente, non spécification de l’état de stock pour découvrir le stock d’alerte lenteur pendant
l’utilité de l’application.

1
https://www.ibm.com/fr-fr/topics/inventory-management
 Page 2 sur 59

Pour résoudre ces problèmes et améliorer l'efficacité du dépôt pharmaceutique, nous avons décidé
de concevoir une nouvelle application informatique qui peut répondre aux besoins spécifiques du
dépôt pharmaceutique et qui sera facile à utiliser par ses utilisateurs.
En effet, tenant compte des toutes les difficultés ci-haut énumérées et avec l’objectif de réorganiser
le système de gestion existant au sein du dépôt pharmaceutique PRINCE PHARMA à Bukavu, nous
nous posons les questions suivantes :
1. Quel serait le type de système à mettre en place pour gérer de manière efficace et efficiente les
opérations de gestion au sein du dépôt pharmaceutique PRINCE PHARMA en remplaçant cette
application non performante?
2. Quels sont les avantages et les limites d’une application de gestion de stock dans le dépôt
pharmaceutique PRINCE PHARMA ?

0.2. HYPOTHESE
L’hypothèse se définit comme une proposition admise provisoirement avant qu’elle soit
confirmée, infirmée ou nuancée par la confrontation des faits.
L’hypothèse est « en quelque sorte une base avancée de ce que l'on cherche à prouver. C'est la
formulation pro forma de conclusions que l'on compte tirer et que l'on va s'efforcer de justifier
et de démontrer méthodiquement et systématiquement 2»
 Le choix d’une nouvelle application plus performante permettra une meilleure gestion
de stock au sein du dépôt pharmaceutique PRINCE PHARMA cela aidera à la traçabilité
des produits, optimiser les commandes en fonction des besoins, fournir les informations
précises sur le stock actuel et préciser les produits à retrancher suivant la date de
fabrication et d’expiration.
 L’Utilisation d’une application de gestion des stocks dans un dépôt permettra une
traçabilité des stocks et une réduction des coûts de gestion, ses limites dépendront de sa
compatibilité par rapport à d’autres systèmes suivant le coût d’installation ou de
maintenance.

0.3. ETAT DE LA QUESTION

Nous ne sommes pas le premier à traiter le sujet comme le nôtre dans la mesure où nos
Prédécesseurs en ont traité, à l'occurrence:
-Joséphine VUNABANDI NIYIBIZI dans son travail intitulé « Gestion automatisée de stock des
produits cosmétiques d'une maison commerciale, cas de RAFIF Goma3 », elle a conçu une base des
données capable de déterminer les statistiques des entrées et de sorties, et présenter la situation du
stock et remarquer les capacités de ventes de la maison RAFIF.

2
(O. Aktouf, cours de technique de recherche, Université Frères Mentouri 2020-2021)
3
(Joséphine VUNABANDI NIYIBIZI, TFC, ISC GOMA, 2016-2017)
 Page 3 sur 59

-Evariste KAMBALE KANYAMBARA, dans son travail intitulé « Automatisation du processus

d'approvisionnement et de distribution des médicaments dans une zone de santé, cas de la zone de
santé urbaine de Nyantende4 », sa finalité était de faire sortir les états, tels que la fiche de structures
sanitaires, le registres de distribution, fiche de produits Fiche de pharmacies Fiche de stock, le
bordereau d'expédition ; et une fiche de don du BCZS.
-KAHASHA KASHALA François dans son travail de fin de cycle « Automatisation de la gestion
de stocks des imprimés de valeurs de la DGI5 » démontre que toutes les entreprises de nos jours
disposent d'équipements informatiques pouvant leurs permettre de stocker une quantité
d'information et de les traiter avec rapidité mais toutes ces entreprises ne possèdent pas de logiciel
de gestion de stocks bien adapté à leurs besoins réels.
-NZIRIRANE BUGALE Patrick dans son travail intitulé « Gestion automatisé de stocks des
produits finis au sein du dépôt CEPRAMAL (Centre de Production pour I ‘Amélioration de
l'Alimentation6) » est parvenu à sortir les imprimés des documents suivant la fiche de stocks, le
billet de livraison et la facture en temps record.

0.4. OBJECTIF DU TRAVAIL

a) Objectif Général
Après des nombreuses observations dans la gestion et distributions de produits pharmaceutiques
dans la ville de Bukavu surtout au dépôt pharmaceutique PRINCE PHARMA on a eu l’ambition de
contribuer dans le domaine sanitaire en facilitant l’une de ces entreprises chargées de la distribution
des produits pharmaceutiques dans la meilleure gestion qui leur permettra de gagner beaucoup plus
du temps et travailler avec assurance et certitude.

Objectifs Spécifiques
 Fournir une application capable d’améliorer la condition des distributions des produits
pharmaceutiques
 Permettre aux utilisateurs de contrôler les produits se trouvant dans le stock
 Aider les utilisateurs de garder les coordonnées des opérations passées dans l’entreprise
 Effectuer le calcul et imprimer une facture juste
 Satisfaire les besoins des clients en offrant le service digne
0.5. CHOIX ET INTERET DU SUJET
0.5.1. Choix du sujet
Nous avons choisi de développer le sujet « Gestion de stock d’un dépôt pharmaceutique, cas du Prince
pharma/Bukavu ». Ce choix peut être justifié par notre sens d’observation, ayant vu l'importance que
nous accordons à la santé et l’amélioration de conditions de distributions des produits pharmaceutiques
dans notre vie.

4
(Evariste KAMBALE KANYAMBARA, Mémoire de fin d’études, ISP Bukavu, 2018-2019)
5
KAHASHA KASHALA François
6
NZIRIRANE BUGALE Patrick
 Page 4 sur 59

0.5.2. Intérêt du sujet

Dans le monde de recherche on est toujours inspiré par une idée pour mener les investigations qui
pourront réalisées un objectif quelconque. Le sujet sur lequel nous travaillons est d'une grande
importance. Il s'attaque à un problème existant dans la gestion de produits pharmaceutiques. Il est
également d'actualité, car il permet de doter les produits aux clients dans les meilleures conditions,
d'étendre les opportunités dans tous les coins de la Province du Sud-Kivu.

0.5.2.1. Du point de vue de l'entreprise

La réalisation d'une application de gestion de stock permettra à l'entreprise de :
 Gérer en temps réel le stock en ayant les informations précises sur le niveau de stock
 Réduire les coûts de gestion en automatisant ses tâches
 Gagner la confiance aux clients grâce à la traçabilité des produits
 L’Optimisation des commandes
0.5.2.2. Du point de vue du développement communautaire
La réalisation d'une application de gestion de stock permettra de :
 Disponibiliser les articles ayant le bon état
 Préserver les vies humaines en élargissant les opportunités, ce qui s'avère aussi important dans
la situation que nous traversons par manque de traitement.

0.5.2.3. Du point de vue scientifique

Le présent travail de fin cycle servira de référence pour d'autres chercheurs qui iront dans le même angle
d'idée que nous ou dans le même domaine que nous. Il suscitera également le courage des chercheurs
passionnés des nouvelles technologies et d'accomplir des merveilles dans le monde du numérique.
0.5.2.4. Du point de vue pratique
Le présent travail de fin cycle nous amène à mettre en pratique ce que nous avons appris de nous-même
et ce que nous avons pu acquérir auprès de nos enseignants de la section des sciences commerciale
administrative et informatique de gestion.
0.5.2.5. Du point de vue personnel
Le présent travail nous amène à faire face à des réalités du monde professionnel, ce qui nous amène à
comprendre qu'au-delà des situations traitées à l'auditoire il y a des situations réelles dans la communauté
ou dans les entreprises qui nécessitent des solutions émanant de la technologie.
 Page 5 sur 59

0.6. METHODES ET TECHNIQUES

0.6.1. METHODES
Une méthode est une voie à parcourir par un chercheur dans le but d’arriver à un résultat ; c’est
l’ensemble des règles et des principes qui mènent vers la connaissance objective7..
Notre investigation est fondée sur la conduite des projets informatiques qui procède par la
modélisation basée sur le processus unifié (UP), qui étant un processus du langage de modélisation
unifié UML (Unified Modeling Language).
Pour cela, dans le but de parvenir au résultat escompté de notre travail, nous avons fait usage des
méthodes suivantes :
a) La méthode structuro-fonctionnelle
Cette méthode nous a été utile pour faire la description de l’organisation et du fonctionnement de
notre champs d’investigation PRINCE PHARMA à Bukavu.
b) La méthode UP
La méthode UP (Unified Process en Anglais), est un processus de développement de logiciel
utilisant le langage UML, qui étant un langage de modélisation développé par Ivar Jacobson, Grady
Booch et James Rumbaugh en 1990. Cette méthode nous a permis de modéliser de manière
graphique et textuelle le système d’information en différentes vues architecturales, de définir les
besoins des utilisateurs finaux et spécifier les solutions envisagées.
0.6.2. TECHNIQUES
Une technique est un ensemble des procédés que le chercheur doit employer de manière méthodique
pour atteindre les résultats de sa recherche. Utilise des méthodes fondées sur la connaissance
scientifique, employés à la production d’un travail quelconque8
Dans le présent travail, nous avons fait usage des différentes techniques, parmi lesquelles nous
pouvons citer :
a) La technique d’observation : Cette technique nous a permis d’observer pour découvrir la
manière dont se déroule le processus de gestion des ventes et du personnel au sein du dépôt
Pharmaceutique PRINCE PHARMA.
b) La technique d’interview : Cette dernière nous a permis de collecter d’autres informations
concernant la gestion des ventes par la conversation avec les agents cadres de l’entreprise
ainsi que d’autres travailleurs.
La technique de navigation sur internet : Vu la pertinence de la modélisation, il nous a été
indispensable de nous passer de l'internet pour nous mettre à jour et de consulter certaines bibliothèques
numériques et avoir des informations utiles sur notre travail. Elle nous a été utile dans la recherche
d’autres données en ligne.

7
(Prof. MUKAMBA Vicky, cours d’initiation à la recherche scientifique, G2 IG, ISP/Bukavu, 2017-2018, P.15.)
8
https://www.cordial.fr/dictionnaire/definition/technique.php
 Page 6 sur 59

0.7. DELIMITATION DU SUJET

La science étant tellement vaste, personne ne peut penser étudier un domaine dans son ensemble. Il
est important de délimiter une thématique de recherche dans l’espace et dans le temps. Le présent
travail s’attèle sur l’informatisation de gestion d’une Entreprise de distribution des produits
pharmaceutiques cas du Prince pharma. Ce travail est délimité du point de vue spatial et temporel.

a) Délimitation spatiale
Comme tout travail scientifique doit se délimiter dans l’espace, le nôtre se restreint au sein de la du
dépôt pharmaceutique Prince pharma, qui se situe en République Démocratique du Congo, dans la
province du Sud-Kivu, ville de BUKAVU commune d’IBANDA dans le quartier NDENDERE,
Avenue, P.E Lumumba, N° 40
b) Délimitation chronologique
Il est important que le travail scientifique se réalise toujours dans un intervalle de temps bien
déterminé, le nôtre s’étend sur une période allant de 2022 à 2023, voire une durée d’une année.

0.8. DIFFICULTES RENCONTREES

La présente recherche s’est heurtée à plusieurs problèmes dont :
Les moyens financiers pour faire la recherche,
L’accès aux données,
Certains enquêtés privilégiaient leurs multiples préoccupations par rapport à notre sujet de
recherche ; Mais avec nos efforts et le concours des personnes de bonne volonté nous
sommes parvenus à la fin de ce travail.
Difficulté de voir le directeur du travail suite aux nombreuses préoccupations de la vie

0.9. SUBDIVISION DU TRAVAIL

Faisant l’abstraction à l’introduction et la conclusion, le présent travail est scindé en trois chapitres.
 Le premier chapitre parle de la généralité sur le milieu d’étude et cadre de référence ; dans lequel
nous essayerons de présenter le champ d’investigation du point de vue géographique,
organisationnel et fonctionnel mais aussi nous passerons en revue de l’analyse de l’existant.

 Le deuxième chapitre concerne la modélisation du système ; dans ce chapitre, nous allons

présenter les différents outils de modélisation auxquels notre choix est porté, d’exprimer les
besoins du maitre d’ouvrage et du logiciel, de présenter l’architecture de notre application pour
atterrir avec les différentes facettes architecturales de notre système.

 Le troisième et dernier chapitre sera axé à la conception de l’application comme résultat de notre
travail ; à ce niveau, il sera question de montrer les outils matériels et logiciels qui nous ont été
utiles dans le développement et l’implémentation de ladite application, le langage de
programmation auxquels nous avons fait recours et pour terminer avec la présentation des
différentes interfaces de notre application permettant son exploitation à l’utilisateur.
 Page 7 sur 59

CHAPITRE PREMIER : GENERALITES SUR LE MILIEU D’ETUDE

I.1. PRESENTATION DE PRI NCE PHARMA BUKAVU

I.1.1. SITUATION GEOGRAPHIQUE
Le dépôt pharmaceutique PRINCE PHARMA est situé en République Démocratique du Congo,
Province du Sud-Kivu, Commune d’Ibanda, Quartier Ndendere, Avenue P.E Lumumba, N° 40

I.1.2. BREVE HISTORIQUE

Prince pharma est basé en République Démocratique du Congo depuis plus d'une décennie et demie,
Prince Pharma est l'un des principaux acteurs pharmaceutiques du pays qui propose une large
gamme de médicaments génériques et de marque dans 12 domaines thérapeutiques, à la fois dans
les catégories sur ordonnance et en vente libre.
Dans un effort de supplémentaire pour rendre disponible les médicaments de qualité à la disposition
de la population de l’Est de la RDC, un nouveau dépôt était installé à Bukavu Province du Sud-
Kivu, Commune d’Ibanda, Quartier Ndendere, Avenue P.E Lumumba en 1993. Prince Pharma n’est
pas seulement installé à Kinshasa et Bukavu mais aussi à Kisangani, Mbandaka Bumba, Goma,
Lubumbashi, Kolwezi, Matadi, Tshikapa.

I.1.3. OBJECTIFS POURSUIVIS

L'objectif principal du dépôt pharmaceutique PRINCE PHARMA est de rendre la vie saine en
fournissant des médicaments de haute qualité fabriqués dans des usines approuvées par l’OMS
d'approvisionner la population de Bukavu des produits pharmaceutiques de bonne qualité pour leur
garantir une bonne santé avec la disponibilité de médicaments de qualité et de prix abordables pour
tous
VALEURS :
 Qualité : elle reste toujours la marque de fabrique de notre entreprise Passion: Passionné
de fournir des soins de santé rentables pour tous, Innovation: efforts soutenus pour
introduire des solutions de soins de santé innovantes pour répondre aux besoins de santé
émergents de la population, Confiance: maintenir les plus hauts niveaux d'éthique,
d'honnêteté et d'intégrité dans l'entreprise, Socialement responsable: empathique et
attentionné envers les méritants pour la noble cause sociale
 Vision : être une entreprise pharmaceutique de premier plan en République démocratique du
Congo
I.1.4. ACTIVITES ORGANISEES
A son sein, le dépôt pharmaceutique PRINCE PHARMA organise deux activités principales :
Importation et Distribution de produits pharmaceutiques ;
Formations continue des personnels soignants
 Page 8 sur 59

1.1.5. Les ressources du dépôt pharmaceutique PRINCE PHARMA

a) Les ressources humaines
Les activités du dépôt pharmaceutique PRINCE PHARMA sont gérées et administrées par :
- Le Directeur Général
- Le gérant
- Le caissier
- Agent de la facturation
- Le livreur
- Les ouvriers

b) Ressources matérielles
Pour ce qui est de matériels, le dépôt pharmaceutique PRINCE PHARMA de Bukavu détient
trois ordinateurs de bureau, un ordinateur portable et ses accessoires, une Imprimante, quatre
caméra, , trois téléphones digitaux, Cinq chaises roulantes de bureau, trois tables bureau, une
table, 7 armoires, une garde archive métallique, une étagère, un coffre-fort, un appareil
photo, six chaises en bois, quatre malles, trois agrafeuse, 2 perforateur, six machines
cuivriques, deux téléphones portables, et autres petits matériels de bureau.
 Page 9 sur 59

I.1.6. STRUCTURE ORGANISATIONNELLE ET FONCTIONNELLE

Une structure : est l’ensemble des dispositifs par lesquels une entreprise repartit, organise,
coordonne et contrôle ses activités [6].

a) ORGANIGRAMME DU DEPOT PHARMACEUTIQUE PRINCE PHARMA

L’organigramme du dépôt pharmaceutique PRINCE PHARMA se présente comme suit :

Directeur Général

Gérant

Caissier Livreur
Facturier

Les ouvriers

Figure 1 Organigramme du dépôt pharmaceutique

 Page 10 sur 59

b) STRUCTURE FONCTIONNELLE

Le fonctionnement au sein de dépôt pharmaceutique PRINCE PHARMA se fait à

Travers ses organes ci-dessous :
 Le Directeur Général
Il est chargé de:
Définir la politique de gestion des ressources ;
Assurer le respect des prescriptions légales, réglementaire et statutaire ;
Mettre en application une politique pouvant aider l'organisation à atteindre ses
Objectifs.
 Le Gérant
Celui-ci étant le superviseur de l’entreprise, doit contrôler tous les mouvements dans l’entreprise, à
son tour doit vérifier la facture et ordonner la livraison des marchandises, après la livraison il doit
confirmer l’opération et contrôler le stock restant
 Le facturier
Le facturier est l’opérateur qui se charge d’acquérir et recevoir la demande de chaque client c’est
lui qui ajoute les clients dans le système, il enregistre les commandes et facturer les commandes
 Caissier
Quant à lui doit consulter la facture imprimée à la facturation, récupérer l’argent au près du client,
compter l’argent, enregistrer l’opération et déposer la facture au gérant
 Livreur
C’est lui qui récupère les articles dans le magasin et amener à la livraison, il doit consulter la facture
imprimée à la facturation et signer à la caisse pour ne pas livrer les produits non commandés.
 Les Ouvriers
Sont chargés de faire le déplacement des produits depuis l’arrivé dans les camions, ils sont les
protocoles de sécurité et règlementations vigueur, ils travaillent prudemment et soigneusement car
ils manipulent les produits sensibles
 Page 11 sur 59

I.2. ANALYSE DU SYSTEME EXISTANT

L’analyse de l’existant est une étape de la programmation sur l’ordinateur qui consiste à étudier
l’énoncé du problème à traiter, la recherche des algorithmes propre à les résoudre et la rédaction des
spécifications du programme, raison pour laquelle dans ce point, nous allons effectuer l’analyse
du système existant pour mieux manipuler le nouveau système.
L’analyse de l’existant comporte les étapes suivantes.
 Analyse de la structure ;
 Analyse des postes de travail ;
 Analyse de documents ;
 Analyse de moyens de traitement ;
 Analyse de flux d’information ;
 Diagnostic de l’existant.

I.2.1 ANALYSE DE FLUX D’INFORMATION

Un flux est un transfert d’information entre acteurs externe et interne du système d’information. Le
flux part d’un acteur source pour atteindre l’acteur but ; il est représenté par une flèche qui indique
la direction. (Prof Masanguluka, 2015-2016, cours de conception Méthode Merise inédit, G2
IG, ISP/Bukavu, p32. )
Pour le présent travail qui concerne l’informatisation de gestion d’une station de pétrole, le flux
d’information se schématise comme suit :
a) Diagramme des flux d’information de la livraison du produit pharmaceutique

Facturation

2
Client

Livraison
3
Caissier

4 5

Gérant

Figure 2 Diagramme des flux d’information de la livraison du produit pharmaceutique

 Page 12 sur 59

Légende :
1. Arrivée du client chez à la facturation et enregistre sa réquisition ;
2. L’agent de la facturation imprime et envoie la facture chez le caissier;
3. Le caissier reçoit l’argent et scelle la facture pour donner au gérant ;
4. Le gérant vérifie la facture et confirme la livraison ;
5. Le client reçoit ses produits à la livraison ;

a) Diagramme des flux d’information pour la gestion du personnel

Figure 3 Diagramme des flux d’information pour la gestion du personnel

Légende :
1. Arrivée de l’agent à la direction pour signer la présence en vue de prester ;
2. Octroi du billet de retrait à l’agent par le DG à la fin du mois ;
3. Remise du billet de retrait à la caisse pour vérification par le caissier ;
4. Remise du salaire à l’agent et signature de la fiche de paie ;
5. Remise du rapport à la direction par le caissier après opérations.

1.2.2. ANALYSE DE DOCUMENTS UTILISES

Comme notre travail s’occupe de la gestion des de stock du dépôt pharmaceutique, nous sommes
contraints premièrement de présenter le document qui est en usage habituel pour ce service et qui
va nous permettre ainsi d’avoir les informations qui interviennent dans le traitement manuel de cette
dite vente et qui nous aidera ainsi dans la proposition d’une solution informatisé pour cette gestion.
Parmi les documents qui sont utilisés, citons :
 Page 13 sur 59

La facture : c’est un document imprimé après la saisi de chaque réquisition des clients, il
atteste la vente des produits pharmaceutiques.
Elle est obligatoire pour toute mouvement commercial entre client et le dépôt

Figure 4 La facture
 Page 14 sur 59

Etat de paie du personnel

C’est un document qui récapitule les éléments de rémunération d’un salarié pour une période d’un
mois selon Prince pharma

PRINCE PHARMA
DEPOT PHARMACEUTIQUE
RCCM : 14-B-3367, ID.Nat.01-F4300-K25707C
Avenue P.E Lumumba, Numero 40, Bukavu-RDC
Noms Agents Fonctions Prestation Revenus Crédit Net à Billet
Menstruelle Menstruelle payer de Paie

1.2.3. APPRECIATION CRITIQUE DU SYSTEME EXISTANT

La critique de l’existant consiste à faire ressortir toutes les anomalies constatées au cours de l’étude
préalable afin de déterminer leurs causes. Elle constitue le point de départ de l’étude parce qu’elle
permet de mettre en évidence les principaux problèmes liés soit à l’insuffisance des moyens actuels.
Elle permet aussi de mettre en évidence au cours d’un projet les disfonctionnements des procédures
et des processus. La phase de critique constructive de l’existant va nous permettre progressivement
de mieux comprendre le problème et nous suggérer des pistes de solutions, [9].
a) Critique des documents utilisés
Les documents qui sont d’usage dans la gestion des opérations de vente des produits
pharmaceutiques au sein du dépôt pharmaceutique Prince pharma sont à apprécier positivement du
fait qu’ils sont toujours à jour selon la nécessité des tâches commerciales à réaliser et montrent
clairement les informations sur les produits et les clients.

b) Critique des moyens de traitement

Nous devons signaler un retard technologique et informatique dans la gestion des opérations de
vente de produit pharmaceutique et de paie du personnel au sein du dépôt pharmaceutique Prince
pharma, du fait certaines informations de différents produits ne sont pas inclues dans le système de
facturation il y a confusion entre les produits commandés mais également pousser à la reprise des
marchandises non commandées
 Page 15 sur 59

1.2.4. PROPOSITION DE LA SOLUTION

Après une critique objective du système existant, une solution est envisagée qui est la solution
informatique.
La solution informatique
La solution informatique implique l’informatisation du système qui consiste à mettre en place un
système informatique en créant une base de données pour la gestion des opérations relatives au
traitement d’information ayant trait à la vente du carburant. Cette solution fait recours aux matériels
informatiques et aux logiciels appropriés qui faciliteront au personnel d’assurer gestion automatique
desdites opérations et ainsi de mettre à la disposition des nécessiteux les résultats attendus dans le
temps opportun.
Avantages : Sécurité de l’information, gain de temps, accès facile aux données et la fiabilité des
résultats.
Inconvénients : Le mobilisation du matériel informatique et perfectionnement du personnel en vue
de s’adapter au fonctionnement du nouveau système.
Conclusion partielle
Dans ce chapitre, nous avons essayé de passer en revue de la présentation du milieu d’étude du point
de vue situation géographique, organisationnel, fonctionnel, tout en atterrissant par l’étude du
système d’information existant où nous avons essayé de faire l’analyse des flux d’information, des
documents qui sont d’usage habituel dans la gestion de stock des produits pharmaceutiques et de
gestion du personnel au sein du dépôt pharmaceutique Prince Pharma étant donné que ceci nous
donnent les informations qui vont nous être utiles dans le chapitre suivant concernant la
modélisation du nouveau système.
 Page 16 sur 59

CHAPITRE DEUXIEME : ETUDE ET MODELISATION DU SYSTEME

L’évolution des techniques de programmation a toujours été dictée par les besoins de concevoir et
de maintenir des applications toujours plus complexes.
Modéliser un système avant sa réalisation, permet de mieux comprendre son fonctionnement. Le
langage UML a été utilisé pour modéliser le système et le logiciel suivant « Visual Paradigm for
UML 10.2(20130710) » pour la réalisation des diagrammes.
La Modélisation c’est l’effet de modéliser, qui veut dire tout simplement concevoir ou élaborer une
information d’une façon facile à comprendre et à atteindre le but.

Dans ce chapitre, notre étude va se baser sur certaines analyses dans l’entreprise pour
identifier les points négatifs et spécifier les besoins nécessaires de l’entreprise. Ensuite on va
élaborer la modélisation des informations à l’aide de la méthode UP(Unified Process) qui nous
aidera à concevoir un système de gestion capable de mettre les activités plus faciles et claires sur
les processus des différentes réactions des acteurs dans l’entreprise PRINCE PHARMA, enfin nous
devons élaborer un plan d’action spécifié pour proposer une solution sur la bonne gestion de ces
produits pharmaceutiques stockés.

II.1. SPECIFICATION DES BESOINS

Les phases d'expression et d'analyse du besoin permettent de décrire les fonctionnalités du logiciel
et les contraintes sous lesquelles celui-ci doit être réalisé. Les besoins sont exprimés par l'utilisateur
dans le cahier des charges rédigé en langage naturel. C’est
une étape décisive pour le développement de notre application, elle nous servira dans la
détermination des besoins; son but est de veiller à développer un logiciel qui répond aux exigences
des utilisateurs, elle se forge de donner une vue sur la description générale des fonctionnalités du
système en se fondant sur les différents détails en répondant aux questions suivantes :
 Quels problèmes l’application résoudra-t-elle ?
 Quelles seront les conditions d’utilisation de l’application ?
 Quand l’application sera-t-elle utile ?
 Pourquoi l’application est-elle importante ?
 Comment l’application fonctionnera-t-elle ?
La réponse à chacune de ces questions doit constituer une piste de solution aux problèmes retrouvé
dans notre entreprise de recherche.
C’est pourquoi, selon les ambitions poursuivies dans notre recherche l’application fournie pour la
gestion de stock du dépôt pharmaceutique PRINCE PHARMA doit être capable :
 L’Application va résoudre les problèmes basés sur l’enregistrement des clients,
enregistrement des commandes, enregistrement des paiements, impression des factures ou
reçues et la visualisation des commandes
 Les utilisateurs doivent se connecter avant de commencer
 Quand elle répond aux besoins de ses utilisateurs à temps réel
 Page 17 sur 59

 Elle importante car elle corrige les abus de l’ancienne application qui maquait quelques
fonctionnalités importantes dans la gestion.
 L’application va fonctionner sur connexion
Notre investigation est établie sur la conduite des projets informatiques qui procèdent par la
modélisation basée sur le processus unifié (UP), qui étant un processus du langage de modélisation
unifié UML (Unified Modeling Language).
La méthode UP distingue deux types de besoins dont les besoins fonctionnels et les besoins non
fonctionnels ou techniques.
II.1.1 Les besoins fonctionnels
Les besoins fonctionnels expriment les opérations réalisables par le système. Ce sont des besoins
qui spécifient le comportement d’entrée/sortie du système. Ces besoins conduisent à l’élaboration
des cas d’utilisation. Pour mieux avancer dans tout ça il nous serait utile de déterminer les acteurs
qui vont intervenir avec le système.
 Identification des acteurs
Dépendamment de notre recherche et l’observation sur terrain, on a identifié quatre principaux
acteurs interagissant avec le système de gestion de notre entreprise, notamment le facturier, le et le
gérant.
Dans le cadre de notre travail, on a déterminé comme rôles de nos acteurs :
Facturier il sera chargé d’enregistrer les clients dans le système de gestion,
enregistrer les commandes, imprimer la facture
Le gérant Gérer les utilisateurs et Visualiser les commandes

Tableau 1 Identification des acteurs

II.1.2 Les besoins non fonctionnels

Les besoins opérationnels appelés encore non fonctionnels représentent les caractéristiques du
système comme la performance, la sécurité et l’ergonomie de ce dernier. Ces besoins peuvent être,
pour le cas de notre système :

L’ergonomie des interfaces :

- L’interface de notre application, sera délicate car elle est simple et claire ; La manipulation
de l'interface ne nécessite pas des connaissances approfondies.
- L’application est compatible avec n'importe quel système d'exploitation, facile à manipuler,
compréhensible.
- L’application est Robuste : notre application sera forte, vigoureuse et doit résister à des
modifications.
- L'application doit permettre le stockage des informations des utilisateurs inscrits, ainsi
qu'assurer une bonne gestion d'erreurs. Pendant l’utilisation, l’application doit donner la
possibilité d’une utilisation efficace c’est-à-dire qui ne plante pas.
 Page 18 sur 59

- L’application doit être capable de certifier la sécurité des données :

La rapidité de traitement : En effet, vu le nombre important d’opérations quotidiennes, il est
impérativement nécessaire que la durée d'exécution des traitements s'approche le plus possible du
temps réel.
La performance : Un logiciel doit être avant tout performant c'est-à-dire à travers ses
fonctionnalités, répond à toutes les exigences des usagers d'une manière optimale.

La convivialité : Le futur logiciel doit être facile à utiliser. En effet, les interfaces utilisateurs doivent
être conviviales c'est-à-dire simples, ergonomiques et adaptées à l'utilisateur.

II.2. DEMARCHE METHODOLOGIQUE

Il existe plusieurs méthodes de développement logiciel construites sur le langage de modélisation
unifié (UML). Parmi elles nous pouvons citer :
La famille des méthodes UP (RUP, TTUP, UP, 2TUP) ;
Les méthodes Agiles (XP, Crystal, ASD, Scrum et DSDM) ;
Parmi ces méthodes notre choix est basé sur la méthode UP (Unified Process).

II.2.1. La méthode U.P : (Unified Process - Processus Unifié) = c’est une famille de méthodes de
développement de logiciels orientés objet.
Le processus unifié est un processus de développement logiciel construit sur UML. est une méthode
qui se caractérise par une démarche itérative et incrémentale, centré sur l'architecture, piloté par des
cas d'utilisation et orienté vers la diminution des risques. Il regroupe les activités à mener pour
transformer les besoins d’un utilisateur en système logiciel9.

9
https://fr.wikipedia.org/wiki/Two_Tracks_Unified_Process
 Page 19 sur 59

II.2.2. Les principes de la méthode UP

Associé à UML, le processus de développement UP met en œuvre quatre principes suivants :
Processus piloté par les cas d'utilisation : pour montrer juste que le système informatique à réaliser
doit tout d’abord définir les utilisateurs et les fonctionnalités qu’ils vont y effectuer il correspond à
un ensemble d’actions réalisées par le système en interaction avec les acteurs en vue de réaliser un
bon résultat
Processus itératif et incrémental : signifiant que le développeur modélise les besoins de l’utilisateur
et à chaque fois il est demandé de revenir chez celui-ci en vue de lui montrer ce qu’il a déjà fait pour
que l’utilisateur l’apprécie et pouvoir y intégrer les éléments de correction avant de passer à une
autre étape en évitant ainsi le risque du rejet de l’ouvrage après avoir tout finit sans l’avis de
l’utilisateur final.

Figure 5 Processus itératif et incrémental

 Page 20 sur 59

Processus centré sur l'architecture : cela signifie que pour tout projet informatique, il s’avère
indispensable de définir l’architecture qui sera retenue pour sa conception, ici l’architecture
décrit « Comment faire »
Processus orienté par la réduction des risques : les risques parlés ici signifie le fait de concevoir
un projet qui ne répond à rien comme besoins des utilisateurs finaux. Pour cela, c’est le fait
d’incrément-itératif qui fait que le processus unifié réduit les risques. Ces principes sont à la base
du processus unifié décrit par les auteurs d'UML.

II.2.3. Les phases de la méthode UP

Le processus unifié se déroule en quatre phases, incubation, élaboration, construction et transition.
Chaque phase répète un nombre de fois une série d’itérations. Et chaque itération est composée de
cinq activités : capture des besoins, analyse, conception, implémentation et test.
a). Incubation
C’est la première phase du processus unifié. Il s’agit de délimiter la portée du système, c’est-à-dire
tracer ce qui doit figurer à l’intérieur du système et ce qui doit rester à l’extérieur, identifier les
acteurs, lever les ambiguïtés sur les besoins et les exigences nécessaires dans cette phase.
Il s’agit aussi d’établir une architecture candidate, c’est-à-dire que pour une première phase, on doit
essayer de construire une architecture capable de fonctionner. Dans cette phase, il faut identifier les
risques critiques susceptibles de faire obstacles au bon déroulement du projet.
b). Elaboration
C’est la deuxième phase du processus. Après avoir compris le système, dégagé les fonctionnalités
initiales, précisé les risques critiques, le travail à accomplir maintenant consiste à stabiliser
l’architecture du système. Elle permet d’avoir une bonne connaissance des besoins des utilisateurs
Il s’agit alors de raffiner le modèle initial de cas d’utilisation, voire capturer de nouveaux besoins,
analyser et concevoir la majorité des cas d’utilisation formulés, et si possible implémenter et tester
les cas d’utilisation initiaux.
c). Construction
Dans cette phase, il faut essayer de capturer tous les besoins restants car il n’est pratiquement plus
possible de le faire dans la prochaine phase. Ensuite, continuer l’analyse, la conception et surtout
l’implémentation de tous les cas d’utilisation. A la fin de cette phase, les développeurs doivent
fournir une version exécutable du système.
d). Transition
C’est la phase qui finalise le produit. Il s’agit au cours de cette phase de vérifier si le système offre
véritablement les services exigés par les utilisateurs, détecter les défaillances, combler les manques
dans la documentation du logiciel et adapter le produit à l’environnement (mise en place et
installation).
 Page 21 sur 59

II.2.4. Cycle de vie du processus unifié

L'objectif d'un processus unifié est de maîtriser la complexité des projets informatiques en diminuant
les risques. UP est un ensemble de principes génériques adapté en fonctions des spécificités des
projets.
L’architecture bidirectionnelle : UP gère le processus de développement par deux axes à savoir :
L'axe vertical : représente les principaux enchaînements d'activités, qui regroupent les activités
selon leur nature. Cette dimension rend compte l'aspect statique du processus qui s'exprime en
termes de composants, de processus, d'activités, d'enchaînements, d'artefacts et de travailleurs.
L'axe horizontal : représente le temps et montre le déroulement du cycle de vie du processus ; cette
dimension rend compte de l'aspect dynamique du processus qui s'exprime en terme de cycles, de
phases, d'itérations et de jalons.

Figure 6 Cycle de vie du processus unifié

Adaptation du processus unifié

Il existe plusieurs processus de développement qui implémente l’UP dont le plus intéressant le 2UP
(2 Tracks Unified Process). Pour un modèle 2TUP, tout développement peut être décomposé et
traités en parallèle selon un axe fonctionnel et un axe technique. Nous pouvons ainsi suivre les
évolutions liées aux changements des besoins fonctionnels et aux changements des besoins
techniques. La schématisation du processus de développement correspond alors à un Y. Les deux
perspectives se rejoignant lors de la phase de conception préliminaire.
La branche fonctionnelle contient la capture des besoins et de leurs analyses. Les résultats de
l'analyse sont indépendants des technologies utilisées ; alors que la branche technique contient la
capture des besoins techniques et de la conception générique.
L'architecture technique construit le squelette du système informatique indépendamment des
besoins fonctionnels. Les deux branches sont ensuite fusionnées en une seule branche qui prend en
charge la conception préliminaire (cartographie des composants à développer), conception détaillée
(comment réaliser chaque composant), codage (production des composants), tests et étapes de
validation des fonctions développées.
 Page 22 sur 59

II.3. DEVELOPPEMENT DE LA METHODE CHOISIE

II.3.1 Présentation de Diagramme de cas d’utilisation
Est un ensemble d’actions réalisées par le système en réponse à une action d’un acteur
Ils permettent de décrire l'interaction entre l'acteur et le système. L'idée forte est de dire que
l'utilisateur d'un système logiciel a un objectif quand il utilise le système ! Le cas d'utilisation est
une description des interactions qui vont permettre à l'acteur d'atteindre son objectif en utilisant le
système. Les use case (cas d'utilisation) sont représentés par une ellipse sous-titrée par le nom du
cas d'utilisation (éventuellement le nom est placé dans l'ellipse). Un acteur et un cas d'utilisation
sont mis en relation par une association représentée par une ligne.
Dans cette notion, on entend par :
Système : l’interface dans laquelle se déroulent les actions ;
Acteur : Une entité externe qui agit sur le système ; Le terme acteur ne désigne pas seulement les
utilisateurs humains mais également les autres systèmes. Les acteurs sont des classificateurs qui
représentent des rôles au travers d'une certaine utilisation (cas) et non pas des personnes physiques.
Les acteurs : Ils sont des entités externes qui interagissent avec le système, comme une personne
humaine ou un robot. Une même personne (ou robot) peut être plusieurs acteurs pour un système,
c'est pourquoi les acteurs doivent surtout être décrits par leur rôle, ce rôle décrit les besoins et les
capacités de l'acteur. Un acteur agit sur le système. L'activité du système a pour objectif de satisfaire
les besoins de l'acteur. Les acteurs sont représentés par un pictogramme humanoïde (stick man)
sous-titré par le nom de l'acteur
Un acteur peut avoir différents rôles et est amené à intervenir dans une ou plusieurs situations. Miller
(2001) en identifiant quatre acteurs qui sont :

 Initiateur : acteur qui active le système et déclenche le cas.

 Serveur : acteur aidant le système à assumer ses responsabilités.
 Receveur : acteur recevant les informations du système (système de backup)
 Facilitateur : acteur dont les actions sont effectuées au bénéfice d'un autre acteur
- Les relations entre les cas d’utilisation : Trois types de relations sont prises en charge par la
norme UML et sont graphiquement représentées par des types particuliers de ces relations. Les
relations indiquent que le cas d'utilisation source présente les mêmes conditions d'exécution que le
cas issu. Une relation simple entre un acteur et une utilisation est un trait simple.
 Relation d’inclusion : Dans ce type d'interaction, le premier cas d'utilisation inclut le second
et son issue dépend souvent de la résolution du second. Ce type de description est utile pour
extraire un ensemble de sous-comportements communs à plusieurs tâches, comme une
macro en programmation. Elle est représentée par une flèche en pointillé et le terme include.
 Relation d’extension : Les extensions (extend) représentent des prolongements logiques de
certaines tâches sous certaines conditions. Autrement dit un cas d'utilisation A étend un cas
d'utilisation B lorsque le cas d'utilisation A peut être appelé au cours de l'exécution du cas
d'utilisation B. Elle est représentée par une flèche en pointillée avec le terme extend.
Ce type de relation peut être utile pour traiter des cas particuliers ou fonctions optionnelles,
 Page 23 sur 59

préciser les objectifs, ou encore pour tenir compte de nouvelles exigences au cours de la
maintenance du système et de son évolution.

 Relation de généralisation : La troisième relation est la relation de généralisation ou

spécialisation. Le cas d'utilisation A est une généralisation de B, si B est un cas particulier
de A c'est-à-dire lorsque A peut-être substitué par B pour un cas précis. Ces relations sont
des traits pleins terminés par une flèche en triangle.
 Page 24 sur 59

Dans le cadre de notre travail, le diagramme de cas d’utilisation se présente comme suit :

Figure 7 Diagramme de cas d'utilisation

 Page 25 sur 59

II.3.2. Description textuelle des cas d’utilisation

Pour le cas de notre travail, nous allons décrire les deux cas d’utilisation dont :
« Enregistrer un client », « Enregistrer les commandes », « Gérer les utilisateurs » « Visualiser
les commandes ».
En terme d’éclaircissement CU ne signifie que cas d’utilisation d’où notre premier cas d’utilisation
est décri de la manière suivante :

a) CU1 : « Enregistrer un client »

CU1 «Enregistrer un client»
Résumé Le CU1 Permet au Facturier d’ajouter un client dans le pour
permettre aux clients passer les commandes.

Facturier
: Acteur
Près-condition Etre connecté
Description du scénario <Début>
principal 1. Le système affiche une page d’accueil ;
2. Le Facturier se connecte au système
3. Dans l’interface client il clique sur ajouter
4. L’agent saisie les coordonnées du client ;
5. Après la saisie des données il clique sur le bouton
enregistrer et directement le client sera ajouter dans le
système
Scenario Alternatif A4 : Si le facturier laisse les champs non incomplètes, le
système affiche le message d’erreur et retourne à la
cinquième position

Tableau 2 CU Enregistrer un Client

 Page 26 sur 59

b) CU2 : « Enregistrer les commandes »

CU2 «Enregistrer les commandes»
Résumé Le CU2 Permet au Facturier de soumettre les commandes
des clients au système moyennant une réquisition du client

Facturier
: Acteur
Près-condition Consulter la réquisition
Description du <Début>
principal 1. Le Facturier reçoit la réquisition et cherche le client
scénario dans le système
2. Le Facturier ajoute une commande en sélectionnant les
articles commandés par le client
3. Le système vérifie si la quantité commandés est
inférieur ou égal à la quantité en stock
4. Le Facturier enregistre confirme la commande
5. Le système affiche Facturer pour visualiser et
imprimer la facture
Scenario Alternatif A3 : si les données sont incorrectes, on réalise l’opération N°6
6. Le système envoie un message d’erreur, « la quantité
commandée est supérieur à la quantité en stock »
7. Si les données sont correctes le système passe à
l’opération n°8
8 : le système Imprime la facture

Tableau 3 CU « Enregistrer les commandes »

 Page 27 sur 59

c) CU3 : « Gérer les utilisateurs »

CU3 «Gérer les utilisateurs »
Résumé Le CU3 Permet au Gérant de gérer les utilisateurs, il peut
ajouter, modifier ou supprimer l’utilisateur

Gérant
: Acteur
Près-condition Etre connecté comme Gérant
Description du <Début>
Principal 1. Le gérant se connecte au système
scénario 2. Le gérant accède dans l’interface utilisateur
3. Le système affiche les boutons Ajouter, Modifier et
Supprimer
4. Le Gérant fait l’opération de son choix

Scenario Alternatif A3 : si les conditions sont respectées l’utilisateur sera géré

selon le choix du gérant
5. Le système modifie les informations sur l’utilisateur

Tableau 4 CU Gérer les utilisateurs

d) CU4 : « Visualiser les commandes »

CU4 « Visualiser les commandes »

Résumé Le CU4 Permet au Gérant de contrôler les commandes et les
ventes effectuées, d’où il peut voir, modifier ou supprimer une
vente
Gérant
: Acteur
Près-condition S’authentifier en fournissant son login et le mot de passe
 Page 28 sur 59

Description du scénario <Début>

principal 1. Le système affiche une page de connexion ;
2. Le Gérant fournit le login et le mot de passe au système ;
3. Le système ouvre l’interface gérant
4. Le gérant accède dans vente et visualise les différentes
ventes
5. Le système donne au gérant l’opportunité de modifier une
vente ou supprimer;
6. Le système propose au gérant l’impression de la facture

Scenario Alternatif A3 : si les ventes sont mal faites le gérant peut modifier selon le
cas, si toutes les conditions sont respectées le système imprime la
facture.
Tableau 5 Visualiser les commandes

II.3.3. Elaboration des diagrammes de séquence

La figure suivante représente le diagramme de séquence qui illustre le scénario d’authentification.
Quand l’un des acteurs veut utiliser le système, il doit d’abord introduire son identifiant et son mot
de passe. Si ces deux entrées sont correctes, le système affichera le menu principal de l’application,
sinon il affichera le message suivant : « Identifiant ou mot de passe incorrect »., concernant notre
travail, nous présenterons les diagrammes de séquence pour les cas d’utilisations ci-après :
 Enregistrer les clients
 Enregistrer les commandes
 Gérer les utilisateurs
 Visualiser les commandes
a) Diagramme de séquence « Enregistrer un client »

Figure 8 Diagramme de séquence Enregistrer les Clients

 Page 29 sur 59

b) Diagramme de séquence « Enregistrer les Commandes »

Figure 9 Diagramme de séquence Enregistrer Commande

 Page 30 sur 59

c) Diagramme de séquence « Gérer les utilisateurs »

Figure 10 Diagramme de séquence Gérer les utilisateurs

 Page 31 sur 59

d) Diagramme de séquence « Visualiser les commandes »

Figure 11 Diagramme de séquence Visualiser les commandes

II.4.3. Diagramme d’activités

Le diagramme d’activité (Activity Diagram) fait partie des diagrammes comportementaux.
Il est utilisé pour modéliser les aspects dynamiques d'un système, (www.fun-mooc.fr/LeConDAC).
La modélisation peut être utilisée pour décrire le déroulement d'un cas d'utilisation ou d'une
méthode. Les diagrammes d'activité affichent le flux de travail d'un point de départ à un point
d'arrivée en détaillant les nombreux chemins de décision existant dans la progression des
événements contenus dans l'activité.
A titre d’exemple, nous utilisons quatre cas d’utilisations pour le diagramme d’activité dont :
Enregistrer client, Enregistrer commandes, Gérer les utilisateurs et Visualiser les commandes.
Les activités de notre système de gestion :
- Enregistrer Client : c’est l’une des activités principales de notre système de gestion. D’où Le
Facturier(utilisateur) doit enregistrer les clients dans la base de données pour retenir leur adresse
ainsi que d’autres coordonnées.
 Page 32 sur 59

a) Le diagramme d’activité « Enregistrer client »

Figure 12 Diagramme d'activité Enregistrer client

b) Le diagramme d’activité « Enregistrer commandes »

Figure 13 Diagramme d'activité Enregistrer commandes

 Page 33 sur 59

c) Le diagramme d’activité « Visualiser les commandes »

Figure 14 Diagramme d'activité Visualiser les commandes

 Page 34 sur 59

II.4.4. Le diagramme de classes récapitulatif

Le diagramme de classes est un schéma utilisé pour présenter les classes et les interfaces des
systèmes ainsi que leurs relations. Ce diagramme fait partie de la partie statique d'UML, ne
s'intéressant pas aux aspects temporels et dynamiques.
Une classe est une représentation abstraite d’un d’ensemble d’objets, elle contient les informations
nécessaires à la construction de l’objet (c'est-à-dire la définition des attributs et des méthodes), La
classe peut donc être considérée comme le modèle, le moule ou la notice qui va permette la
construction d’un objet. Nous pouvons encore parler de type (comme pour une donnée).
Un objet est une instance d’une classe (la concrétisation d’une classe).
Une classe est représentée par un rectangle (appelé aussi classeur) qui est toujours divisé en 3
compartiments à savoir :
 Le nom de la classe : qui représente le type d’objet instancié ;
 Les attributs ;
 Les méthodes ;
Le diagramme des classes est un diagramme structurel ou statique d’UML qui permet de
représenter les classes (attributs + méthodes) et les associations (relations) entre les classes.
Le diagramme de classes est le plus important des diagrammes UML, parce que c’est le seul qui soit
obligatoire lors de la modélisation objet d’un système.
 Page 35 sur 59

Figure 15 Diagramme de classe récapitulatif

II.4.5. Présentation du diagramme de déploiement

En UML, un diagramme de déploiement est une vue statique qui sert à représenter l'utilisation de
l'infrastructure physique par le système et la manière dont les composants du système sont répartis
ainsi que leurs relations entre eux. Les éléments utilisés par un diagramme de déploiement sont
principalement les nœuds, les composants, les associations et les artefacts. Les caractéristiques
des ressources matérielles physiques et des supports de communication peuvent être précisées par
stéréotype
La représentation du diagramme de déploiement du futur système fait usage de trois nœuds, dont un
serveur d’application, un serveur de base de données et le client (navigateur). Pour le cas du présent
système, le diagramme de déploiement se présente de la manière suivante :

Figure 16 Diagramme de déploiement

Conclusion partielle
Nous sommes à la fin de notre deuxième chapitre qui était consacré à la modélisation du système
informatique, au sein duquel nous avons essayé de présenter la méthode UP associé au langage
UML qui nous a permis de modéliser d’une manière efficace la vision globale et facile à comprendre
les interactions existantes dans la gestion de stock de notre entreprise d’où on a présenté les réactions
des différents acteurs et les processus impliqués dans ce système de gestion. L’utilisation de la
méthode UP permet d’assurer une meilleure qualité du code et une évolutivité nécessaire après le
développement du nouveau système.
 Page 36 sur 59

CHAPITRE TROISIEME : CONCEPTION ET REALISATION DE

L’APPLICATION

Dans le présent chapitre, il est question de présenter les outils et langages qui nous ont permis de
réaliser notre application de gestion de finance (prince-pharma). Dans la réalisation d’un travail de
conception d’une application informatique, les concepteurs se servent d’un ou plusieurs langages et
outils pour atteindre leurs objectifs. C’est ainsi que dans le cadre de ce travail, nous avons recouru
à certains langages qui nous ont permis d’atteindre les objectifs assignés à cette application.
Ce chapitre se subdivise en cinq parties. La première propose le choix et la présentation du langage
de programmation utilisée, la deuxième présente le choix et la présentation du SGBD utilisé, la
troisième essaye de présenter la réalisation de l’application en exposant les structures des tables,
requêtes, formulaires, états de sorties ainsi que les outils utilisés lors du développement. La
quatrième quant à elle consiste à faire une estimation de la durée et du coût de réalisation du logiciel.
En fin, la dernière section consiste à faire la présentation du guide de l’utilisateur.

III.1 Choix du SGBD utilisé

Dans le cadre de notre travail de TFC, notre choix a porté sur le Système de Gestion de Base de
Données (SGBD) MySQL pour des raisons suivantes :

- Il a un caractère OpenSource ;
- Il a des fonctionnalités de plus en plus riches ;
- Il est ouvert presque à tous les langages de programmation du marché ;
- Il est fonctionnel sur les systèmes les plus courants (les distributions classiques de LUNIX,
Windows, Mac OS, BSD, Novell et les dérivés d’UNIX) ;
- Il est facile à utiliser si on peut le dire aussi.

III.2. Outils de développement et environnement d’implémentation

Il serait difficile d’atteindre nos hypothèses sans autant pour faire recours aux quelques outils de
développement et d’implémentation. Les outils que nous avons utilisés au cours du développement
de notre application sont :
III.2.1 WampServer :

Xampp est un logiciel gratuit et open source qui fournit un environnement de

développement web, ce mot xampp n’est qu’acronyme qui représente les composants
du logiciel

Figure 17 Image Xampp

 Page 37 sur 59

III.2.2. PhpMyAdmin
PHP comprenant deux serveurs (Apache et MySQL), un interpréteur de script (PHP), ainsi que
phpMyAdmin pour l'administration Web des bases MySQL110.

PhpMyAdmin est un outil logiciel gratuit écrit en PHP, destiné à gérer

l’administration de MySQL sur le Web. Il prend en charge une large gamme
d’opérations sur MySQL tel que la gestion des bases de données, des
tableaux, des colonnes, des relations, des index, des utilisateurs, des
autorisations, etc. ses opérations peuvent être effectuées via l’interface
utilisateur, alors il offre aussi la possibilité d’exécuter directement une
instruction SQL2.

Figure 18 PhpMyAdmin

III.2.3. Les langages de programmation

Le PHP ou HyperText PreProcessor est un langage de programmation

spécialisé dans les scripts généralistes. Il est Open Source et très
ouvertement orienté web. Le trio Php-HtmlCSS avec MySQL, est souvent
rencontré dans le monde de la programmation web.
La nécessité d’utiliser PHP comme langage de scripts accompagnant le
HTML est un choix assez naturel dans ce sens que non seulement le PHP
peut se faire à l’intérieur des codes HTML mais aussi que les deux se
Figure 19 image Php complètent de nature sans engendrer des problèmes.

III.2.4. SQL

SQL signifie Structures Query Language ou Langage des requêtes

structurées. C’est un langage permettant de communiquer avec une base des
données. Ce langage informatique est notamment très utilisé par les
développeurs web pour communiquer avec les données d’un site web.

Figure 20 image Sql

III.2.5 Bootsrap Bootstrap est une collection d’outils utiles à la création du design (Animation, graphisme
et interactions avec la page dans le navigateur, …) de sites et d’applications web. C’est
un ensemble qui contient des codes HTML et CSS, des formulaires, boutons, outils de
navigation et autres éléments interactifs ainsi que des extensions JavaScript en option.

10
https://fr.wikipedia.org/wiki/Xampp
 Page 38 sur 59

III.2.6. HTML
’Hyper Text MarkUp Language n’est pas un langage de programmation HTML est d'un
langage de description (et non pas d'un langage de programmation) qui va nous permettre de
décrire l'aspect d'un document, d'y inclure des informations variées (textes, images, sons,
animations
Le terme markup se réfère aux marques, aux annotations manuscrites placées par l'auteur sur
un document pour préciser à l'imprimeur comment il doit être présenté. Avec l'apparition des
ordinateurs et des photocomposeuses, ces marques ont été intégrées dans le texte mais chaque
matériel de photocomposition réclamait son propre langage "markup" Au début des années
80, le CGA (Graphics Communications Association) a mis au point le premier langage
markup généralisé baptisé GenCode.
Figure 21 Image
HTML

CSS
Le cascading Style Sheets est un langage qui accompagne le HTML depuis plusieurs
années au point qu’aujourd’hui, ils sont presqu’indissociable. Le CSS a pour rôle de
s’occuper de la mise en forme des documents HTML ; en améliorant l’apparence des
fenêtres, les couleurs, l’agencement des objets graphiques, etc.

III.3. PRESENTATION DES QUELQUES INTERFACES DE L’APPLICATION

Avant de passer aux interfaces, voyons d’abord le modèle qui nous a servi pour le côté base de
données. Dans ce point, nous allons voir les tables de notre base de données et les autres aspects
fonctionnels de celle-ci.

III.3.1. Les tables

MySQL appelle database un regroupement logique d’objets (tables, index, vues, déclencheurs,
procédures cataloguées, etc.) pouvant être stockés à différents endroits de l’espace disque. Je ferai
donc souvent référence au terme « base de données » pour parler de cette notion. Pour cela, il suffit
d’ouvrir son navigateur, juste après avoir lancer le serveur local. Il faut pour cela double-cliquer sur
l’icône de xampp et l’exécuter en tant qu’administrateur. Il faut attendre jusqu’à ce que la petite
icône dans la barre de tâches vire au vert, depuis le rouge.
A présent, on se rend dans le navigateur et on tape : localhost
On se retrouve alors sur la page d’accueil de ou Xampp, qui ressemble à ceci :
 Page 39 sur 59

Figure 22 Interface Xampp

III.3.1 Structure de tables

Pour atteindre la réalisation de cette application, la structure des tables qui nous ont été utiles est la
suivante :
a) Table Utilisateur
Cette table nous enregistre les informations relatives aux intervenants de notre système, elle se
présente comme suit :

Figure 23 Table Utilisateurs

b) Table Clients
Cette dernière nous a été utile pour stocker les informations des clients interagissant le système,
nous avons fait recours à la table clients dont voici la figure

Figure 24 Table Clients

 Page 40 sur 59

c) Table Articles
Cette table nous a servis pour conserver les informations des différents produits stockés dans le
système. Elle est structurée de la manière suivante :

d) Table Commandes
Celle-ci nous a permis de stocker les informations issues des commandes du produit par le client.
Elle se présente comme suit :
 Page 41 sur 59

e) Table Approvisionnement
Cette table nous a servi de stocker les articles approvisionner par l’entreprise, elle
se présente comme suit :

Guide d’utilisateur
Cette partie est la dernière phase dans la conception d’une application. Elle est nécessaire dans toute
application par le fait où elle permet aux utilisateurs d’avoir une idée dans l’utilisation de cette
application.
Pour ce qui concerne notre application conçue, l’utilisation est simple et expliquée dans les pages
qui suivent.
Aux lancements de l’application, la page de présentation s’affiche la page de connexion sur laquelle
on demande à l’utilisateur d’entrer son login et son mot de passe pour accéder à la base de données
apparaît. Elle s’affiche de la manière suivante :

 Page d’Accueil
 Page 42 sur 59

Si le login et le mot de passe sont corrects, l’utilisateur accède au système selon son droit d’accès.
Pour notre exemple, la personne connectée est le Gérant. Sa page de gestion se présente comme suit
:

En cas d’ajout d’un produit pharmaceutique c’est une session de l’administrateur et il a la possibilité
d’ajouter, modifier et supprimer les produits et contrôler l’état de stock. Sa page de gestion se présente
comme suit :
 Page 43 sur 59

Notre système doit faciliter au gérant de découvrir le stock d’alerte (les articles de quantité inférieur
ou égal à 30 qui vont s’afficher en rouge dans la case de quantité) et les articles qui ont dépassés la
date d’expiration qui vont s’afficher en rouge toute la ligne comme ici :

Le gérant a aussi la possibilité d’approvisionner le stock de produits dans le système de gestion

selon le besoin et la demande, ici il peut voir la quantité de chaque article, il peut supprimer les
articles et peut approvisionner le stock, Cette session se présente comme suit :
 Page 44 sur 59

A part l’approvisionnement du stock le gérant peut Consulter les opérations de vente d’où il peut
Visualiser, modifier ou supprimer une vente.

Après une vente le gérant est capable d’afficher le détail d’une commande après avoir affiché la
commande il peut facturer et imprimer la facture si l’opération est déjà confirmée. Cette fenêtre
s’affiche ainsi :
 Page 45 sur 59

Dans ces tâches, le gérant peut contrôler la liste des clients ajoutés par le facturier d’où il peut,
modifier ou supprimer un client selon le besoin, cette session s’affiche ainsi :
 Page 46 sur 59

Pour la suppression un message d’alerte doit apparaître pour confirmer l’opération

Parmi ces occupations, il consulte également la liste des utilisateurs de ce système dont étant
connecté il peut ajouter, modifier ou supprimer un utilisateur dans le système, la session liste des
utilisateurs s’affiche comme suit :
 Page 47 sur 59

A part ces attributions faites par le Gérant le facturier également est l’un des utilisateurs de ce
système, il chargé d’enregistrer les clients dans le système et il peut modifier ou supprimer un client,
Cette fenêtre s’affiche comme ceci

Pour éviter les erreurs dites à la vitesse un message d’alerte doit s’afficher avant de modifier ou
supprimer un client dans le système de gestion d’où cette fenêtre s’affiche de cette manière :

Le facturier se charge également de contrôler la vente d’où il peut gérer les différentes commandes
passées par les clients, il peut modifier les factures commandes avant de facturer, la fenêtre de
gestion de vente s’affiche comme :
 Page 48 sur 59

Avant d’ajouter la vente le facturier doit sélectionner l’un des clients enregistrer dans le système,
après ça il doit menant enregistrer la vente qui va lui permettre de sélectionner les articles
commandés par le client, il a la possibilité de modifier ou supprimer la vente s’il n’a pas encore
facturé, après la facturation il est impossible de modifier encore l’opération, cette fenêtre s’affiche
comme suit :

Pendant l’ajout des articles commandés le système doit afficher la quantité en stock de chaque article
pour éviter l’erreur de facturation il doit également afficher un message d’alerte.
Page 49 sur 59
 Page 50 sur 59

CONCLUSION
Etant donné que toute chose qui a un amont doit avoir un aval, c’est en ce mot que nous concluons notre
travail qui vaquait sur « Gestion de stock d’un dépôt Pharmaceutique, cas de PRINCE PHARA/Bukavu ».
Il s’agissait de mettre en place une application web offrant à l’entreprise une application qui gère d’une
manière efficace le stock en corrigeant quelques insuffisances de l’application existante.
Dépendamment de notre problématique qui se basait sur deux questions dont :
 Quel serait le type de système à mettre en place pour gérer de manière efficace et efficiente
les opérations de gestion au sein du dépôt pharmaceutique PRINCE PHARMA en corrigeant
cette application non performante?
 Quels sont les avantages et les limites d’une application de gestion de stock dans le dépôt
pharmaceutique PRINCE PHARMA ?

On a su que ce travail est tellement avantageux pour nous car on a réalisé notre ambition de contribuer dans
l’informatisation de l’une des entreprises de distribution des produits pharmaceutiques dans la ville de
Bukavu qui contribuera aussi à l’amélioration des traitements médicaux dans cette ville.
Malgré la gestion automatisée de l’entreprise Prince pharma il y avait toujours quelques insuffisances au
niveau de son système de gestion parmi lesquels on a relevé la non transparence de l’état de stock qui va
faciliter les utilisateurs sur l’information générale du stock.

Pour vérifier cela la technique d’interview et d’observation nous ont permis à palper du doigt la réalité sur
terrain afin de le matérialiser par la méthode UP.
Cependant hormis l’introduction et la conclusion ce travail été reposé sur trois chapitres entre autres :
Le premier portant sur la GENERALITE SUR LE MILIEU D’ETUDE ;
Le deuxième sur ETUDE ET MODELISATION DU SYSTEME ;
Et le dernier sur la CONCEPTION ET REALISATION DE L’APPLICATION
 Page 51 sur 59

Table des matières

EPIGRAPHE .................................................................................................................................... I
DEDICACES.................................................................................................................................... II
REMERCIEMENTS ..................................................................................................................... III
SIGLES et ABREVIATIONS ......................................................................................................... IV
LISTE DES TABLEAUX .............................................................................................................. V
LISTE DES FIGURES .................................................................................................................. VI
0. INTRODUCTION .................................................................................................................... 1
0.1. PROBLEMATIQUE ........................................................................................................... 1
0.2. HYPOTHESE ................................................................................................................... 2
0.3. ETAT DE LA QUESTION .............................................................................................. 2
0.4. OBJECTIF DU TRAVAIL .............................................................................................. 3
0.5. CHOIX ET INTERET DU SUJET ................................................................................. 3
0.5.2. Intérêt du sujet .............................................................................................................. 4
0.6. METHODES ET TECHNIQUES ................................................................................... 5
0.6.1. METHODES .............................................................................................................. 5
0.6.2. TECHNIQUES .......................................................................................................... 5
0.7. DELIMITATION DU SUJET ......................................................................................... 6
0.8. DIFFICULTES RENCONTREES .................................................................................. 6
0.9. SUBDIVISION DU TRAVAIL ........................................................................................ 6
CHAPITRE PREMIER : GENERALITES SUR LE MILIEU D’ETUDE ............................... 7
I.1. PRESENTATION DE PRI NCE PHARMA BUKAVU .................................................... 7
I.1.1. SITUATION GEOGRAPHIQUE ................................................................................ 7
I.1.2. BREVE HISTORIQUE.................................................................................................. 7
I.1.3. OBJECTIFS POURSUIVIS .......................................................................................... 7
I.1.4. ACTIVITES ORGANISEES ......................................................................................... 7
1.1.5. Les ressources du dépôt pharmaceutique PRINCE PHARMA................................. 8
I.1.6. STRUCTURE ORGANISATIONNELLE ET FONCTIONNELLE ............................ 9
I.2. ANALYSE DU SYSTEME EXISTANT .......................................................................... 11
I.2.1 ANALYSE DE FLUX D’INFORMATION ........................................................................ 11
1.2.2. ANALYSE DE DOCUMENTS UTILISES ................................................................... 12
1.2.3. APPRECIATION CRITIQUE DU SYSTEME EXISTANT ................................... 14
1.2.4. PROPOSITION DE LA SOLUTION ........................................................................ 15
CHAPITRE DEUXIEME : ETUDE ET MODELISATION DU SYSTEME ...................... 16
II.1. SPECIFICATION DES BESOINS .................................................................................. 16
 Page 52 sur 59

II.2. DEMARCHE METHODOLOGIQUE ............................................................................ 18

II.3. DEVELOPPEMENT DE LA METHODE CHOISIE ................................................... 22
II.4.3. Diagramme d’activités ................................................................................................ 31
CHAPITRE TROISIEME : CONCEPTION ET REALISATION DE L’APPLICATION36
III.1 Choix du SGBD utilisé ...................................................................................................... 36
III.2. Outils de développement et environnement d’implémentation ....................................... 36
III.2.1 WampServer : ............................................................................................................. 36
III.2.2. PhpMyAdmin............................................................................................................. 37
III.2.3. Les langages de programmation .............................................................................. 37
III.2.4. SQL ............................................................................................................................. 37
III.2.5 Bootsrap ........................................................................................................................ 37
III.3. PRESENTATION DES QUELQUES INTERFACES DE L’APPLICATION .......... 38
III.3.1. Les tables .................................................................................................................... 38
III.3.1 Structure de tables...................................................................................................... 39