Rapport de Stage Approvissionnement de Produits Pharmaceutique

REPUBLIQUE DU CAMEROUN REPUBLIC OF CAMEROON
Paix-travail-Patrie Peace-Work-Fatherland
INSTITUT AFRICAIN D’INFORMATIQUE CENAME

<<Centre d’Excellence Technologique Paul BIYA>> Siege social:2170 Messa,Yaoundé -
BP :13179 Yaoundé, Cameroun Cameroun
Tel :242 72 99 58/ 242 72 99 57 Tel:222 23 29 20/222 23 29 22
Site :www.iaicameroun.com Site:www.cename.cm
Email :contact@iaicameroun.com Email:contact@cename.cm
RAPPORT DE FIN DE STAGE
THEME : DIGITALISATION DU PROCESSUS

D’APPROVISSIONNEMENT EN PRODUITS
PHARMACEUTIQUE A LA CENAME
Stage effectué du 05 Juillet au 30 Septembre 2021 en vue de l’obtention du Diplôme

d’Ingénieur des Travaux Informatiques option Génie Logiciel.
Rédigé par : KRENNA Baiva Anicet Oumar

Étudiant(e) en 3eme année à l’IAI-Cameroun, Centre Yaoundé.
Encadreur académique : Encadreur professionnel :

ET
M. TCHAKOUTIO Ludovic M. TETANG Lancelot
Enseignant à l’IAI-CAMEROUN Ingénieur de conception en sécurité informatique
2020-2021
DIGITALISATION DU PROCESSUS D’APPROVISIONNEMENT EN
PRODUITS PHARMACEUTIQUE A LA CENAME
i
Rédigé par Krenna Baiva Anicet Oumar, Etudiant en 3eme Année Licence
IAI-CAMEROUN, CENTRE D’EXCELLENCE TECHNOLOGIQUE PAUL BIYA – 2020/2021
DEDICACE
A
LA FAMILLE
BAIVA
ii
REMERCIEMENTS
Notre reconnaissance va à l’endroit de tous ceux qui de près ou de loin ont contribué à
la réalisation de ce travail en particulier :
La réalisation d’une telle application, quel qu’en soi son site d’implémentation, reste en soi un
grand défi qui demande d’être relevé. En premier, nous aimerions remercier le bon Dieu, le
Tout Miséricordieux, le Très Miséricordieux pour nous avoir armé de courage et de volonté.
-M. Armand Claude ABANDA, Représentant Résident de l’IAI-Cameroun, Chef

d’Etablissement pour le cadre de formation qu’il nous a offert ;
- Dr. VANDI Deli, Directeur Général de la CENAME pour nous avoir permis d’effectuer un
stage dans son illustres structures ;
- M. TETANG Lancelot, Chef cellule informatique par intérim ainsi pour son suivie lors de
l’élaboration de notre projet ;
-. M.MBOUOBOUO Amidou, Informaticien a la CENAME pour ses directives qui nous ont
permis d’évolués dans le monde professionnel ;
- M. NDIMANTCHI Ayoba, Stagiaire professionnel a la CENAME pour ses conseils et pour

son expertise dans le travail ;
- M. TCHAKOUTIO Ludovic, Enseignant à l’IAI-CAMEROUN pour son encadrement et sa

rigueur dans le travail;
-M. BALEMAKEN Stéphane, Professeur titulaire de la GL3B pour son encadrement et ses
conseils avisé ;
-M. BAIVA Maladjen, mon père pour son soutien morale et financier ;
-M. ZOKOM Denise, pour ma mère pour son amour maternelle et ses conseils avises ;
-Tout le personnel administratif et enseignant du centre IAI-Garoua, pour leur soutien et leur
accompagnement, leurs conseils et la qualité de formation ;
- Tous nos promotionnaires, pour tous les moments passés ensemble et la passion partagée ;
- En fin, à tous ceux qui ont contribués de près ou de loin à l’aboutissement de ce travail ;
iii
SOMMAIRES
DEDICACE ................................................................................................................................ ii
REMERCIEMENTS ................................................................................................................. iii
SOMMAIRES ........................................................................................................................... iv
LISTE DES TABLEAUX ......................................................................................................... vi
LISTE DES FIGURES ............................................................................................................. vii
SIGLES ET ABBREVIATIONS ............................................................................................ viii
RESUME................................................................................................................................... ix
ABSTRACT ............................................................................................................................... x
INTRODUCTION GENERALE................................................................................................ 1
PARTIE 1: PHASE D’INSERTION .......................................................................................... 2
I. ACCEUIL ET INTEGRATION......................................................................................... 4
II. PRESENTATION DE LA CENAME................................................................................ 4
III. ORGANIGRAMME ET FONCTIONNEMENT............................................................... 6
PARTIE 2 :CAHIER DE CHARGES ........................................................................................ 9
I. CONTEXTE ET JUSTIFICATION DU PROJET ........................................................... 10
II. OBJECTIFS DU PROJET ............................................................................................... 10
III. EXPRESSION DES BESOINS ....................................................................................... 11
IV. ESTIMATION DU COUT DE PROJET ......................................................................... 11
V. PLANNIFICATION DU PROJET................................................................................... 14
VI. CONTRAINTES .............................................................................................................. 15
VII. LIVRABLES .................................................................................................................... 16
PARTIE 3 :DOSSIER D’ANALYSE ...................................................................................... 18
I. RECEUIL DE L’EXISTANT .......................................................................................... 20
II. PRESENTATION DE LA METHODE D’ANALYSE ................................................... 21
iv
III. DIAGRAMME D’ANALYSE ...................................................................................... 31
PARTIE 4 :DOSSIER DE CONCEPTION ............................................................................. 47
I. OBJECTIF DE LA CONCEPTION ................................................................................. 49
II. PLAN DU SITE ............................................................................................................... 49
III. DIAGRAMME DE CLASSE........................................................................................... 49
IV. DIAGRAMME D’ETAT-TRANSITION ........................................................................ 53
PARTIE 5 :DOSSIER DE REALISATION ............................................................................ 57
I. CHOIX DES TECHNOLOGIES ..................................................................................... 59
II. CYCLE DE DEVELOPPEMENT................................................................................... 60
III. PRESENTATION DES ARCHITECTURES .................................................................. 62
IV. DIAGRAMME DE DEPLOIEMENT ............................................................................. 64
PARTIE 6 : GUIDE D’INSTALLATION ET D’UTILISATION ........................................... 69
I. GUIDE D’INSTALLATION ........................................................................................... 71
II. GUIDE D’UTILISATION ............................................................................................... 73
CONCLUSION GENERALE .................................................................................................. 77
v
LISTE DES TABLEAUX
Tableau 1.Evaluation en ressource humaines : Mercuriale des prix 2020 .............................. 12

Tableau 2 Evaluation en ressources matérielles : Mercuriale des prix 2020 .......................... 12
Tableau 3 Evaluation logiciel : Mercuriale des prix 2020 ..................................................... 13
Tableau 4 Evaluation globale : source : Mercuriale des prix 2020 .......................................... 14
Tableau 5 Plannification du projet ........................................................................................... 14
Tableau 6 Formalisme du diagramme des cas d’utilisation. .................................................... 32
Tableau 7 Formalisme d'une description textuelle ................................................................... 36
Tableau 8 Description textuelle : commander_produit ............................................................ 37
Tableau 9 Description textuelle : choisir_transitaire................................................................ 38
Tableau 10 Formalisme du diagramme d’activité .................................................................... 39
Tableau 11 Formalisme d’un diagramme de séquence ............................................................ 42
Tableau 12 formalisme du diagramme de classe .................................................................... 50
Tableau 13 Tableau du formalisme du diagramme d'Etat-Transition ...................................... 53
Tableau 14 Choix des technologies .......................................................................................... 59
Tableau 15 Matériels ................................................................................................................ 60
Tableau 16 Formalisme du diagramme de déploiement .......................................................... 65
vi
LISTE DES FIGURES
Figure 1 Plan de localisation ...................................................................................................... 5

Figure 2 Organigramme de la CENAME ................................................................................... 7
Figure 3 Diagramme de Gantt .................................................................................................. 15
Figure 4 Processus 2TUP ......................................................................................................... 30
Figure 5 Diagramme de cas d’utilisation global ...................................................................... 34
Figure 6 Diagramme de cas d'utilisation commander produit ................................................. 35
Figure 7 Diagramme de cas d'utilisation Choisir transitaire .................................................... 35
Figure 8 Diagramme d'activité commander_produit ................................................................ 40
Figure 9 Diagramme d'activité :Choisir_transitaire ................................................................. 41
Figure 10 Diagramme de séquence d’authentification ............................................................. 44
Figure 11 Diagramme de séquence de commande ................................................................... 45
Figure 12 Plan du site ............................................................................................................... 49
Figure 13 Diagramme de classe de la solution ......................................................................... 53
Figure 14 Diagramme d'état-transition: Client ......................................................................... 55
Figure 15 Diagramme d’état-transition :Réceptionniste .......................................................... 55
Figure 16 Logo de PHP 7 ......................................................................................................... 59
Figure 17 Cycle en V ............................................................................................................... 61
Figure 18 Architecture MVC ................................................................................................... 63
Figure 19 Architecture 3-tier .................................................................................................... 64
Figure 20 Diagramme de déploiement de la solution .............................................................. 67
Figure 21 Logo de WampServer .............................................................................................. 71
Figure 22 Logo d'Apache ......................................................................................................... 72
Figure 23 Logo de MySql ........................................................................................................ 72
Figure 24 Logo de Workbench................................................................................................. 73
Figure 25 Logo de Google Chrome.......................................................................................... 73
Figure 26 Page d’authentification de SUPPLY........................................................................ 74
Figure 27 Page d’accueil de SUPPLY ..................................................................................... 74
Figure 28 Page d'administration des utilisateurs ...................................................................... 75
Figure 29 Page d'édition de l'utilisateur ................................................................................... 75
Figure 30 Formulaire de recherche de médicament ................................................................. 76
vii
SIGLES ET ABBREVIATIONS
• DAPS :Direction de l’approvisionnement et des programmes santé de la CENAME.

• 2TUP : Two Track Unified Process .
• DTS : Diplôme de Technicien Supérieur .
• IAI : Institut Africain d’Informatique .
• MVC: Model View Controller .
• OMG : Object Management Group .
• OOSE :Object Oriented Software Engineering.
• OMT : Object Modeling Technic .
• PHP : PHP Hypertext Processor .
• CENAME :Centrale Nationale d’Approvisionnement en Médicaments et
Consommables Médicaux Essentiels.
viii
RESUME
Le travail ici présenté dans le but de l’obtention du Diplôme d’Ingénieur des Travaux
Informatiques, consiste à concevoir une application web de digitalisation du processus
d’approvisionnement en produits pharmaceutiques à la CENAME.Il est donc question pour
nous de pouvoir effectuer les commandes clients, le suivie des clients et la gestion
documentaires des fichiers nécessaire au processus d’approvisionnement. Cette application
facilitera la gestion centralisée de ce processus d’approvisionnement. Nous avons utilisé
quelques outils à savoir : WAMP Server et Visual Code Studio Ce projet permettra à la
CENAME d’innover et d’avancer dans le projet de digitalisation de son système d’information.
Le présent document détaillera au lecteur toutes les étapes de mise sur pieds de ce projet , de la
phase d’insertion a la CENAME , jusqu’à la réalisation et le déploiement du projet.
ix
ABSTRACT
The work presented here for the purpose of obtaining the Diploma of Engineering
degree, is to create an application to digitalise the process of supply of medicament within the
CENAME.The purpose of this application will allow client to command medicament online,
the customer follow-up, and the document management of files for the process of supply. This
application will ease the central management of the process of supply at the CENAME.We use
some application to realise it such as : WAMP Server and Visual Code Studio. This project will
innovate the project of digitalisation of the information system of the CENAME.This report
will detail the steps of setting up of this project, from the insertion phase, until the realization
and the deployment of the project.
x
INTRODUCTION GENERALE
Les Technologies de l’Information et de la Communication ne cessent de se développer

au fil du temps, visant l’automatisation et l’optimisation des tâches effectuées par les Hommes.
Ayant un impact indéniable dans plusieurs secteurs d’activité, les TIC constituent un atout non
négligeable permettant aux entreprises et institutions d’avoir une plus-value sur leur rendement
quotidien. Ainsi pour bénéficier au mieux des avantages qu’offrent les TIC, les institutions
tendent de plus en plus à apporter des solutions informatiques aux problèmes auxquels elles
sont confrontées au quotidien. C’est dans cette optique que nous avons été admis pour un stage
académique d’une durée de trois (03) mois à la CENAME pendant lesquels nous devions
proposer une solution «Digitalisation Du Processus d’Approvisionnement en Produit
Pharmaceutique a la CENAME». Dans le but d’accomplir cette mission, nous avons effectué
de différentes tâches. Nous aborderons donc dans ce rapport les diverses tâches effectuées en
mettant l’accent dans un premier temps sur le contexte du projet et les objectifs que nous
voulons atteindre avec celui-ci, puis nous présenterons les différents documents projets
intervenants, à savoir les dossiers d’analyse, de conception, de réalisation et enfin des guides
d’installation et d’utilisation de la solution.
1
PARTIE 1: PHASE D’INSERTION
RESUME
Dans cette section nous parlerons de notre accueil ,notre insertion dans la structure afin de
débutés le stage académique ainsi que des observations effectués menées durant cette période
au sein de la CENAME.
PLAN
INTRODUCTION
I-ACCEUIL ET INTEGRATION
II-PRESENTATION DE LA CENAME
III-ORGANIGRAMME ET FONCTIONNEMENT
CONCLUSION
2
INTRODUCTION
Dans l’obtention d’un diplôme d’ingénieur des Travaux Informatiques option Génie
Logiciel il nous est offert un stage académique d’une durée de 3 mois au cours dans une
structure de la quel nous devons rédiger un rapport de stage. C’est pourquoi, il nous est soumis
une phase d’insertion facilitant l’insertion professionnel en entreprise .La phase d’insertion est
la période pendant laquelle le stagiaire se familiarise avec les locaux de l’entreprise. Elle
constitue un atout très important pour la suite du déroulement du stage car c’est grâce à elle que
le stagiaire définit ce qu’il apportera en surplus à l’entreprise. Pendant les deux semaines allant
du 5 juillet au 16 juillet 2021, nous avons pris connaissance de cette structure, son
fonctionnement ainsi que ses infrastructures matérielles, logicielles et réseaux.
3
I. ACCEUIL ET INTEGRATION
Le lundi 5 juillet 2021 à 8h00 a marqué notre entrée à la CENAME en tant que stagiaire
académique, nous avons été reçus par le Chef de la Cellule Informatique M. TETANG
Lancelot ,Ingénieur Systèmes, Réseaux et Sécurité informatique qui nous a mené vers le
responsable des stagiaires M. MBOUOBOUO Amidou qui s’est chargé de nous encadrer au
sein de la cellule informatique et de nous expliquer le fonctionnement de la CENAME. Pour
cela, maitriser les grandes lignes de l’insertion professionnelle est une nécessité c’est pourquoi
du 5 juillet au 17 juillet nous avons pris connaissance de cette structure, son fonctionnement ainsi
que ses infrastructures.
II. PRESENTATION DE LA CENAME
Historique
• 1996 : Projet doté de la Personnalité Juridique, issu de la Convention Tripartite de juin
1996 entre l’Etat du Cameroun, le Royaume de Belgique et l’Union Européenne.
• 2005 : La CENAME devient un Etablissement Public de forme particulière par le

décret N° 2009/252 du 30 juin 2005 du Président de la République.
• 2009 : Par le décret N° 2009/386 du 30 Novembre 2009, la CENAME devient

un établissement public administratif doté de la personnalité juridique et de l’autonomie
financière, placé sous la tutelle technique du MINSANTE et la tutelle financière du
MINFI.
Statut juridique et localisation

La CENAME est un établissement public administratif de forme particulière régie par
le décret n° 2005/252 du 30 juin 2005 portant création, organisation et fonctionnement de la
Centrale Nationale d'Approvisionnement en Médicaments et Consommables Médicaux
Essentiels.
Ce décret stipule que la CENAME est placée sous la tutelle technique du Ministre chargé
de la santé publique et sous la tutelle du Ministre chargé des finances. La CENAME est dotée
de la personnalité juridique et elle jouit de l'autonomie financière. Son siège social est situé à
4
Yaoundé a la Rue Rudolph Douala Manga Bell près de la trésorerie générale du

Cameroun, et des annexes peuvent être créées en tant que de besoin, sur délibération du Conseil
d'Administration.
Figure 1 Plan de localisation
Missions de la CENAME
La CENAME a pour mission générale de contribuer à la mise en œuvre de la politique
pharmaceutique nationale en matière d'approvisionnement en médicaments et dispositifs
médicaux essentiels.
De manière spécifique, elle est chargée :
➢ D’assurer la disponibilité, la permanence et l'accessibilité des médicaments ;
➢ Fournir les dispositifs médicaux essentiels sur toute l'étendue du territoire national ;
➢ De garantir la qualité des médicaments et dispositifs médicaux essentiel qu'elle distribue

conformément aux normes de qualité prescrites par la réglementation en vigueur ;
➢ De fournir les Centres d'Approvisionnement Pharmaceutiques Provinciaux en
Médicaments et dispositifs médicaux essentiels au meilleur rapport qualité/prix ;
5
➢ D’exécuter toute autre mission à elle confiée par les pouvoirs publics et se rapportant
à son objet social.
Il est par ailleurs précisé dans le décret n° 2005/252 du 30 juin 2005 que le Ministre chargé
de la santé publique peut, en cas d'urgence, autoriser des formations sanitaires du secteur public
ou des centrales d'achat à s'approvisionner directement auprès de la CENAME, moyennant le
respect d'un cahier de charges.
III. ORGANIGRAMME ET FONCTIONNEMENT
Présentation des directions

• Le Directeur Général : Sous le contrôle du conseil d’administration, le directeur
Général (DG) est chargé de l’application de la politique générale et de la gestion de la
centrale.
• Direction Administrative et financière : Assure la gestion des ressources matériel ;

humaine et financière de la CENAME.
• Direction des Approvisionnement des programmes de santé publique : Garanti

l’approvisionnement en produits pharmaceutiques de la CENAME.
• Direction des stocks, de la logistique et des ventes : Assure le stockage, la distribution

et la vente des produits pharmaceutique.
Organigramme de la CENAME
6
Figure 2 Organigramme de la CENAME
7
CONCLUSION
Au cours de cette phase d’insertion a la CENAME, nous avons eu un rapide aperçu de
son fonctionnement. Nous nous sommes familiarisés au monde professionnel et avons pris part
aux tâches de la cellule informatique. À la fin de cette période, un thème de stage nous a été
attribué, notamment « la digitalisation du processus d’approvisionnement en produits
pharmaceutique à la CENAME ». Au vue des besoins observées sur le terrain nous allons
mener des études approfondies afin de mieux cerner le thème c’est pourquoi il en ressort un
document appelez cahier de charge.
8
PARTIE 2 :CAHIER DE CHARGES
RESUME
Le cahier de charge est un document utilisé par le maitre de stage pour faire part au stagiaire
des attentes de l’entreprise. Il décrit également les règles de fonctionnement de l’entreprise au
stagiaire . Cette partie permet à l’étudiant de mieux prendre connaissance de son thème afin de
l’appréhender.
PLAN
INTRODUCTION
I- CONTEXTE ET JUSTIFICATION DU PROJET

II- OBJECTIFS DU PROJET
III- EXPRESSIONS DES BESOINS DE L’UTILISATEUR
IV- ESTIMATION DU COÛT DU PROJET
V- PLANIFICATION DU PROJET
VI- LES CONTRAINTES
VII. LES LIVRABLES
CONCLUSION
9
I. CONTEXTE ET JUSTIFICATION DU PROJET
Contexte du projet
Suite à un constat effectué dans la structure nous avons remarqués que
l’approvisionnement se faisait manuellement donc nous avons proposé une solution de
digitalisation du processus d’approvisionnement de la CENAME à travers la mise en place
d’une application permettant d’automatiser cette tâche et d’assurer la traçabilité du processus.
Justificatif
La CENAME fournit les centres d'approvisionnement pharmaceutiques en médicaments
et dispositifs médicaux essentiels au meilleur rapport qualité/prix .De ce fait, il traitre un grand
nombre de demande provenant des programmes santé, des particuliers et des organes de santé
.Afin de réduire la charge de travail et d’améliorer la performance de cette opération nous
proposons une solution de développement d’une application web de gestion de
l’approvisionnement en produit pharmaceutique a la CENAME.
II. OBJECTIFS DU PROJET
Afin de réaliser tout grand projet ,il est important de fixer des objectifs afin de le
diviser pour mieux le gérer.
Objectif général
Notre travail a pour but de développer une plateforme d’acquisition de produit
pharmaceutique en ligne ou en local afin d’automatiser cette tâche.
Objectif spécifique
Afin de mieux développer notre thème nous allons le subdiviser en objectifs à
savoir :
• Disposer d’une base d’information sur les activités des processus d’approvisionnement
et de distribution ;
10
• Permettre aux clients de commander en ligne et de générer les bons de commandes ;
• Permettre aux clients de consulter les documents signés tout au long du processus de
traitement des commandes ;
• Accroitre le niveau de traçabilité de toutes les opérations des dits processus ;
• Permettre à chaque acteur du processus d’accroitre sa performance et sa production ;
• Réduire les délais de traitement des commandes clients.
De ce fait, naitra une analyse approfondie de projet pour savoir les fonctionnalités de
l’application, et le moyen de déploiement de l’application.
III. EXPRESSION DES BESOINS
Les besoins fonctionnels

Pour satisfaire un plus grand nombre d’utilisateurs, la plateforme aura :
• Module d’inscription/authentification avec gestion des privilèges ;

• Module de gestion documentaire du processus d’approvisionnement: permet
d’envoyer /recevoir des documents signé nécessaire à l’approvisionnement ;
• Module de commande en ligne et suivi clientèle :permet à un client de passé une
commande en ligne et de la consulter à tout moment.
Les besoins non fonctionnels

Les besoins non fonctionnels expriment les contraintes qui n’ont pas trait au
comportement du système, mais plutôt à sa forme. Pour notre projet, ces contraintes sont :
• Une bonne ergonomie,
• La responsivité de l’application,
• La sécurité et la confidentialité des informations des utilisateurs.
IV. ESTIMATION DU COUT DE PROJET
1. Evaluation en ressources humaines
11
Tableau 1.Evaluation en ressource humaines : Mercuriale des prix 2020
DUREE SALAIRE
FONCTION NOMBRE TOTAL
(jours) MENSUEL
CHEF DU PROJET 96 1 350 000 F 33 600 000 F
ANALYSTE 31 1 250 000 F 7 750 000 F
CONCEPTEUR 20 1 250 000 F 5 000 000 F
PROGRAMMEUR 62 2 150 000 F 18 600 000 F
FRONT-END DESIGNER 14 1 150 000 F 2 100 000 F
67 050 000 F
2. Evaluation en ressources matérielles

Tableau 2 Evaluation en ressources matérielles : Mercuriale des prix 2020
DESIGNATION QUANTITE PRIX UNITAIRE TOTAL
Ordinateur de bureau
HP 1 320 000 F 320 000 F
PRODESK 600 G2
Serveur
569 250 F 569 250 F
DELL PowerEdge 1
T640
Antenne WIFI :
TPLINK TL- 56 350 F 56 350 F

1
ANT2414A
TOTAL : 945 600 F
Caractéristiques de l’ordinateur de bureau HP PRODESK 600 G2 :
• Processeur : Intel Core i5-6400

• Disque dur : 500 Giga
12
• RAM : 8 Giga DDR4
Caractéristiques du serveur DELL PowerEdgeT640 :
• Nombre de cœurs :8
• Taille de la mémoire vive :16 Go
• Nombre de ports VGA : 1
• Nombre de ports USB 2.0 : 3
Caractéristiques de l’antenne WIFI :TPLINK TL-ANT2414A :
• Nombre de cœurs : 1
• Type de technologie sans fil : 802.11b, 802.11g
Evaluation logicielle
Tableau 3 Evaluation logiciel : Mercuriale des prix 2020
PRIX
DESIGNATION QUANTITE TOTAL
UNITAIRE
Microsoft
Windows 10
Système d’exploitation
1 144 500 F 144 500 F
Professionnel
Microsoft 186 300

Suite bureautique 186 300 FCFA
Office 2016 1 FCFA
20 000
Logiciel de modélisation 20 000 FCFA
Power AMC 1 FCFA
Google
Navigateur 1 GRATUIT GRATUIT
Chrome
Visual Code
Editeur de texte 1 GRATUIT GRATUIT
Studio
WAMP
Plateforme de développement web 1 GRATUIT GRATUIT
Server
Logiciel de planification Gantt Project 1 GRATUIT GRATUIT

TOTAL : 350 800 F
13
Evaluation globale
Tableau 4 Evaluation globale : source : Mercuriale des prix 2020
DESIGNATION MONTANT
EVALUATION HUMAINE 67 050 000 F
EVALUTION MATERIELLE 945 600 F
EVALUATION LOGICIEL 350 800 F
Imprévus (fourchette de 10% sur le total) 6 834 640 F
TOTAL 75 181 040 FCFA
V. PLANNIFICATION DU PROJET
Conscient de l’importance de cet outil dans la réalisation de notre projet, et en accord
avec le cahier de charge, nous avons adopté le planning suivant qui s’étend sur une durée de 3
mois :
Tableau 5 Plannification du projet
ETAPE PERIODE
Analyse Du 5 Juillet au 17 Juillet
Conception 18 Juillet au 03 Aout
Réalisation 04 Aout au 10 Septembre
Rédaction du guide d'utilisateur 11 Septembre au 17 Septembre
Livraison du produit 18 Septembre au 30 Septembre
Ce planning peut être représenté par le diagramme de GANTT suivant :
14
Figure 3 Diagramme de Gantt
VI. CONTRAINTES
Les contraintes sont des obstacles qui peuvent subvenir aux avancements de notre projet.
Pour notre cas les contraintes peuvent être d’ordre naturel à savoir :
Contraintes de cout
La réalisation de notre projet nécessitera des dépenses en ressources humaines,
matérielles et logicielles pour un total de 75 181 040 FCFA.
Contraintes de délais
Notre projet devra être réalisé sur une durée de 3 mois, à savoir du 5 juillet 2021 au 30
Septembre 2021.
Contraintes de qualité
La réalisation de ce projet nécessite une grande attention de ce fait nous devons la réalisé
en 3 mois. La plateforme résultante de la réalisation de notre projet devra suivre les contraintes
de qualité suivante :
• Elle devra être robuste, c’est-à-dire devra fonctionner avec le moins d’erreurs
possible…
• Elle devra être évolutive, c’est-à-dire capable de s’adapter aux nouvelles demandes de
l’utilisateur.
15
• Elle devra être ergonomique, c’est-à-dire établir un bon contraste entre les besoins
fonctionnels et non fonctionnels de l’utilisateur, tout en gardant un équilibre entre les
performances.
• Elle devra être stable, c’est-à-dire fonctionné correctement sans bugs ni réaction
imprévues.
VII. LIVRABLES
Un livrable est un produit ou un service donné au client. Il peut s’agir de l’achèvement

d’un processus ou d’une tache, d’une partie du projet ou de l’aboutissement de la totalité. Ainsi
un projet peut avoir plusieurs livrables. Dans notre projet, nous aurons :
➢ Un dossier d’analyse
➢ Un dossier de conception
➢ Un dossier de réalisation
➢ Un dossier de test
➢ L’application sur un support amovible comme (clé USB ou disquette CD/DVD)
➢ Un guide d’utilisateur
➢ Un guide d’installation
16
CONCLUSION
L’élaboration d’un cahier des charges est une étape importante dans la conception d’une
solution informatique. Ce document nous a permis de mieux cadrer notre projet et de connaître
de manière exacte la route à suivre et les tâches à effectuer dans les délais prescrits.
17
PARTIE 3 :DOSSIER D’ANALYSE
RESUME
L’analyse est une étape importante dans tout projet informatique, quelle que soit sa taille.
Dans cette section nous parlerons de la méthode d’analyse choisie et des diagrammes qui
matérialisent la structure de notre projet.
PLAN
INTRODUCTION
I - RECEUIL DE L’EXISTANT
II - REPRESENTATION DE LA METHODE D’ANALYSE
III – DIAGRAMME D’ANALYSE
CONCLUSION
18
INTRODUCTION
De suite nous allons présenter le dossier d’analyse qui est une partie importante de notre
travail car elle permet de distinguer les différentes parties d’un problème, et d’en déterminer
des solutions en suivant une méthodologie définie, L’analyse de notre projet sera basée sur la
méthodologie UML, selon le processus 2TUP. Par-delà, ses outils nous tirerons les diagrammes
intervenants dans la phase d’analyse, à savoir les diagrammes de cas d’utilisation, les
diagrammes d’activité, et les diagrammes de séquence.
19
I. RECEUIL DE L’EXISTANT
Description de l’existant
Le programme envoie une lettre avec les quantités des produits à la direction générale
puis la direction acheté les produits sur une procédure légale de marché publique qui est un
appel d’offre sauf en cas exceptionnel on utilise un marché gré à gré puis l’appel d’offre est
envoyer à la commission interne de passation des marché de la CENAME et parfois à la
commission centrale de contrôle des marchée des approvisionnement généraux sous la
tutelle du MINMAP si le montant est supérieur ou égale à 250 millions émet un avis pour
publier ce dossier d’appel d’offre.
Si le montant est inférieur à 250 millions on continue la procédure ,les offres sont reçus
au secrétariat de la direction générale puis elle son analyse par la commission interne de
passation des marches qui formule une proposition d’attribution au maitre d’ouvrage qui est
le dg puis on attribue au différent fournisseurs un document appelé marché un document
contenant des clauses relative à l’exécution de ses marchés(délai livraison, garantie qualité,
causions de bon exécution, durée de vie des produits, stabilité des produits).15 jours avant
la livraison, la CENAME choisit son transitaire en mettant à sa disposition des document
d’expédition par le service de gestion des commandes et des transits on monte un dossier
réception à envoyer le directeur de la commission de réception qui convoque la
commission de réception afin de réceptionnéé les produits livre par le transitaire en présence
du comptable matière, le directeur de la commission de réception ou du directeur
d’approvisionnement du programme santé au cours de cette transaction est signé un
document appelez document de transitaire(numéro contenaire,nature du produit, adresse
de départ et de destination) archivé chez le chef de service de commande et chez le
comptable matière après la réception ,le rapporteur établi un procès-verbal de réception qui
est signé par tous les membres présents et est utilisé comme support pour l’entrée en stock
dans le logiciel SAGE .
Les programmes que la CENAME acheté sur la base des demandes qu’il adressent à la
CENAME et le transitaire est choisi en fonction du protocole d’accord et les produits
peuvent être à acheter soit par nous soit par l’agence d’approvisionnement on facture les
20
frais de gestion mais si l’achat est effectué à la CENAME le programme rembourse puis
ajoute les frais de gestions de 20%.
Critiques de l’existant
Suite au nombreuse requête d’approvisionnement en produit pharmaceutique ,une
procédure a été mise en place mais alors, cette procédure fait intervenir beaucoup d’acteur a
des moment différents. Ce qui augmente considérablement la charge de travail des employés
de la CENAME. De plus , la traçabilité de l’information est assez difficile donc il est compliqué
de retrouver qui a fait quoi ? à quel moment ?
Problématiques
Au vues de la critique de l’existent, comment réduire les délais de traitement des
commandes clients ? comment s’informé sur les activités des processus d’approvisionnement ?
Comment automatiser la gestion de l’approvisionnement en produit pharmaceutique a la
CENAME ?
Solution Apportée
Suite aux observations effectués ,nous proposons la réalisation d’une application web
nommer SUPPLY afin de satisfaire les besoins de la CENAME et de ses clients.
II. PRESENTATION DE LA METHODE D’ANALYSE

Pour notre analyse, nous avons choisi le langage UML (Unified Modeling Language)
avec lequel nous allons utilisez le processus 2TUP (Two Track Unified Process).
Présentation du langage UML
A. Présentation
UML signifie Unified Modeling Language, en français Langage de Modélisation

Unifié, « Unifié » car il regroupe les langages BOOCH, OMT, et OOSE. Il est utilisé en
développement logiciel, et en conception orientée objet. UML est à présent un standard défini
par l’Object Management Group (OMG). Officiellement UML est né en 1994.UML v2.0 date
de 2005. Il s'agit d'une version majeure apportant des innovations radicales et étendant
largement le champ d'application d'UML.
B. Objectifs de UML
21
Au milieu des années 90, les auteurs de Booch, OOSE et OMT ont décidé de créer un
langage de modélisation unifié avec pour objectifs :
Modéliser un système des concepts à l'exécutable, en utilisant les techniques orientée objet ;
• Réduire la complexité de la modélisation ;
• Utilisable par l'homme comme la machine :
• Représentations graphiques mais disposant de qualités formelles suffisantes pour être

traduites automatiquement en code source ;
Ces représentations ne disposent cependant pas de qualités formelles suffisantes pour justier
d'aussi bonnes propriétés mathématiques que des langages de spécification formelle.
C. Les avantages de UML
Comme avantages d’UML nous avons :
− UML est un langage formel et normalisé : Il permet le gain de précision, encourage

l'utilisation d'outils et constitue à cet effet un gage de stabilité.
− UML est un support de communication performant :Il cadre l'analyse et facilite la

compréhension de représentations abstraites complexes. Son caractère polyvalent et sa
souplesse en font un langage universel.
D. Comparaison entre UML et MERISE
MERISE est une méthode systémique d'analyse et de conception de systèmes

d'information. C'est-à-dire qu'elle utilise une approche systémique. La méthode MERISE
fournit un langage de modélisation graphique (MCD, MPD, MOT, MCT...) et une démarche à
adopter pour développent un logiciel.
MERISE propose de considérer le système réel selon deux points de vue:
- Une vue statique (données)
- Une vue dynamique (traitements).
22
C'est-à-dire qu'avec la méthode MERISE, nous avons une étude séparée des données et
des traitements.
Tandis que ,UML propose une approche différente de celle de MERISE en ce sens qu'il
associe les données et les traitements.
Car avec UML, centraliser les données d'un type et les traitements associés permet de limiter
les points de maintenance dans le code et facilite l'accès à l'information en cas d'évolution du
logiciel. De plus, UML décrit la dynamique du système d'information comme un ensemble
d'opérations attachées aux objets du système.
UML n'est cependant pas une méthode mais plutôt un langage de modélisation objet à qui
il faut associer une démarche pour en faire une méthode. c'est le cas de la méthode 2TUP ; RUT
et XP.
UML n'est qu'un langage ,Il spécifie comment décrire des cas d'utilisation, des classes, des
interactions Mais ne préjuge pas de la démarche employée.
E. Utilité
UML est utilisé pour spécifier, visualiser, modifier et construire les documents nécessaires
au bon développement d’un logiciel orienté objet. UML offre un standard de modélisation, pour
représenter l’architecture logicielle.
Grâce aux outils de modélisation UML, il est également possible de générer automatiquement
une partie de code, par exemple en langage Java, à partir des divers documents réalisés.
F. Formalisme
UML se décompose en plusieurs sous-ensembles :
• Les vues : Les vues sont les observables du système. Elles décrivent le système d’un point de
vue donné, qui peut être organisationnel, dynamique, temporel, architectural, géographique,
logique, etc. En combinant toutes ces vues, il est possible de définir (ou retrouver) le système
complet.
• Les diagrammes : Les diagrammes sont des éléments graphiques. Ceux-ci décrivent le
contenu des vues, qui sont des notions abstraites. Les diagrammes peuvent faire partie de
plusieurs vues.
23
• Les modèles d’élément : Les modèles d’élément sont les briques des diagrammes
UML, ces modèles sont utilisés dans plusieurs types de diagrammes à l’exemple des cas
d’utilisation, des classes, des associations, etc.
G. Les vues d’UML
Les différentes vues d’UML sont :
• Vue des cas d’utilisation : C’est la description du modèle vu par les acteurs du système. Elle
correspond aux besoins attendus par chaque acteur (c’est le QUOI et le QUI).
• Vue logique : C’est la définition du système vu de l’intérieur. Elle explique comment peuvent
être satisfaits les besoins des acteurs (c’est le COMMENT).
• Vue d’implémentation : Cette vue définit les dépendances entre les modules.
• Vue des processus : C’est la vue temporelle et technique, qui met en œuvre les notions de
tâches concurrentes, stimuli, contrôle, synchronisation, etc.
H. Les diagrammes d’UML
Les 13 diagrammes UML 2.1 sont dépendants hiérarchiquement et se complètent, de façon

à permettre la modélisation d’un projet tout au long de son cycle de vie.
• Diagrammes structurels ou statiques : Les diagrammes structurels ou statiques

rassemblent :
− Diagramme de classes : il représente les classes intervenant dans le système.
− Diagramme d'objets: il sert à représenter les instances de classes (objets) utilisées dans
le système.
− Diagramme de composants : il permet de montrer les composants du système d'un

point de vue physique, tels qu'ils sont mis en œuvre (fichiers, bibliothèques, bases de
données…)
− Diagramme des paquetages: un paquetage étant un conteneur logique permettant de

regrouper et d'organiser les éléments dans le modèle UML, le diagramme de paquetage
24
sert à représenter les dépendances entre paquetages, c’est-à-dire les dépendances entre
ensembles de définitions.
• Diagrammes comportementaux : Les diagrammes comportementaux rassemblent :
− Diagramme des cas d'utilisation: il permet d'identifier les possibilités d'interaction

entre le système et les acteurs (intervenants extérieurs au système), c'est-à-dire toutes
les fonctionnalités que doit fournir le système.
− Diagramme états-transitions: permet de décrire sous forme de machine à états finis le

comportement du système ou de ses composants.
− Diagramme d'activité: permet de décrire sous forme de flux ou d'enchaînement

d'activités le comportement du système ou de ses composants.
• Diagrammes d’interaction ou dynamiques : Les diagrammes d’interaction ou dynamiques

rassemblent :
− Diagramme de séquence: représentation séquentielle du déroulement des traitements

et des interactions entre les éléments du système et/ou de ses acteurs.
− Diagramme de communication : représentation simplifiée d'un diagramme de

séquence se concentrant sur les échanges de messages entre les objets.
− Diagramme global d'interaction: permet de décrire les enchaînements possibles entre

les scénarios préalablement identifiés sous forme de diagrammes de séquences.
− Diagramme de temps : permet de décrire les variations d'une donnée au cours du

temps.
I. Les méthodes orientées objet d’UML
Une méthode est un guide plus ou moins formalisé. Elle est constituée d’un ensemble
de concepts de modélisations qui sont mis en oeuvre en suivant une succession chronologique
d’activité et en respectant un ensemble de règles.
i. Processus Unifié (Unified Process)
La méthode de Processus Unifié (UP) s’intéresse au cycle de vie d’un logiciel et le gère.
En ce qui concerne les logiciels orientés objet, elle se concentrera sur son développement. Quant
à elle, est une des émanations de la méthode PU, qui s’attache à donner un cadre précis au
25
développement du logiciel. C’est une méthode générique, itérative et incrémentale assez

lourde mais qui s’adapte très facilement aux processus et aux besoins du développement.
Il s’agit d’un processus de développement de logiciels construit autour d’UML.Les activités de

développement autour de ce processus sont énumérées comme suit :
(1) capture des besoins des utilisateurs,
(2) analyse des besoins,
(3) conception des solutions,
(4) implémentation des solutions par des outils informatiques,
(5) mise en œuvre (codage, tests, etc.).
Le processus unifié se caractérise par ce qui suit :
• Orienté utilisateur : il répond aux besoins métiers à travers les cas d’utilisation (use
cases). Le cas contraire est de développer un système générique qui ne tient pas compte ni des
spécificités de l’entreprise ni des besoins des utilisateurs.
• Centré sur l’architecture: c'est-à-dire il prend en compte l'architecture de l’entreprise
(deux-tiers, trois-tiers, multi-tiers).
• Incrémental : il permet d’élaborer des résultats intermédiaires qui peuvent être évalués
par rapports aux spécifications et donc de maitriser les risques, les coûts et les délais.
Le cas contraire est de développer un système comme un seul bloc indivisible.
• Piloté par les risques : il permet de prendre en compte les besoins des utilisateurs et
les spécificités et contraintes de mise en œuvre.
• Orienté modèle : à travers les étapes du processus, les diagrammes UML sont utilisés
(classes, cas d'utilisation, ...) afin de capturer les besoins ou de concevoir le système.
• Permet la réutilisation car centré sur le développement de composants réutilisables.
26
ii. La méthode RUP (Rational Unified Process)
Le développement d’un logiciel se fait bien souvent de manière itérative jusqu’à conduire
à des livrables incrémentaux du système. Cette méthode va alors servir à canaliser et à organiser
la modélisation de la partie développement. Il est très important que la méthode soit bien
appréhendée par le chef de projet. En effet, au-delà de l’aspect théorique, c’est la mise en œuvre
de la méthode RUP qui est intéressante pour la qualité du travail.
Les plus de la méthode RUP, ce sont ses revues fréquentes avec toutes les parties prenantes: le
produit est ainsi construit en sécurité. Chaque itération est considérée comme un livrables et
l’on peut revenir sur les phases précédentes et réadapter le logiciel. Le retour utilisateur prend
une grande place dans la construction.
En effet, cette méthode propose de se concentrer sur quatre phases d’évolution. Ils sont
découpés en cycles.
• La création – évaluation des risques, architecture, planification,
• L’élaboration – spécification du besoin, validation, environnement projet,
• La construction – production du logiciel et de la documentation support, tests,
• La transition – test système et utilisateur, correction, déploiement.
À l’intérieur de ces phases, sont dispatchées toutes les activités du projet, en détail. Ainsi, la
méthode RUP propose d’élaborer un tableau itératif regroupant tous les points mentionnés ci-
dessus.
Tout d’abord, la structure que nous venons de voir, permet de s’assurer de toujours répondre
aux besoins des clients en temps et en heure. Ainsi les livrables sont gérés et contrôlés, tout au
long du développement. De plus, la méthode RUP, permet d’utiliser une architecture qui est
basée sur les composants. Ce qui est vraiment un plus, au niveau du fonctionnement, pour ce
type de travail en projet.
iii. La méthode XP
Bien connue dans le milieu informatique, la méthode agile XP, pour « Extreme
Programming », est tout aussi répandue que sa sœur, la méthode Scrum. Essayons de voir plus
précisément en quoi consiste cette méthode de gestion de projet.
27
La méthode agile XP est issue d’un projet de la société Chrysler, qui au milieu des années
90, a souhaité remettre totalement à jour son système de paie, en s’attaquant donc à des
fonctionnalités touchant près de 10 000 salariés. Le principe consiste à identifier les facteurs
déterminants d’un projet et à se concentrer dessus à l’extrême lors de la phase itératives de
développement et de tests.
La première étape de la méthode agile XP consiste à définir les spécifications. Mais

plutôt que de spécifier tout le projet dès le début, on va se concentrer sur les fonctionnalités les
plus importantes. Cela demande naturellement de l’expérience et une analyse assez fine du
besoin. Le projet va alors être découpé en modules et sous-modules. Les développements vont
avoir lieu lors d’itérations pouvant avoir une durée de deux à cinq semaines maximum.
Généralement, trois semaines est un bon choix. Une livraison est effectuée à l’issue de chaque
itération et elle est testée. Si les tests sont concluants, on passe à l’itération suivante, sinon,
l’itération recommence.
Le suivi du projet se fait au fur et à mesure de l’avancement des itérations, ce qui permet de
rapidement mettre en évidence les problèmes éventuels et de pouvoir prendre en compte de
nouvelles demandes du client.
Un certain nombre de règles doit s’appliquer systématiquement aux développements réalisés

dans le cadre de la méthode agile XP :
• La relecture du code doit être faite systématiquement.
• L’amélioration du code est faite tout au long de l’avancement des itérations.
• Les modifications sont publiées souvent de façon à permettre à tous d’avancer

rapidement.
• La solution la plus simple est toujours privilégiée.
• Les termes utilisés doivent être parfaitement définis de façon à ce que la compréhension
du projet soit la même pour tous les intervenants.
• Les tests doivent être systématiques, complets, et réalisés à la fin de chaque étape.
L’application de ces règles va permettre au fur et à mesure de l’avancement du projet de mettre

en place des bonnes pratiques de développement, de permettre un apprentissage et une montée
en compétences rapides, et au final de mettre en place un processus d’amélioration continue.
28
Chaque développeur va travailler avec un binôme. Chacun va alternativement

écrire le code et le contrôler. Ainsi, pendant que l’un développe, l’autre contrôle en temps réel
que le code est correct, qu’il répond bien aux normes de la méthode agile XP… La relecture du
code se fait donc en temps réel, et son amélioration est continue. Il faut donc que les
développeurs qui vont travailler ensemble soient capables d’accepter le changement et les
critiques, de façon à améliorer la qualité du code produit.
Processus 2TUP
A. Présentation
2TUP est un processus unifié qui a pour but d’apporter une réponse aux contraintes de
changement fonctionnelles et techniques qui s’imposent aux systèmes d’information, il propose
un cycle de développement qui dissocie les aspects techniques des aspects fonctionnels. Il
distingue ainsi deux branches (fonctionnelle et technique) dont les résultats sont fusionnés pour
réaliser le système. On obtient un processus de développement en Y. Il faut noter que le
processus 2TUP commence d’abord par une étude préliminaire, il s’agit d’identifier les acteurs
et le système, puis à produire un cahier des charges et enfin à modéliser le contexte.
Le 2TUP met en action le langage UML tout au long d’un processus en Y qui sépare
initialement les aspects fonctionnels d’un système des aspect opérationnels pour les unir par la
suite.
29
Figure 4 Processus 2TUP
B. La branche fonctionnelle
Les étapes de la branche fonctionnelle se présentent comme suit :
• La capture des besoins fonctionnels : Elle produit le modèle des besoins focalisés sur le métier
des utilisateurs. Elle permet de visualiser au plus tôt le risque de produire un système inadapté aux
utilisateurs. Cette phase a pour objectif de définir :
•La frontière fonctionnelle : entre le système considéré comme une boîte noire et son
environnement, c’est le niveau contextuel ;
Les activités attendues des différents utilisateurs par rapport au système toujours envisagées comme
une boîte noire, c’est le niveau cas d’utilisation.
• L’étape d’analyse : Elle consiste à étudier précisément les spécifications fonctionnelles de

manière à obtenir une idée de ce que va réaliser le système en termes de métier.
C. La branche technique
Les étapes de la branche technique se présentent comme suit :
30
L’étape de capture des besoins techniques : Recense toutes les contraintes sur les choix de
dimensionnement et la conception du système, les outils et le matériel sélectionné ainsi que la
prise en compte des contraintes d’intégration avec l’existant (pré requis d’architecture
technique). Cette étape permet de définir le modèle d’analyse technique.
L’étape de conception générique : Définis ensuite les composants nécessaires à la

construction de l’architecture technique. Cette conception est complètement indépendante des
aspects fonctionnels. Elle permet de générer le modèle de conception technique ou design.
D. La phase de réalisation
La phase de réalisation consiste à réunir les deux branches, permettant de mener une
conception applicative et enfin la livraison d’une solution adaptée aux besoins.
III. DIAGRAMME D’ANALYSE
Le diagramme de cas d’utilisation
A. Définition
Un diagramme de cas d’utilisation capture le comportement d’un système. Son rôle est
de recueillir, d’analyser et d’organiser les besoins, ainsi que de recenser les grandes
fonctionnalités d’un système, en représentant de manière graphique toutes les actions possibles
d’un acteur dans ce dernier. Il s’agit donc de la première étape UML pour l’analyse d’un
système. Ainsi dans ce diagramme de cas d’utilisation, nous avons des acteurs et leurs actions,
y compris les flèches associatives qui sont d’une part en trait fin et d’autre part en trait
interrompu.
B. Formalisme
Un diagramme de cas d’utilisation se compose des principaux éléments énumérés

dans le tableau suivant :
31
Tableau 6 Formalisme du diagramme des cas d’utilisation.
REPRESENTATION LIBELLE DESCRIPTION
Acteur Un acteur est un élément

externe qui joue un rôle dans
le système. Le rôle joué est
considéré comme un cas
d’utilisation.
Système Le système représente

l’espace étudié. C’est dans
celui-ci que l’acteur effectue
ses actions, par conséquent
c’est dans ce dernier que se
trouvent les cas d’utilisation.
Il est représenté par un cadre,
avec le nom du système.
Cas d’utilisation Il représente une
fonctionnalité fournie par le
système. Il est décrit sous la
forme verbe (infinitif) +
objet. Il correspond à un
objectif du système motivé
par un besoin d’un ou
plusieurs utilisateurs.
L’ensemble des cas
d’utilisation décrit le but du
système. Le cas d’utilisation
est représenté par une ellipse
contenant son nom.
32
Association Les associations sont

utilisées pour lier les acteurs
avec les cas d’utilisation.
Elles indiquent qu’un acteur
participe au cas d’utilisation
sous une forme quelconque.
Les associations sont
représentées par une ligne
reliant l’acteur au cas
d’utilisation.
Relation Les relations sont utilisées
pour lier les cas d’utilisation
entre eux. Elles permettent de
définir quel cas d’utilisation
dépend de l’autre (relation
<<include>> ou
d’inclusion) ou encore quel
cas d’utilisation est une
possibilité étendue d’un autre
(relation <<extend>> ou
d’extension). Les relations
sont représentées par une
flèche à trait interrompu
allant d’un cas d’utilisation à
un autre.
Généralisation La généralisation est utilisée
pour lier les acteurs entre
eux. Elles permettent de dire
qu’un acteur effectue tous les
cas d’utilisation d’un autre en
plus de ce qu’il peut faire.
Cette relation est aussi
appelée relation d’héritage.
33
Les généralisations sont

représentées par une flèche
allant d’un acteur (celui qui
hérite) à un autre.
A. Diagramme des cas d’utilisation global
Figure 5 Diagramme de cas d’utilisation global
Notre système est constitué de trois acteurs qui ont chacun des tâches bien précises. Avant
d’effectuer une action sur le système, les acteurs doivent d’abord s’authentifier pour besoin de
sécurité et de confidentialité des archives. Une fois authentifié les acteurs peuvent effectuer les
tâches suivantes :
• Client
• Employé
• Administrateur
34
B. Diagramme des cas d’utilisation commander
Figure 6 Diagramme de cas d'utilisation commander produit
C. Diagramme des cas d’utilisation choisir transitaire
Figure 7 Diagramme de cas d'utilisation Choisir transitaire
35
Dans cette étape nous avons deux types de diagramme à savoir le diagramme de
classe et le diagramme de séquence.
Le diagramme de classe est un schéma utilisé en Génie Logiciel pour présenter les
classes et les interfaces des systèmes ainsi que des différentes relations entre celle-ci. Ce
diagramme se trouve dans la partie statique d’UML, car il fait abstraction des aspects temporels
et dynamiques.
Dans un diagramme de classe, nous avons des carrés qui représenter dans le premier
blog l’entité, le deuxième blog est l’ensemble des attributs qui décrivent les entités et enfin le
troisième blog représente les opérations qui sont des fonctions qui peuvent prendre des valeurs
en entrée et modifier des attributs ou produire des résultats. Les différentes classes sont reliées
par des associations qui comportent des cardinalités qui servent à compter le nombre minimum
et maximum de possibilité que chaque classe contient dans la relation liant deux ou plusieurs
objets.
Description textuelle
UML permet de décrire l’exécution d’un cas d’utilisation de manière textuelle, sous une
forme appelée scénario nominal. Un scénario nominal décrit de manière plus détaillée
l’exécution d’un cas d’utilisation par un acteur jusqu’à ce qu’il soit entièrement réalisé avec
succès.
A. Formalisme
Une description textuelle d’un cas d’utilisation est représentée sous la forme qui suit :
Tableau 7 Formalisme d'une description textuelle
NOM DU CAS D’UTILISATION
Acteur Acteur concerné dans le cas d’utilisation
Présupposé Ensemble des actions qui doivent être remplies avant le lancement du
cas d’utilisation
Précondition Ensemble des conditions qui doivent être remplies avant le lancement
du cas d’utilisation
36
Déclencheur Élément qui déclenche le cas d’utilisation
Dialogue Description du scénario nominal
Scénarii alternatifs Descriptions des scénarii alternatifs (cas où le scénario nominal est
un échec)
Post condition Ensemble des mécanismes pouvant conduire à la fin du cas

d’utilisation
B. Description textuelle :Commander_produit
Tableau 8 Description textuelle : commander_produit
COMMANDER_PRODUIT
Acteur Client
Présupposé Disposé d’un ordinateur connecté au réseau de la CENAME.
Précondition Le système fonctionne correctement
Déclencheur Choisir des médicaments et appuyés sur envoyer
Dialogue
1- Le système affiche le formulaire de recherche de médicament
2- L’utilisateur renseigne le ou les noms des médicaments
3- Le programme envoie une requête afin de rechercher dans la base
de données les noms des médicaments
4-Le programme affiche les noms des médicaments disponibles a
commandé
5-L’utilisateur sélectionne les médicaments et valide sa commande
Scénarii alternatifs 1- Si à l’étape 3 le médicament n’existe pas dans la base de données

le programme renvoie aucun résultat
37
2- Si à l’étape 5 l’utilisateur valide sa commande sans avoir

sélectionner de médicament le programme renvoie une erreur.
Post condition Le Client renseigne le nom d’un médicament correct ,le sélectionne
et clique sur envoyer
A. Description textuelle :Choisir_transitaire
Tableau 9 Description textuelle : choisir_transitaire
CHOISIR TRANSITAIRE
Acteur Réceptionniste
Présupposé Disposé d’un ordinateur connecté au réseau de la CENAME.
Précondition Le système fonctionne correctement
Déclencheur Choisit un transitaire afin d’acheminer les produits
Dialogue
1- Le système affiche une liste des transitaires
2- Le réceptionniste sélectionne le transitaire pour une commande
3- Le programme enregistre le transitaire et sa commande
4- Le réceptionniste valide la procédure
Scenarii alternatifs
1- Si à l’étape 2 le réceptionniste ne sélectionne pas de transitaire
pour une commande le programme affiche une erreur.
Post condition Le réceptionniste sélectionne un transitaire et valide la procédure
Le diagramme d’activité
A. Définition
Un diagramme d’activité est utilisé pour documenter le déroulement des opérations dans
un système. Un diagramme d’activité est une variante du diagramme d’état transition, mais ici
les états représentent les opérations et les transitions sont des activités qui se produisent quand
l’opération est terminée.
38
B. Formalisme
Les éléments constitutifs d’un diagramme d’activité sont :
Tableau 10 Formalisme du diagramme d’activité
État initial L’état initial marque le point

d’entrée de la première
activité. Il est représenté par
un cercle plein, et il ne peut
y avoir qu’un seul état initial
dans un diagramme
d’activité.
Transition Quand une activité est

accomplie, le traitement
passe à une autre activité.
Les transitions sont utilisées
pour marquer ce passage.
Elle matérialisée par une
flèche portant en dessus le
nom de l’événement.
Activité L’activité marque une action

faite par un objet. Elle est
représentée par un rectangle
aux coins arrondis contenant
le nom de l’activité.
Décision Les décisions sont utilisées

pour marquer dans un
diagramme d’activité le fait
qu’un objet fait un choix
suite à un traitement. Ce
choix détermine la transition
à suivre vers la prochaine
activité.
39
Couloir Le diagramme d’activité fait

intervenir les acteurs et les
objets de chaque activité. Ici,
on place chaque activité dans
une colonne qui correspond à
l’acteur/objet : c’est le
couloir. Les objets/acteurs
sont énumérés au-dessus de
la colonne, et les barres
verticales séparent les
colonnes pour former les
couloirs. Un couloir est
matérialisé par une droite
verticale.
État final Il marque la fin du

déroulement des opérations
modélisées. On peut avoir
plusieurs états finaux dans
un diagramme d’activité.
C. Diagramme d’activité :Commander_produit
Figure 8 Diagramme d'activité commander_produit
40
D. Diagramme d’activité :Choisir transitaire
Figure 9 Diagramme d'activité :Choisir_transitaire
Le diagramme de séquence
A. Définition
Les diagrammes de séquences sont les représentations graphiques des interactions entre
les acteurs et le système selon un ordre chronologique dans la formulation Unified Modeling
Language. En effet elles permettent de décrire comment les éléments du système interagissent
entre eux et avec le système, les objets qui sont au cœur du système interagissent en s’échangent
des messages.
Ainsi, la communication s’effectue via les lignes de vie ou circulent les différents
messages entre les acteurs et le système.
B. Formalisme
41
Tableau 11 Formalisme d’un diagramme de séquence
Ligne de vie d’un acteur Une ligne de vie représente

l’ensemble des opérations
exécutées par un objet.
Ligne de vie d’un objet
Activation Indique que l’objet effectue

une action.
Message récursif C’est lorsqu’un objet ou un

acteur s’auto-envoie un
message.
42
L’opérateur Alt Il correspond à une

instruction de test avec une
ou plusieurs alternatives
possibles. Il permet aussi
d’utiliser les clauses du type
« sinon ».
Message de retour Réponse d’un objet suite à

un message. Il marque la fin
d’une activation.
Message synchrone L’envoi d’un message

synchrone met en attente le
déroulement de l’activation
jusqu’à la réception d’une
réponse provenant de
l’objet/ l’acteur à qui le
message a été envoyé.
Message asynchrone Contrairement au message

synchrone, l’envoi d’un
message asynchrone ne met
pas en attente le
déroulement de l’activation
jusqu’au message de retour.
A. Diagramme de séquence d’authentification
Ici, nous allons décrire brièvement le processus d’authentification a l’aide du diagramme

ci-dessous.
43
Authentification
Serveur d'application Serveur de base de donnees
Utilisateur
1: Demarrer l'application
2: Affiche le formulaire d'

authentification
3: Renseigner informations
4: Verification_information
5: Envoie de la requete
6: Execution de la requete
7: Envoie de la reponse
8: Traitement de la reponse
alt Utilisateur trouver

9: Envoi d'un message de succes
10: Affichage de l'interface utilisateur
Aucun utilisateur trouver

11: Envoie d'un message d'erreur
12: Affichage du formulaire d'

authentification
Figure 10 Diagramme de séquence d’authentification
B. Diagramme de séquence de commande
La commande étant le module principale de l’application SUPPLY,le représenté

par un diagramme de séquence seras plus simple.
44
Commander
Serveur d'application Serveur de base de donnee
Client
ref
Authentification()
1: Clique sur commander
2: Renvoie le formulaire d'ajout de

medicament
3: Renseigne le formulaire
4: Verification des informations
alt Choix valide 5: Envoy de la requete d'ajout de

medicament a la commande
6: Execution de la requete
7: Envoie de la reponse
8: Envoie d'un message de succes
Choix invalide
9: Envoie d'un message d'erreur
10: Renvoie le formulaire d'ajout de
medicament
Figure 11 Diagramme de séquence de commande
45
CONCLUSION
Suite à un dossier d’analyse aboutie nous allons passer au dossier de conception enfin
de mieux aborder notre thème .Afin de concrétiser les résultats obtenus lors de l’analyse pour
commencer la réalisation de notre projet.
46
PARTIE 4 :DOSSIER DE CONCEPTION
RESUME
Le dossier de conception vient concrétiser les résultats obtenus lors de l’analyse. Dans
cette section nous parlerons des objectifs de ce document, et des diagrammes y intervenant.
PLAN
INTRODUCTION
I- PLAN DE L’APLLICATION
II- DIAGRAMME DE CLASSE
III- DIAGRAMME D’ETAT-TRANSITION
CONCLUSION
47
INTRODUCTION
La conception est l’étape principale dans laquelle on entre dans la phase de
développement de la solution. Pendant celle-ci, il s’agira pour nous d’établir les diagrammes
concernés par ce dossier, à savoir celui de classe et celui d’état transition, pour ainsi
implémenter les parties essentielles de notre solution telle que la base de données. cette partie
permet de décrire très simplement le fonctionnement du futur système pour en faciliter sa
réalisation.
48
I. OBJECTIF DE LA CONCEPTION
La conception a pour objectif de permettre de formaliser les étapes préliminaires du

développement d’un système afin de rendre son développement plus fidèle aux besoins du
client. Pour ce faire tout à bord on est parti d’un énoncé informel (tels que les futurs utilisateurs
du logiciel l’on spécifié) ainsi que l’étude et l’analyse de l’existant, la conception sera donc
définie comme la description de l’objet à développer selon une vue interne, cette partie permet
de décrire très simplement le fonctionnement du futur système pour en faciliter sa réalisation.
II. PLAN DU SITE
Notre application sera structurée comme suite :
Authentication Inscription
Accueil Tableau de board
Commande Document Programme santé
Figure 12 Plan du site
III. DIAGRAMME DE CLASSE
Définition
Le diagramme de classe exprime la structure statique du système en termes de classes
et des relations entre ces classes. L’intérêt de ce diagramme est de modéliser les entités du
système d’informations et de représenter l’ensemble des informations qui sont gérées par le
domaine, ces informations étant structurées et regroupées dans des classes.
Formalisme
Un diagramme de classe se compose des différents éléments listés dans le tableau suivant :
49
Tableau 12 formalisme du diagramme de classe
Classe Une classe est la

représentation abstraite
d’une réalité, définissant ses
caractéristiques (attributs et
méthodes). Elle se représente
en UML sous forme d’un
rectangle divisé en trois
sections. La première
contient le nom de la classe,
la seconde partie contient les
attributs de la classe qui sont
typés, et la troisième partie
contient les opérations
(méthodes ou
comportements).
nom Attribut : Type Attribut Un attribut représente une

information élémentaire dans
une classe. Il est représenté
par son niveau d’accessibilité
(+ pour public, - pour
private, # pour protected),
suivi de son nom et de son
type.
nom Méthode() : Type Méthode Une méthode représente un

élément de comportement
des objets défini de manière
globale dans la classe. Elle
est représentée par son
niveau d’accessibilité (+ pour
50
public, - pour private, # pour

protected), suivi de son nom
et de son type de retour.
Association Une association représente

une relation structurelle entre
une ou plusieurs classes. La
plupart des associations sont
binaires, c’est-à-dire liant
deux classes. On représente
une association en traçant
une
Agrégation Elle représente une

association non générique
dans laquelle une des
extrémités joue le rôle
prépondérant par rapport à
l’autre. Une agrégation est
matérialisée entre deux
classes spécifiant que les
objets d’une classe sont des
composants de l’autre. Cette
relation est représentée par
un trait ayant à l’une de ses
extrémités un losange du côté
de l’agrégat.
trait interrompu allant d’un
cas d’utilisation à un autre.
51
Composition C’est un cas particulier de

l’agrégation, dans lequel la
vie des composants est liée à
celle des agrégats. Dans le
cas de la composition,
l’agrégat ne peut être
multiple. La destruction de
l’agrégat entraine
directement la destruction
des composants. Cette
relation est représentée par
un trait ayant à l’une de ses
extrémités un losange rempli
du côté de l’agrégat.
Diagramme de classe de la solution
a) Représentation
52
Figure 13 Diagramme de classe de la solution
b) Relation entre les classes
Tableau 13 Description des relations entre les classes
Relations Description
R1 Un utilisateur choisit au moins un transitaire
R2 Un magasin peut contenir au mins un produit pharmaceutique
R3 Ensemble des conditions qui doivent être remplies avant le lancement

du cas d’utilisation
R4 Plusieurs produits peuvent être transporter par plusieurs transitaires
R5 Au moins un fournisseur peut commander plusieurs produit

pharmaceutiques
R6 Un utilisateur peut souscrire à un programme santé
IV. DIAGRAMME D’ETAT-TRANSITION
Définition
Le diagramme d’état transition exprime tous les états possibles d’un objet. Il indique en
quoi ces changements d’état sont induits par des événements. Le diagramme d’état transition
exprime les changements d’état d’un seul objet dans l’ensemble des cas d’utilisation. C’est par
conséquent une vue synthétique du fonctionnement dynamique d’un objet à travers tout le
système.
Formalisme
Un diagramme d’état transition est constitué des différents éléments listés dans le
tableau suivant :
Tableau 14 Tableau du formalisme du diagramme d'Etat-Transition
53
État initial C’est l’état de départ d’un

objet avant toute transition.
Transition Une transition décrit le

changement d’état d’un
objet. C’est une relation entre
deux états représentés par
une flèche orientée sur
laquelle est annoté
l’événement qui concourt au
changement d’état.
État Il correspond à une situation

durable dans laquelle se
trouvent les objets d’une
classe. Il est représenté par un
rectangle aux coins arrondis
contenant le nom de l’état.
État final Il représente la destruction de

l’objet que l’on modélise. Cet
état est représenté par un
cercle plein entouré d’un
autre cercle.
Diagramme d’état-transition :Client
54
[Creation par le client]
Bloquer Actif Supprimer

[Bloquer par l'administrateur]
[Supprime par l'administrateur]
[Debloquer par l'administrateur]
Figure 14 Diagramme d'état-transition: Client
Diagramme d’état-transition :Réceptionniste
[Creation par le client]
Bloquer Actif
Supprimer
[Bloquer par l'administrateur]
[Supprime par l'administrateur]
[Debloquer par l'administrateur]
[Modifier par l'administrateur]
Receptionniste
Figure 15 Diagramme d’état-transition :Réceptionniste
55
CONCLUSION
Le présent dossier de conception a permis de nous guider tout au long du processus de

développement de notre projet. Pour cela, nous nous sommes appuyés sur le cahier de charges
pour concevoir la futur solution. Cependant, à la fin de cette étape, il est nécessaire d’établir un
dossier de réalisation.
56
PARTIE 5 :DOSSIER DE REALISATION
RESUME
La réalisation d’un projet marque la conclusion aux étapes d’analyse et de conception de la
solution. Dans cette partie du document, nous allons parler des technologies choisies pour
développer la solution, de la présentation des architectures logiques et techniques, ainsi que du
diagramme de déploiement.
PLAN
INTRODUCTION
I- CHOIX DES TECHNOLOGIES

II- PRÉSENTATION DES ARCHITECTURES
III-DIAGRAMME DE DEPLOIEMENT
CONCLUSION
57
INTRODUCTION
Le dossier de réalisation marque la fin de l’analyse, de la conception, et du
développement de notre application en montrant les technologies choisies pour sa création, les
architectures logiques et techniques de notre, ainsi que les différents diagrammes à savoir, dans
notre contexte, celui de déploiement.
58
I. CHOIX DES TECHNOLOGIES
Logiciels
Pour la réalisation de notre projet, il a fallu faire un choix des technologies à
utiliser parmi grand nombre existant dans le monde. Ceux qui seront donc utilisés dans notre
projet sont :
Tableau 15 Choix des technologies
NOM LOGO DESCRIPTION ROLE
PHP 7.2 Langage de Il permettra de

programmation orienté dynamiser nos pages
objet et libre web, d’effectuer les gros
Figure 16 Logo de PHP 7 principalement utilisé pour calculs et d’établir la

produire des pages web communication avec la
dynamiques via un serveur base de données MySQL
HTTP et pouvant
également fonctionner
comme tout langage de
programmation interprété
de façon locale
JavaScript Langage de Dynamisation des petites

programmation de script procédures ne nécessitant
créé par Brendan Eich, pas de connexion à la
ancien développeur à base de données.
Netscape.
Figure 12 Logo de JavaScript
JQuery/Ajax Bibliothèque Javascript Faciliter les requêtes

libre et multiplateforme Ajax
créée pour faciliter
Figure 13 Logo de Jquery/Ajax l’écriture des scripts cotés
59
client dans le code HTML

des pages web
Bootstrap 5 Collecte d’outils utile à la Responsable de la charte

création du design de site graphique de
et d’application web l’application web
Figure 14 Logo de Bootstrap 5
Matériels
Du point de vue matériel, il est nécessaire de se munir des hardwares suivants :
Tableau 16 Matériels
Matériel Fonction Caractéristiques
Caractéristique d’un agrégat

DELL PowerEdge de deux processeur Intel
Serveur : Media Center
T640 Xeon de 2e génération,
jusqu’à 28 coeurs
Wifi Generation : 5
TPLINK TL- Max data rate : 867 Mbits/s
Antenne Wifi
ANT2414A CPU: 720 MHz
II. CYCLE DE DEVELOPPEMENT
Un modèle de développement logiciel désigne toutes les étapes du développement, de

sa conception à sa disparition. L’objectif d’un tel découpage est de permettre de définir les
jalons intermédiaires permettant la validation du développement logiciel, c'est-à-dire la
conformité du logiciel avec les besoins exprimés et la vérification du processus de
développement. Pour cette fois, le cycle en V que nous utilisons, est un modèle d'organisation
des activités d'un projet qui se caractérise par un flux d'activité descendant qui détaille le produit
60
jusqu'à sa réalisation, et un flux ascendant, qui assemble le produit en vérifiant sa qualité,

ce qui lui confère la forme d'un V. Ce modèle est issu du modèle en cascade dont il reprend
l'approche séquentielle et linéaire de phases. Il l'enrichit cependant d'activités d'intégration de
système à partir de composants plus élémentaires, et il met en regard les phases de production
successives avec les phases de validations correspondantes.
Figure 17 Cycle en V
Les étapes du modèle sont alors :
• Exigences: les exigences font l'objet d'une expression des besoins. Le cas échéant,une
étude de faisabilité peut être conduite avant d'engager les travaux ;
• Analyse : il s'agit à partir de l'expression de besoin d'établir le cahier des charges

fonctionnel ou les spécifications fonctionnelles ;
• Conception générale, aussi appelé conception architecturale ou conception

préliminaire: il s'agit de concevoir le système qui doit répondre aux exigences et de
définir son architecture, et en particulier les différents composants nécessaires;
• Conception détaillée: il s'agit de concevoir chaque composant, et la manière dont ils

contribuent à la réponse aux besoins;
• Mise en œuvre: il s'agit de réaliser chaque composant nécessaire. Pour les composants
et systèmes logiciels, l'activité est essentiellement le codage.
61
• Test unitaire: il s'agit de vérifier le bon fonctionnement et la conformité de chaque

composant à sa conception détaillée;
• Intégration et test d'intégration: il s'agit d'assembler le système à partir de tous ses

composants, et de vérifier que le système dans son ensemble fonctionne conformément
à sa conception générale;
• Test système (anciennement « tests fonctionnels ») : vérification que le système est

conforme aux exigences;
• Test d'acceptation (également appelés « recette » dans le contexte de la sous- traitance)

: validation du système par rapport à sa conformité aux besoins exprimés.
Au niveau de la gestion de projet, les différentes étapes peuvent donner lieu à des
phases distinctes sur l'axe horizontal du temps. Plusieurs étapes successives peuvent
toutefois être regroupées au sein d'une phase plus large
III. PRESENTATION DES ARCHITECTURES
Architecture Logique
La logique applicative de notre projet est basée sur le design pattern MVC qui est une
façon très pratique d’organiser ses différentes classes dans un projet de développement
d’application facilitant ainsi la détection d’erreurs, la collaboration et la réutilisabilité du code
.Le design pattern MVC (Modèle vue Contrôleur) est une architecture et une méthode de
conception qui organise l’interface homme-machine (IHM) d’une application logicielle. Ce
paradigme divise l’IHM en un modèle (modèle de données), une vue (interface utilisateur) et
un contrôleur (logique de contrôle, gestion des événements, synchronisation), chacun ayant un
rôle précis dans l’interface.
Le design pattern MVC permet de bien organiser son code source. Il va vous aider à savoir
quels fichiers créer, mais surtout à définir leurs rôles. Le but du MVC est justement de séparer
la logique du code en trois parties que l’on retrouve dans des fichiers distincts.
Modèle : cette partie gère les données de votre site. Son rôle est d’aller récupérer les
informations « brutes » dans une base de données locale ou distante, de les organiser et de les
assembler pour qu’elles puissent ensuite être traitées par le contrôleur. Ces données peuvent
être stockées dans des bases de données, dans le cloud ou dans des fichiers binaires
62
Vue : cette partie se concentre sur l’affichage. Elle ne fait presque aucun calcul et se contente
de récupérer des variables pour savoir ce qu’elle doit afficher. On y trouve essentiellement du
code HTML et CSS, mais aussi quelques boucles et conditions PHP ou JavaScript très simple.
Contrôleur : cette partie gère la logique du code qui prend des décisions. C’est en quelque
sorte l’intermédiaire entre le modèle et la vue : le contrôleur va demander au modèle les
données, les analyser, prendre des décisions et renvoyer le texte à afficher à la vue. Le
contrôleur contient exclusivement du PHP et aussi un peu de JavaScript. C’est notamment lui
qui détermine si le visiteur a le droit de voir ou non une page ou un élément d’une page et sous
quelle forme il doit la voir (Gestion des droits d’accès).
Figure 18 Architecture MVC
Architecture physique
Pour l’implémentation de notre solution, nous avons choisi comme modèle
d’architecture, l’architecture 3— tiers c’est-à-dire de type Client/serveur d’application/Serveur
de bases de données.
63
Cette architecture est l’application du modèle plus général qui est le multi-tiers. Il s’agit
d’un modèle logique d’architecture applicative qui vise à modéliser une application comme un
empilement de trois couches logicielles dont les tâches sont clairement définies :
La présentation des données : correspondant à l’affichage, la restitution sur le poste de

travail, le dialogue avec l’utilisateur.
Le traitement métier des données : correspondant à la mise en œuvre de l’ensemble des

règles de gestion et de la logique applicative.
L’accès aux données persistantes : correspondant aux données qui sont destinées à être
conservées sur la durée, voire de manière définitive.
La figure ci-dessous illustre une représentation de l’architecture 3— tiers :
Figure 19 Architecture 3-tier
IV. DIAGRAMME DE DEPLOIEMENT
Definition
Le diagramme de déploiement modélise les composants matériels utilisés pour
implémenter un système, ainsi que l’association entre ces composants. Le diagramme de
déploiement est constitué de nœuds, de composants logiciels, ainsi que d’associations.
64
Formalisme
Les différents éléments constitutifs d’un diagramme de déploiement sont les suivants :
Tableau 17 Formalisme du diagramme de déploiement
Noeud Un nœud représente un

ensemble d’éléments
matériels du système. Il
est représenté par un
cube tridimensionnel
contenant un nom ainsi
que les composants
associés.
Composant Un composant
représente une entité
logicielle d’un système.
Sur un diagramme de
déploiement, les
composants sont placés
dans des nœuds pour
identifier ou spécifier
l’endroit de leurs
déploiements.
Artéfact Un artéfact représente

une entité physique
d’information issue du
processus de
développement ou de
déploiement d’un
système. Sur un
65
diagramme de
déploiement, les
artéfacts sont placés
dans des nœuds pour
identifier ou spécifier
l’endroit de leurs
déploiements.
Association L’association représente

une relation entre deux
nœuds. Elle est
matérialisée par une
ligne joignant les deux
nœuds.
Dépendance Une dépendance est

utilisée pour modéliser
ou matérialiser la
relation entre deux
composants. La notation
utilisée pour matérialiser
la notation de
dépendance est la flèche
en pointillée, se
dirigeant d’un
composant donné vers le
composant dont il
dépend.
66
Usage La relation d’usage est

utilisée pour matérialiser
le fait qu’un composant a
besoin d’un autre pour
<<use>>
son utilisation ou sa
pleine implémentation
Diagramme de déploiement de la solution
Base de donnees
Serveur Apache
Modele
Routeur
Interface Utilisateur
Controleur Plugins
Generateur de vue
Librairies
Figure 20 Diagramme de déploiement de la solution
67
CONCLUSION
Cette partie du document nous permet d’avoir un aperçu de comment la solution seras
déployée dans le serveur de la CENAME pour qu’elle soit accessible pour tout son personnel
afin de satisfaire aux besoins observés.
68
PARTIE 6 : GUIDE D’INSTALLATION ET D’UTILISATION
RESUME
La réalisation d’un projet marque la conclusion aux étapes d’analyse et de conception
de la solution. Dans cette partie du document, nous allons parler des technologies choisies pour
développer la solution, de la présentation des architectures logiques et techniques, ainsi que du
diagramme de déploiement.
PLAN
INTRODUCTION
I- GUIDE D’INSTALLATION
II- GUIDE D’UTILISATION
CONCLUSION
69
INTRODUCTION
Une fois la solution analysée, conçue et déployée, il est maintenant nécessaire de
former ses futurs utilisateurs à son installation et son utilisation. Cet objectif sera donc de
parler des guides d’installation et d’utilisation.
70
I. GUIDE D’INSTALLATION
L’installation de notre solution se fera sur un serveur web dans un ordinateur disposant
du système d’exploitation Windows 10 Professionnel.
Installation du package
Comme package-nous avons choisies WAMP SERVER 1.6.2 64 bit qui est une plate-
forme de développement Web sous Windows pour des applications Web dynamiques à l’aide
du serveur Apache2, du langage de scripts PHP et d’une base de données MySQL. Il possède
également PHPMyAdmin pour gérer plus facilement vos bases de données .
Figure 21 Logo de WampServer
• PHP 7.2: Langage de programmation orienté objet et libre principalement utilisé pour
produire des pages web dynamiques via un serveur HTTP et pouvant également
fonctionner comme tout langage de programmation interprété de façon locale. PHP est
principalement conçu pour servir de langage de script coté serveur, ce qui fait qu'il est
capable de réaliser tout ce qu'un script CGI quelconque peut faire, comme collecter des
données de formulaire, générer du contenu dynamique, ou gérer des cookies.
• APACHE 2.4.39 : Le logiciel libre Apache HTTP Server est un serveur HTTP créé et
maintenu au sein de la fondation Apache. Jusqu'en avril 2019, ce fut le serveur HTTP
le plus populaire du World Wide Web. Il est distribué selon les termes de la licence
Apache
71
Figure 22 Logo d'Apache
• MYSQL 5.7.26 : MySQL est un système de gestion de bases de données relationnelles.

Il est distribué sous une double licence GPL et propriétaire. MySQL est la base de
données open source la plus populaire au monde. Bien qu'elle soit avant tout connue
pour son utilisation par des sociétés Web, telles que Google, Facebook et Yahoo!,
MySQL est également une base de données embarquée très populaire.
Figure 23 Logo de MySql
• Mysql Workbench : MySQL Workbench est un outil visuel unifié pour les architectes
de bases de données, les développeurs et les administrateurs de bases de données.
MySQL Workbench fournit la modélisation des données, le développement SQL et des
outils d'administration complets pour la configuration du serveur, l'administration des
utilisateurs, la sauvegarde et bien plus encore. MySQL Workbench est disponible sur
Windows, Linux et Mac OS X.
72
Figure 24 Logo de Workbench
Installation du navigateur
Le navigateur utilisé est Google Chrome 64 bit accessible sur
https://www.clubic.com/telecharger-fiche257658-google-chrome.html#modalbox.Chrome est
un navigateur Web développé par Google, bien qu'il émane de projets open source. Ce
navigateur peut être obtenu gratuitement pour toutes les plates-formes sur lesquelles il est
disponible (Windows, Linux, macOS, iOS, iPadOS et Android), et compte plus de 750 millions
d'utilisateurs dans le monde, ce qui en fait l'application la plus utilisée de sa catégorie.
Figure 25 Logo de Google Chrome
II. GUIDE D’UTILISATION
Pour ouvrir notre l’application il faut avoir installé les deux logiciels ci-dessus et enfin
saisir “localhost/supply” puis une page apparait.
73
Figure 26 Page d’authentification de SUPPLY
Apres avoir renseigné des informations correctes l’utilisateur est redirigé sur la page
d’accueil :
Figure 27 Page d’accueil de SUPPLY
Mais s’il est un administrateur il peut accéder au tableau de bord.
74
Figure 28 Page d'administration des utilisateurs
Puis lorsque l’administrateur clique sur administrer la page d’édition de cet utilisateur
s’affiche :
Figure 29 Page d'édition de l'utilisateur
Lorsqu’on retourne sur l’acceuil puis on clique sur commande le formulaire suivant s’affiche :
75
Figure 30 Formulaire de recherche de médicament
76
CONCLUSION GENERALE
Le rôle de l’informatique devient indispensable ainsi bien , par son efficacité que son
utilité, sa présence devient de plus en plus répandue. La problématique posé était
l’automatisation du processus d’approvisionnement en produit pharmaceutique a la CENAME.
C’est pourquoi, durant une période de 3 mois allant du 5 Juillet au 30 Septembre 2021 nous
avions effectués un stage académique a la CENAME avec pour thème : « Digitalisation du
Processus d’Approvisionnement en Produits Pharmaceutique à la CENAME. ».Durant
cette période nous avons pu mettre en place le module d’authentification avec gestion des
privilèges et le module de commande en ligne mais vu le niveau de réalisation nous ne pouvons
pas encore déployés cette application c’est pourquoi ce projet nous allons l’étendre avec des
perspectives.
77
PERSPECTIVES
Ce projet pouvant être nettement plus amélioré, comme perspectives, nous pouvons y
apporter des améliorations techniques telles que :
• Internationaliser l’application : Afin de permettre à tout un chacun de

consulter la plateforme dans la langue de son choix.
• Générer des Statistiques :Afin de représenter les chiffres avec des graphiques.
• Intégré les API :Afin de gérer les transactions bancaires à travers l’application
puis une autre afin de récupérer le nom de tous les médicaments et leurs
informations.
• Intégré le module de gestion documentaire :Qui va nous permettre de recenser

tous les documents qui vont permettre l’approvisionnement en produis
pharmaceutiques
78
BIBLIOGRAPHIE
1. IAI-CAMEROUN, cahier des charges à l’usage des étudiants de 3eme année du cycle de
formation des ingénieurs de Travaux en informatique option Génie Logiciel et Système
et Réseau.
2. Rapport de stage de M.KAMGAING TEKAM STEVE WILLIAM, étudiant en 2eme

Année licence IAI-Cameroun, Centre d’Excellence Technologique Paul Biya –
2018/2019.
3. Cours Rédaction Scientifique 2, de Mme IPEM Arlette ; 2019/2020.
4. Le manuel de procédure de la CENAME ,12 Février 2008.
5. Dr.Doulkifli BOUKRAA , Systèmes d’information, Méthodes avancées, Septembre

2015.
6. Administrez vos bases de données avec MYSQL, de Chantal Gribaumont 2012.
lxxix
WEBOGRAPHIE
1. https://stackoverflow.com - Site web de forums interactifs (question – réponse) dans les

domaines de l’informatique ;
2. https://php.net/manual/fr - Documentation officiel en ligne sur le PHP ;
3. https://api.jquery.com - Documentation officiel en ligne sur le JQuery/Ajax;
4. https://getbootsrtap.com - - Documentation officiel en ligne sur Bootstrap ;
lxxx
Table des matières
DEDICACE ................................................................................................................................ ii
REMERCIEMENTS ................................................................................................................. iii
SOMMAIRES ........................................................................................................................... iv
LISTE DES TABLEAUX ......................................................................................................... vi
LISTE DES FIGURES ............................................................................................................. vii
SIGLES ET ABBREVIATIONS ............................................................................................ viii
RESUME ................................................................................................................................... ix
ABSTRACT ............................................................................................................................... x
INTRODUCTION GENERALE................................................................................................ 1
PARTIE 1: PHASE D’INSERTION .......................................................................................... 2
I. ACCEUIL ET INTEGRATION ......................................................................................... 4
II. PRESENTATION DE LA CENAME................................................................................ 4
Historique ........................................................................................................................ 4
Statut juridique et localisation ......................................................................................... 4
Missions de la CENAME ................................................................................................ 5
III. ORGANIGRAMME ET FONCTIONNEMENT ............................................................... 6
Présentation des directions .............................................................................................. 6
Organigramme de la CENAME ...................................................................................... 6
PARTIE 2 :CAHIER DE CHARGES ........................................................................................ 9
I. CONTEXTE ET JUSTIFICATION DU PROJET ........................................................... 10
Contexte du projet ......................................................................................................... 10
Justificatif ...................................................................................................................... 10
II. OBJECTIFS DU PROJET ............................................................................................... 10
Objectif général ............................................................................................................. 10
lxxxi
Objectif spécifique ..................................................................................................... 10
III. EXPRESSION DES BESOINS ....................................................................................... 11
Les besoins fonctionnels ............................................................................................... 11
Les besoins non fonctionnels ................................................................................. 11
IV. ESTIMATION DU COUT DE PROJET ......................................................................... 11
1. Evaluation en ressources humaines ............................................................................... 11
2. Evaluation en ressources matérielles ............................................................................. 12
Evaluation logicielle ...................................................................................................... 13
Evaluation globale ......................................................................................................... 14
V. PLANNIFICATION DU PROJET................................................................................... 14
VI. CONTRAINTES .............................................................................................................. 15
Contraintes de cout ........................................................................................................ 15
Contraintes de délais ..................................................................................................... 15
Contraintes de qualité .................................................................................................... 15
VII. LIVRABLES .................................................................................................................... 16
PARTIE 3 :DOSSIER D’ANALYSE ...................................................................................... 18
I. RECEUIL DE L’EXISTANT .......................................................................................... 20
Description de l’existant ................................................................................................ 20
Critiques de l’existant.................................................................................................... 21
Problématiques .............................................................................................................. 21
Solution Apportée ......................................................................................................... 21
II. PRESENTATION DE LA METHODE D’ANALYSE ................................................... 21
Présentation du langage UML ....................................................................................... 21
Processus 2TUP............................................................................................................. 29
III. DIAGRAMME D’ANALYSE ......................................................................................... 31
Le diagramme de cas d’utilisation ................................................................................ 31
Description textuelle ..................................................................................................... 36
lxxxii
Le diagramme d’activité............................................................................................. 38
Le diagramme de séquence ........................................................................................... 41
PARTIE 4 :DOSSIER DE CONCEPTION ............................................................................. 47
I. OBJECTIF DE LA CONCEPTION ................................................................................. 49
II. PLAN DU SITE ............................................................................................................... 49
III. DIAGRAMME DE CLASSE........................................................................................... 49
Définition ...................................................................................................................... 49
Formalisme .................................................................................................................... 49
Diagramme de classe de la solution .............................................................................. 52
IV. DIAGRAMME D’ETAT-TRANSITION ........................................................................ 53
Définition ...................................................................................................................... 53
Formalisme .................................................................................................................... 53
Diagramme d’état-transition :Client.............................................................................. 54
Diagramme d’état-transition :Réceptionniste................................................................ 55
PARTIE 5 :DOSSIER DE REALISATION ............................................................................ 57
I. CHOIX DES TECHNOLOGIES ..................................................................................... 59
Logiciels ........................................................................................................................ 59
Matériels ........................................................................................................................ 60
II. CYCLE DE DEVELOPPEMENT................................................................................... 60
III. PRESENTATION DES ARCHITECTURES .................................................................. 62
Architecture Logique..................................................................................................... 62
Architecture physique ................................................................................................... 63
IV. DIAGRAMME DE DEPLOIEMENT ............................................................................. 64
Definition ...................................................................................................................... 64
Formalisme .................................................................................................................... 65
Diagramme de déploiement de la solution .................................................................... 67
PARTIE 6 : GUIDE D’INSTALLATION ET D’UTILISATION ........................................... 69
lxxxiii
I. ......................................................................................................................................... GUIDE
D’INSTALLATION................................................................................................................. 71
Installation du package .................................................................................................. 71
Installation du navigateur .............................................................................................. 73
II. GUIDE D’UTILISATION ............................................................................................... 73
CONCLUSION GENERALE .................................................................................................. 77
lxxxiv

Rapport de Stage Approvissionnement de Produits Pharmaceutique

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport de Stage Approvissionnement de Produits Pharmaceutique

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE DU CAMEROUN REPUBLIC OF CAMEROON

INSTITUT AFRICAIN D’INFORMATIQUE CENAME

RAPPORT DE FIN DE STAGE

THEME : DIGITALISATION DU PROCESSUS

Stage effectué du 05 Juillet au 30 Septembre 2021 en vue de l’obtention du Diplôme

Rédigé par : KRENNA Baiva Anicet Oumar

Encadreur académique : Encadreur professionnel :

Enseignant à l’IAI-CAMEROUN Ingénieur de conception en sécurité informatique

-M. Armand Claude ABANDA, Représentant Résident de l’IAI-Cameroun, Chef

- M. NDIMANTCHI Ayoba, Stagiaire professionnel a la CENAME pour ses conseils et pour

- M. TCHAKOUTIO Ludovic, Enseignant à l’IAI-CAMEROUN pour son encadrement et sa

REMERCIEMENTS ................................................................................................................. iii

LISTE DES TABLEAUX ......................................................................................................... vi

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

SIGLES ET ABBREVIATIONS ............................................................................................ viii

PARTIE 1: PHASE D’INSERTION .......................................................................................... 2

II. PRESENTATION DE LA CENAME................................................................................ 4

III. ORGANIGRAMME ET FONCTIONNEMENT............................................................... 6

PARTIE 2 :CAHIER DE CHARGES ........................................................................................ 9

I. CONTEXTE ET JUSTIFICATION DU PROJET ........................................................... 10

II. OBJECTIFS DU PROJET ............................................................................................... 10

III. EXPRESSION DES BESOINS ....................................................................................... 11

IV. ESTIMATION DU COUT DE PROJET ......................................................................... 11

VI. CONTRAINTES .............................................................................................................. 15

VII. LIVRABLES .................................................................................................................... 16

PARTIE 3 :DOSSIER D’ANALYSE ...................................................................................... 18

I. RECEUIL DE L’EXISTANT .......................................................................................... 20

II. PRESENTATION DE LA METHODE D’ANALYSE ................................................... 21

III. DIAGRAMME D’ANALYSE ...................................................................................... 31

PARTIE 4 :DOSSIER DE CONCEPTION ............................................................................. 47

I. OBJECTIF DE LA CONCEPTION ................................................................................. 49

II. PLAN DU SITE ............................................................................................................... 49

III. DIAGRAMME DE CLASSE........................................................................................... 49

IV. DIAGRAMME D’ETAT-TRANSITION ........................................................................ 53

PARTIE 5 :DOSSIER DE REALISATION ............................................................................ 57

I. CHOIX DES TECHNOLOGIES ..................................................................................... 59

II. CYCLE DE DEVELOPPEMENT................................................................................... 60

III. PRESENTATION DES ARCHITECTURES .................................................................. 62

IV. DIAGRAMME DE DEPLOIEMENT ............................................................................. 64

PARTIE 6 : GUIDE D’INSTALLATION ET D’UTILISATION ........................................... 69

I. GUIDE D’INSTALLATION ........................................................................................... 71

II. GUIDE D’UTILISATION ............................................................................................... 73

CONCLUSION GENERALE .................................................................................................. 77

LISTE DES TABLEAUX

Tableau 1.Evaluation en ressource humaines : Mercuriale des prix 2020 .............................. 12

LISTE DES FIGURES

Figure 1 Plan de localisation ...................................................................................................... 5

• DAPS :Direction de l’approvisionnement et des programmes santé de la CENAME.

Les Technologies de l’Information et de la Communication ne cessent de se développer

PARTIE 1: PHASE D’INSERTION

II. PRESENTATION DE LA CENAME

• 2005 : La CENAME devient un Etablissement Public de forme particulière par le

• 2009 : Par le décret N° 2009/386 du 30 Novembre 2009, la CENAME devient

Statut juridique et localisation

Yaoundé a la Rue Rudolph Douala Manga Bell près de la trésorerie générale du

Figure 1 Plan de localisation

De manière spécifique, elle est chargée :

➢ D’assurer la disponibilité, la permanence et l'accessibilité des médicaments ;

➢ De garantir la qualité des médicaments et dispositifs médicaux essentiel qu'elle distribue

➢ De fournir les Centres d'Approvisionnement Pharmaceutiques Provinciaux en

Médicaments et dispositifs médicaux essentiels au meilleur rapport qualité/prix ;

III. ORGANIGRAMME ET FONCTIONNEMENT

Présentation des directions