Rapport Pfe 3a

11 République de la Côte d’Ivoire
Union-Discipline-Travail
N° d’ordre : 19INP00340/2022/INP-HB/ESI
MEMOIRE DE FIN DE CYCLE
En vue de l’obtention du Diplôme de Technicien Supérieur en Electronique,

Informatique et Télécommunications
REALISATION D’UNE APPLICATION MOBILE DE LA

PLATEFORME E-COMMERCE DE PRODUITBAT
Réalisé par : MASSONG CHARLES JONATHAN LUCIEN

Etudiant Technicien Supérieur en Electronique, Informatique et
Télécommunications 3eme année
Période de stage : 14 mars au 14 juillet 2022
ENCADREUR PEDAGOGIQUE : MAITRE DE STAGE :

M. MOUSSOH Edi M. TOUALY Yere Jean Regis
Enseignant – Chercheur INP-HB / Directeur du service
DFR-GEE informatique de DEVISCADEAU
Année Académique : 2021 – 2022

REALISATION D’UNE APPLICATION MOBILE DE LA PLATEFORME
E-COMMERCE DE PRODUITBAT
PREFACE
Ce mémoire de fin d’études est l’aboutissement de notre parcours dans

l’enseignement supérieur en tant que Technicien Supérieur. Nous le présentons
afin d’obtenir notre DTS en Electronique, Informatique et Télécommunications.
Ledit mémoire qui vous est présenté est un extrait du condensé de savoir
accumuler lors de notre formation universitaire et de l’expérience personnelle
acquise au sein de la structure qui m’a accueillie.
Le projet a été entrepris à la demande de DEVISCADEAU SARL, société au
sein de laquelle j’ai effectué mon stage. L’entreprise était désireuse de proposer,
en plus du support web, leur service e-commerce « PRODUITBAT » sur un
autre support plus accessible et plus intuitif. Ils m’ont donc chargé de la
réalisation de la version mobile de la plateforme web PRODUITBAT.
La réalisation de ce travail ne fut pas de tout repos, loin de là, mais c’est grâce
aux conseils avisés de M. TOUALY Yere que nous avons pu nous rapprocher
des objectifs fixés au départ. Nous tenons à adresser aussi nos remerciements à
notre professeur encadreur M. MOUSSOH Edi pour son aide non négligeable
dans la rédaction de ce mémoire. En espérant que vous apprécierez le contenu.
De : MASSONG Charles
Jonathan Lucien
DEDICACE
Il nous tient à cœur de dédier le travail réalisé aux personnes suivantes :

 Ma famille, véritable soutien moral et spirituel qui contre vents et marées
n’a cessé de croire en moi et en mes capacités. J’espère la rendre fière ;
 Tous les professeurs rencontrés lors de mon parcours universitaire, car ce
sont eux qui ont semé les graines de connaissances qui ont, aujourd’hui,
germé et se sont développées ;
 L’équipe de DEVISCADEAU Sarl, qui m’a apportée une riche
expérience par ses conseils, ses encouragements et plus encore.
Jonathan Lucien
REMERCIEMENTS
Nous tenons tout d’abord à remercier DEVISCADEAU SARL, et

particulièrement M. TOUALY Yere Jean Regis pour nous avoir fait confiance
en nous confiant ce projet, pour son accompagnement rigoureux et ses conseils
avisés sans lesquels rien de tout cela ne serait possible.
Nous pensons également à M. LATTE MICHEE, Directeur Général de la
société DEVISCADEAU SARL, qui a cru en notre potentiel et nous as accueilli
au sein de son entreprise.
Nous souhaitons aussi remercier tout particulièrement M. MOUSSOH Edi, notre
encadreur à l’Institut National Polytechnique Félix HOUPHOUËT BOIGNY
(INP-HB), pour sa disponibilité, ses conseils qui nous ont permis de rédiger ce
rapport.
Un grand merci à mon père, ma mère et mes frères.
Jonathan Lucien
SOMMAIRE
PREFACE................................................................................................................................................I
DEDICACE............................................................................................................................................II
REMERCIEMENTS...........................................................................................................................III
SOMMAIRE.........................................................................................................................................IV
SIGLES...................................................................................................................................................V
LISTE DES FIGURES.......................................................................................................................VII
LISTE DES TABLEAUX.................................................................................................................VIII
AVANT-PROPOS................................................................................................................................IX
RESUME...............................................................................................................................................XI
INTRODUCTION..................................................................................................................................1
PARTIE I : PRESENTATION DE LA STRUCTURE D’ACCEUIL ET DU THEME.............................2
CHAPITRE I : PRÉSENTATION DE LA STUCTURE D’ACCEUIL............................................................................3
I. PRÉSENTATION DE DEVISCADEAU SARL..................................................................................................3
II. ORGANISATION ET SITUATION GÉOGRAPHIQUE DE L’ENTREPRISE.................................................4
CHAPITRE II : PRÉSENTATION DU PROJET ET PLANIFICATION..........................................................................5
I. PRÉSENTATION DU PROJET...........................................................................................................................5
II. CAHIER DES CHARGES...................................................................................................................................6
III. PLANIFICATION DES TACHES.......................................................................................................................6
PARTIE II : ETUDE APPROFONDIE DU PROJET...................................................................................8

CHAPITRE III : ETUDE DE L’EXISTANT ET SPECIFICATION DES BESOINS......................................................9
I. ETUDE DE L’EXISTANT...................................................................................................................................9
II. SPECIFICATION DES BESOINS.....................................................................................................................10
CHAPITRE IV : METHODE D’ANALYSE ET DE CONCEPTION............................................................................13
I. MERISE..............................................................................................................................................................13
II. UML / PU...........................................................................................................................................................16
III. ÉTUDE COMPARATIVE ET CHOIX DE LA METHODE D’ANALYSE.....................................................20
CHAPITRE V : CONCEPTION......................................................................................................................................21
I. BRANCHE FONCTIONNELLE.......................................................................................................................21
CHAPITRE VI : OUTILS D’IMPLEMENTATION.......................................................................................................35
I. CHOIX DE L’ARCHITECTURE DE DEPLOIEMENT...................................................................................35
II. FRONTEND.......................................................................................................................................................38
III. BACKEND.........................................................................................................................................................40
IV. AGREGATEUR DE PAIEMENT......................................................................................................................41
V. BILAN DES OUTILS UTILISÉS......................................................................................................................42
PARTIE III : REALISATION DE L’APPLICATION................................................................................43

CHAPITRE VII : PRESENTATION DES INTERFACES.............................................................................................44
I. PRESENTATION DES INTERFACES PRINCIPALES..................................................................................44
II. QUELQUES ACTIONS POSSIBLE SUR L’APPLICATION PRODUITBAT...............................................47
CHAPITRE VIII : ESTIMATION DU PROJET.............................................................................................................50
CONCLUSION.....................................................................................................................................51
BIBLIOGRAPHIE.............................................................................................................................XII
WEBOGRAPHIE..............................................................................................................................XIII
TABLE DES MATIERES................................................................................................................XIV
Jonathan Lucien
SIGLES
2
2TUP : Two Tracks Unified Process
A
API : Application Programming Interface
C
CPGE : Classes Préparatoires aux Grandes Ecoles
CSRF : Cross-Site Request Forgery
E
EDP : Ecole Doctorale Polytechnique
EFCPC : Ecole de Formation Continue et de
Perfectionnement des Cadres
ENSA : Ecole Nationale Supérieure
d’Agronomie
ENSTP : Ecole Nationale
Supérieure des
Travaux Publics
ESA : Ecole Supérieure
d’Agronomie
ESCAE : Ecole Supérieure de Commerce et
d’Administration des Entreprises
ESI : Ecole Supérieure d’Industrie
ESMG : Ecole Supérieure
des Mines et de
Géologie
ESTP : Ecole Supérieure
des Travaux
Publics
I
IAB : Institut Agricole de Bouaké
INP-HB : Institut National Polytechnique Félix
Jonathan Lucien
HOUPHOUËTBOIGNY
INSET : Institut National Supérieur
d’Enseignement Technique
M
MCD : Modèle Conceptuel de Données
MCT : Modèle Conceptuel de Traitement
MERISE : Méthode d’Etude et de Réalisation Informatique par
Sous–Ensembles
MLD : Modèle Logique de Données
MLT : Modèle Logique de Traitement
MOD : Modèle organisationnel de Données
MOT : Modèle Organisationnel de Traitement
MPD : Modèle Physique de Données
MVC : Model View Controller
MySQL : My Structured Query Language
P
PHP : Hypertext Preprocessor
PTAC : Poids Total Autorisé en Charge
PU : Processus Unifié
R
RUP : Rational Unified Process
S
SGBD : Système de Gestion de Base des Données
SQL : Structured Query Language
SARL : Société à Responsabilité Limitée
U
UML : Unified Modeling Language
URL : Uniform Resource Locator
X
XUP : eXtreme Unified Process
Jonathan Lucien
LISTE DES FIGURES
Figure 1 : Organigramme de DEVISCADEAU.....................................................................4

Figure 2 : Diagramme de GANTT..........................................................................................7
Figure 3 : Interface d’accueil de PRODUITBAT..................................................................9
Figure 4 : Diagrammes de contexte statique........................................................................23
Figure 5 : Diagrammes de contexte dynamique...................................................................24
Figure 6 : Diagrammes des cas d’utilisation.........................................................................25
Figure 7 : Diagramme de paquetages....................................................................................26
Figure 8 : Diagramme de séquence cas « authentification »...............................................31
Figure 9 : Diagramme de séquence cas « Commander »....................................................32
Figure 10 : Diagramme de séquence cas « Ajout au panier ».............................................33
Figure 11 : Diagramme de classe...........................................................................................34
Figure 12 : Architecture 1-tiers.............................................................................................35
Figure 15 : Interface d’accueil de PRODUITBAT..............................................................44
Figure 16 : Interface des catégories de PRODUITBAT......................................................45
Figure 17 : Interface compte du client de PRODUITBAT.................................................45
Figure 18 : Interface des détails d’un Produit......................................................................46
Figure 19 : Logo de l’application PRODUITBAT...............................................................46
Figure 20 : Ajout d’un produit au panier.............................................................................47
Figure 21 : Interface du panier..............................................................................................47
Figure 22 : Validation de Commande...................................................................................48
Figure 23 : Choix de la méthode de paiement......................................................................48
Figure 24 : Recherche d’un produit......................................................................................49
Figure 25 : Interfaces d’authentification..............................................................................49
Jonathan Lucien
LISTE DES TABLEAUX
Tableau 1: Cycle de vie de merise.........................................................................................14

Tableau 2 : Niveaux d'abstraction de MERISE...................................................................15
Tableau 3 : Cycle de décision de MERISE...........................................................................15
Tableau 4 : Comparaison des principales variantes du Processus Unifié.........................19
Tableau 5:Étude comparative MERISE et PU....................................................................20
Tableau 6 : Présentation des acteurs de PRODUITBAT....................................................21
Tableau 7 : Liste des objectifs................................................................................................27
Tableau 8 : Description textuelle du cas « S’authentifier »................................................28
Tableau 9 : Description textuelle du cas « Commander »...................................................29
Tableau 10 : Description textuelle du cas « Ajout au panier »...........................................30
Tableau 11 : Comparative de technologies de développement frontend...........................39
Tableau 12 : Technologies utilisées pour le développement de PRODUITBAT...............42
Tableau 13 : Evaluation financières du projet.....................................................................50
Jonathan Lucien
AVANT-PROPOS
[W1]
L’Institut National Polytechnique Félix -BOIGNY (INP-HB) a été créé par
décret 96-678 du 04 Septembre 1996, de la restructuration des quatre grandes
écoles dont les noms suivent :
 École Nationale Supérieure d’Agronomie (ENSA) ;
 École Nationale Supérieure des Travaux Publics (ENSTP) ;
 Institut Agricole de Bouaké (IAB HOUPHOUËT) ;
 Institut National Supérieure de l’Enseignement Technique (INSET) ;
A sa création, l’INPHB était constitué sept (07) écoles formant des techniciens
supérieurs, des ingénieurs de techniques et de conception. Elle est aujourd’hui
constituée de huit (08) grandes écoles reparties sur trois sites que sont : INP-
NORD, INP-SUD et INP-CENTRE. L’INP-NORD qui regroupe les écoles
suivantes :
 Ecole de Formation Continue et de Perfectionnement des Cadres (EFCPC) ;
 Ecole Supérieure d’Agronomie (ESA) ;
 Ecole Doctorale Polytechnique (EDP).
L’INP-CENTRE regroupe les écoles suivantes :

 Ecole Supérieure de Commerce et d’Administration des Entreprises (ESCAE) ;
 Ecole Supérieure d’Industrie (ESI).
L’INP-SUD qui regroupe les écoles suivantes :

 Ecole Supérieure de Travaux Publics (ESTP) ;
 Ecole Supérieure des Mines et Géologie (ESMG) ;
 Classes Préparatoires aux Grandes Ecoles (CPGE) ;
 Ecole Supérieure du Pétrole et de l’Energie (ESPE).
Jonathan Lucien
L’ESI dont nous sommes issus forme des ingénieurs et des techniciens
supérieurs dans plusieurs spécialités telles que l’énergétique, la mécanique,
l’électronique, la télécommunication, moteurs et équipements motorisés, la
chimie alimentaire, la chimie industrielle, l’électrotechnique et l’informatique.
La filière électronique, informatique et télécommunication (EIT), d’où nous
venons, a été créée dans le souci de former des techniciens aptes à répondre aux
exigences des industries avec une formation pluridisciplinaire.
C’est donc pour finaliser notre formation de Technicien Supérieur que l’école
instaure en fin de cycle, un stage permettant à l’étudiant de se familiariser aux
réalités de l’entreprise et de mettre au profit de celle-ci les connaissances
acquises tout au long de sa formation. C’est dans ce cadre que nous avons été
accueillis dans la société DEVISCADEAU SARL pour effectuer notre stage de
fin de cycle.
Jonathan Lucien
RESUME
Le projet qui nous a été soumis vient du besoin de l’entreprise DEVISCADEAU

SARL de proposer une boutique e-commerce de matériaux de construction sur
mobile. En effet bien qu’elle possède déjà un site web nommé PRODUITBAT
en fin de développement qui fournit ce service, elle souhaite élargir son marché
de client potentiel en facilitant la disponibilité de la boutique. C'est dans cette
perspective que nous avons reçu le thème suivant : « REALISATION D'UNE
APPLICATION MOBILE DE LA PLATEFORME E-COMMERCE DE
PRODUITBAT ».
Il s’agira pour nous de reproduire le site vitrine de PRODUITBAT où le client
pourra consulter le catalogue de produits disponibles, effectuer des achats et/ou
produire des devis. Dans la réalisation de ce travail certains outils se sont montré
indispensables à savoir le Framework Flutter pour le frontend et le backend
niveau client, le Framework Laravel pour le backend niveau serveur, MySQL
pour stocker notre base de données et bien d’autres.
Mots-clés : PRODUITBAT, e-commerce, boutique, application,

Framework.
Jonathan Lucien
INTRODUCTION
Avec des progrès techniques considérables et une digitalisation de plus en

plus importante, les outils technologiques font désormais partie de notre
quotidien. Avec cette évolution on remarque aussi le développement et/ou
l’émergence de nouvelles solutions pour répondre aux besoins dans certains
domaines. Les entreprises conscientes de cela s’efforcent de proposer des
solutions digitales innovantes à leurs clientèles.
Notamment DEVICADEAU SARL qui décide alors de lancer un projet e-
commerce de vente de matériaux de construction. Pour réaliser ce projet elle met
sur pied un site web nommé PRODUITBAT. Néanmoins pour élargir le marché
et faciliter la disponibilité de PRODUITBAT à toute personne, elle va décider
de mettre en développement une version mobile du site. C’est en ce sens qu’ils
m’ont attribué le thème suivant : « REALISATION D’UNE APPLICATION MOBILE
DE LA PLATEFORME E-COMMERCE DE PRODUITBAT ».
Alors, dans quel environnement notre projet s’inscrit-il ? Et quelles sont les
étapes qui mènent à la réalisation de notre projet ?
Dans la suite, nous nous efforcerons de répondre à ces interrogations dans notre
travail qui sera présenté autour de trois (03) axes, structurés en huit (08)
chapitres. Dans la première partie, nous présenterons le projet, son contexte, et
la structure d’accueil. Dans la seconde, nous présenterons les méthodes
d’analyse et de conception sans oublier l’élaboration du système. Enfin, la
dernière relatera de la réalisation a proprement du projet et de l’estimation de
celui-ci.
Jonathan Lucien
PARTIE I : PRESENTATION DE LA
STRUCTURE D’ACCEUIL ET DU THEME
Dans cette partie nous allons tout d’abord présenter l’environnement dans lequel
le projet a été réaliser et expliciter celui-ci.
Jonathan Lucien
CHAPITRE I : PRÉSENTATION DE LA STUCTURE

D’ACCEUIL
I. PRÉSENTATION DE DEVISCADEAU SARL

1. Contexte de création
DEVISCADEAU SARL est une entreprise connue dans le secteur des Bâtiments
et Travaux Publics, créée à partir d’une réflexion collective entre jeunes
ivoiriens de formation divers.
L’entreprise DEVISCADEAU SARL a pour cœur de métier le BTP. Depuis sa
création en 2016, son objectif est de répondre aux problèmes que rencontrent les
entreprises et ménages dans le but de trouver le ou les prestataire(s) idéal. Elle
dispose d’un réseau de professionnels et un personnel qualifié pour répondre
efficacement aux exigences de sa clientèle.
2. Mission
DEVISCADEAU SARL a pour mission d’offrir des prestations innovantes et
efficaces dans ses domaines de compétences tout en travaillant à l’amélioration
et l’accessibilité des prestations de services BTP aux entreprises et particuliers.
3. Domaine de compétence
Les domaines de compétence de DEVISCADEAU SARL :
 Génie civil
 Menuiserie
 Charpente et étanchéité
 Et bien d’autres...
Jonathan Lucien
II. ORGANISATION ET SITUATION GÉOGRAPHIQUE DE

L’ENTREPRISE
1. Structure organisationnelle
Figure 1 : Organigramme de DEVISCADEAU
2. Situation géographique
 Siège Social : Abidjan Koumassi Remblais, Carrefour Ibo ;
 Adresse : 10 BP 819 Abidjan 01 ;
 Téléphone : +225 27 21 39 27 79 ;
Jonathan Lucien
CHAPITRE II : PRÉSENTATION DU PROJET ET

PLANIFICATION
I. PRÉSENTATION DU PROJET
1. Contexte de réalisation
DEVISCADEAU SARL étant une entreprise spécialisée dans le BTP, en
prestant ses services, a pu remarquer auprès des entreprises et même des
particuliers, le besoin d’avoir une référence sur les prix sans cesse fluctuants des
matériaux de construction, et aussi l’envie de se rapprocher directement des
fournisseurs de ces matériaux.
DEVISCADEAU SARL remarquant l’absence d’une réelle
institution qui pourra recoudre ces différents besoins et apporter satisfaction aux
clients décide de concevoir un site WEB d’e-commerce nommée
PRODUITBAT qui sera axés sur la vente de matériaux et outils de
constructions. Dans l’optique d’élargir son
marché et de rendre plus accessible son idée, l’entreprise décidera de développer
la version mobile de PRODUITBAT d’où le thème du projet : ‘REALISATION
D’UNE APPLICATION MOBILE DE LA PLATEFORME E-COMMERCE DE DE
PRODUITBAT.’
2. Les objectifs
L’objectif général de ce projet est la réalisation de l’application de mobile
de PRODUITBAT qui pourra être hébergé sur Play Store et App Store
afin de diversifier et d’élargir sa clientèle.
Pour atteindre l’objectif précédemment cité il faudra mener diverses
actions et réaliser certaines tâches, il s’agit en effet des objectifs
spécifiques qui sont les suivants :
 Exposition des produits ainsi que leurs prix et
caractéristiques;
 Inscription des visiteurs pour devenir clients ;
 Ajout des produits choisis au panier ;
 Choix du mode de livraison ;
Jonathan Lucien
 Le payement en ligne ;
 Confirmation de l’opération d’achat et la réception de la
facture.
II. CAHIER DES CHARGES

L’application qui sera développée devra prendre en compte les exigences
suivantes :
 La gestion des devis
 Les espaces clients
 La gestion des commandes
 L’affichage des produits
 L’affichage des catégories
 La barre de recherche
 La gestion du panier
 La connexion ou l’inscription d’un client
III. PLANIFICATION DES TACHES
L’organisation d'un projet est une activité qui consiste à prévoir

l'ordonnancement des tâches du projet, à estimer leurs charges et à déterminer
les profils nécessaires à leur réalisation. L’outil requis est le planning.
Le planning constitué va permettre le suivi du
projet durant son déroulement. Il sera ainsi possible de déterminer si les
objectifs fixés sont atteints.
1. Liste des tâches

Avant la réalisation d’un projet il faut pouvoir énumérer les différentes tâches
qui peuvent y intervenir.
Jonathan Lucien
Quant à ce projet les taches à réaliser seront :

- Une formation sur la prise en main de la base de données déjà existante ;
- Une formation sur Laravel ;
- Le choix des outils de développement ;
- Fixer les objectifs à atteindre ;
- La réalisation des différentes interfaces ;
- La réalisation de la communication entre l’application et le serveur ;
- L’implémentation de l’application
- La rédaction du rapport ;
- Prendre rendez-vous avec le professeur encadreur.
2. Diagramme de Gantt
Le diagramme de Gantt est un outil de planification des tâches nécessaires pour

la réalisation d'un projet quel que soit le secteur d’activité. Il permet de
visualiser l’avancement des tâches d’un projet de manière simple et concise, et
de pouvoir ainsi suivre l’avancement du projet.
2 2 2 2 2 2 2 2
-2 -2
r-2 r-2 -2 -2 -2 -2 22 22
ar
s
ar
s ai ai in in il- il-
m m -av -av -m -m -ju -ju -ju -ju
1 4- 2 8- 11 25 09 23 06 20 04 14
ETUDE DU PROJET 2 semaines

Definition du theme
Analyse du cahier des charges
Organisation du travail
Formation sur la methode d'analyse utilisé
REALISATION DE L'APPLICATION 7 semaines
Création de l'interface d'acceuil
Gestion de l'affichages des catégories
Gestion de l'affichages des produits
Création des l'interfaces de connexion
Création de l'interface client
Gestion du panier
Gestion des commandes
IMPLEMENTATION 10 jours
Test de l'application
Hebergement sur playStore et l'appStore
REDACTION DU RAPPORT 4 mois
Jonathan Lucien
Figure 2 : Diagramme de GANTT
PARTIE II : ETUDE APPROFONDIE DU

PROJET
Dans cette partie nous allons effectuer une étude plus poussée de notre projet.
Nous commencerons par une étude de l’existant, ensuite à l’analyse de la
méthode de modélisation et enfin les outils d’implémentation utilisés.
Jonathan Lucien
CHAPITRE III : ETUDE DE L’EXISTANT ET

SPECIFICATION DES BESOINS
I. ETUDE DE L’EXISTANT
1. Description de l’existant
DEVISCADEAU SARL arrive déjà en fin de développement de son site web E-
commerce PRODUITBAT. En effet ce site permettra à ses visiteurs de procéder
à l’achat direct de matériaux ou outils de constructions parmi un large catalogue
présenter par tout type de fournisseurs ou de simplement les consulter pour en
dégager un devis.
Figure 3 : Interface d’accueil de PRODUITBAT
Jonathan Lucien
2. Critique de l’existant
Avec la mise en place du site vitrine PRODUITBAT, DEVISCADEAU SARL

résout bon nombre de problèmes et offres aux clients de nouvelles possibilités à
savoir :
- Permettre aux clients d’avoir plus de contrôle car ils pourront eux-mêmes
procéder à l’achat des matériaux ;
- D’effectuer un devis en ligne rapidement et simplement ;
- Rapprocher les clients avec les différents fournisseurs partenaires ;
- Permettre aux clients d’avoir accès aux dernières promotions des
matériaux qu’ils recherchent.
Comme nous pouvons le constater PRODUITBAT répond à un réel problème
dans le domaine du BTP. Néanmoins une amélioration peut être apporter au
projet en le rendant plus accessible et plus intuitif. En effet malgré l’aspect
responsif du site qui lui permet de s’adapter à tous types d’écrans et donc celui
des smartphones, le fait d’y accéder en une touche sans saisir dans une barre de
recherche le lien du site ou encore avoir une ergonomie adaptée et plus agréable
prime ; d’où la raison du projet soumis.
II. SPECIFICATION DES BESOINS

Dans cette section, nous nous intéressons aux besoins des utilisateurs dans notre
projet à travers les spécifications fonctionnelles et non fonctionnelles pour
aboutir à une application de qualité qui répond aux besoins des clients.
1. Besoins fonctionnels
L’application devra répondre aux mêmes besoins que celles du site web à
savoir :
 L’affichage des produits :
L’application doit disposer d’une vitrine virtuelle à travers laquelle le
client pourra consulter une grande variété des produits, il sera donc
Jonathan Lucien
indispensable d’y présenter les prix et les caractéristiques techniques de

chaque produit pour faciliter la sélection du produit à acheter.
 L’inscription et la connexion du client :

Il faudra que le client puisse s’inscrire pour pouvoir passer commande. Il
pourra aussi s’identifier avec son mail et son mot de passe s’il possède au
préalable un compte.
 L’ajout des produits au panier :

Après le choix d’un produit le client doit mentionner la quantité qui
s’ajoute automatiquement à son panier avec le prix unitaire et le prix total.
 Les modes de livraison :

Le client devrait pouvoir choisir entre deux modes de livraison à savoir,
directement sur le chantier où se passent les travaux, où aller lui-même
récupérer ses produits directement chez le(s) fournisseur(s)
correspondant(s).
 Le paiement :
Pour procéder au paiement le client aura la possibilité entre plusieurs
moyens à savoir : les services de mobile money, la carte bancaire, etc...
 La fin de l’opération d’achat :

Apres validation de la commande et du paiement une facture sera envoyé
au client qui résumera l’opération effectuée.
2. Besoins non fonctionnels

Les besoins non fonctionnels désignent un ensemble de spécifications non
explicites qui améliorent la qualité d’une application, ce qui fait qu’ils ne
doivent pas être négligés. Dans notre cas notre application devra respecter les
exigences suivantes :
 La fiabilité : L’application doit fonctionner de façon cohérente sans

erreurs et doit être satisfaisante.
Jonathan Lucien
 Les erreurs : Les ambigüités doivent être signalées par des messages
d’erreurs bien organisés pour bien guider l’utilisateur et le familiariser
avec notre site web.
 L’ergonomie et une bonne Interface : L’application doit être adaptée à
l’utilisateur sans qu’il ne fournisse le moindre effort (utilisation claire et
facile).
 La sécurité : Notre solution doit respecter surtout la confidentialité des
données personnelles des clients.
Jonathan Lucien
CHAPITRE IV : METHODE D’ANALYSE ET DE

CONCEPTION
Une méthode d'analyse et de conception informatique a pour objectif de

formaliser les étapes préliminaires du développement d'un système afin de le
rendre plus fidèle aux besoins du client[B3].
Et parmi toutes les approches existantes, les plus utilisées sont la méthode
MERISE et le Processus Unifié (PU) allié au langage de modélisation UML.
Nous présentons ici succinctement ces deux (2) méthodes avec leurs principales
approches et implémentations.
I. MERISE
La Méthode d’Etude et de Réalisation Informatique par Sous-Ensemble
(MERISE) est une méthode de conception, de développement et de réalisation
de projets informatiques.
MERISE est basée sur le principe de la séparation des données et des
traitements[B1]. Elle propose une démarche articulée simultanément sur quelques
axes pour hiérarchiser les préoccupations auxquelles répondre lors de la
conduite d’un projet.
Lesquelles sont :
1. La démarche ou cycle de vie
La dénomination de ce cycle de vie traduit le caractère « vivant » du système
d'information, qui représente une conception, une gestation, une naissance. Dans
le cas d'un système d'information (SI), on peut distinguer trois grandes périodes :
la conception, la réalisation et la maintenance.
La méthode MERISE propose, pour le déroulement du cycle de vie, le
découpage de ces grandes périodes en différentes étapes illustrées par le tableau
suivant :
Jonathan Lucien
Tableau 1 : Cycle de vie de merise
Tableau 1: Cycle de vie de merise
C’est la représentation du domaine étudié à travers plusieurs modèles suivant un

formalisme en tenant compte du niveau d’abstraction. Le tableau ci-dessous
décrit les niveaux d’abstraction et les modèles correspondants.
Tableau 2 : Niveaux d'abstraction de MERISE
Tableau 2 : Niveaux d'abstraction de MERISE
Jonathan Lucien
2. La maîtrise ou cycle de décision

La maîtrise du déroulement simultané de la démarche et du raisonnement
nécessite la prise de décision des choix à retenir. Ainsi, à chaque niveau de
développement et à chaque étape, des décisions doivent être prises.
Tableau 3 : Cycle de décision de MERISE
Tableau 3 : Cycle de décision de MERISE
II. UML / PU
1. Langage de modélisation unifié (UML)
Unified Modeling Language (UML) est né de la fusion des trois méthodes qui
ont le plus influencé la modélisation objet au milieu des années 90. Il est un
langage graphique qui permet de représenter les divers aspects du système
d’information[B2].
Les diagrammes d’UML se regroupent en trois grandes catégories : les
diagrammes statiques, dynamiques et de comportement.
Jonathan Lucien
a. Les diagrammes statiques

 Le diagramme de classes : représentation des classes intervenant
dans le système ;
 Le diagramme objets : représentation des instances de classes

(objets) utilisées dans le système ;
 Le diagramme de composants : représentation des composants

du système d'un point de vue physique, tels qu'ils sont mis en
œuvre (fichiers, bibliothèques, bases de données…) ;
 Le diagramme de déploiement : représentation des éléments

matériels (ordinateurs, périphériques, réseaux, systèmes de
stockage…) et la manière dont les composants du système sont
répartis sur ces éléments matériels et interagissent entre eux ;
 Le diagramme des paquetages : représentation des dépendances

entre les paquetages (un paquetage étant un conteneur logique
permettant de regrouper et d'organiser les éléments dans le
modèle UML), c'est-à-dire entre les ensembles de définitions ;
 Le diagramme de structure composite : représentation, sous

forme de boîte blanche, des relations entre composants d'une
classe ;
 Le diagramme de profils : spécialisation et personnalisation

pour un domaine particulier d'un méta modèle de référence
d'UML.
b. Les diagrammes de comportements

 Le diagramme des cas d’utilisation : représentation des possibilités
d'interaction entre le système et les acteurs (intervenants extérieurs au
système), c'est-à-dire de toutes les fonctionnalités que doit fournir le
système ;
 Le diagramme état-transitions : représentation sous forme de machine à
états finis le comportement du système ou de ses composants ;
 Le diagramme d’activité : représentation sous forme de flux ou
d'enchaînement d'activités le comportement du système ou de ses
composants.
Jonathan Lucien
c. Les diagrammes dynamiques

 Le diagramme de séquence : représentation de façon
séquentielle du déroulement des traitements et des interactions
entre les éléments du système et/ou de ses acteurs ;
 Le diagramme de communication : représentation de façon
simplifiée d'un diagramme de séquence se concentrant sur les
échanges de messages entre les objets ;
 Diagramme global d'interaction : représentation des
enchaînements possibles entre les scénarios préalablement
identifiés sous forme de diagrammes de séquences (variante du
diagramme d'activité) ;
 Diagramme de temps : représentation des variations d'une
donnée au cours du temps.
2. Le Processus Unifié (PU)

Le Processus Unifié (PU), est une méthode générique, itérative et incrémentale
de développement qui fusionne le traitement des données de celui des
opérations. Il permet d’analyser, de concevoir et de réaliser des solutions
logicielles techniques, mais peut très bien prendre en compte les solutions
logicielles orientées vers la gestion des systèmes d’information.
Les caractéristiques du Processus Unifié sont les suivantes[W4] :
 Piloté par les cas d’utilisation : le but principal d'un système
informatique est de satisfaire les besoins du client. Le processus
de développement sera donc accès sur l'utilisateur. Les cas
d’utilisation permettent d’illustrer ces besoins ;
 Centré sur l’architecture : tout système complexe doit être
décomposé en parties modulaires afin d’en faciliter la
maintenance et l’évolution. Cette architecture (fonctionnelle,
logique, matérielle, etc.) doit être modélisée en UML, et pas
seulement documentée en texte ;
 Itératif et incrémental : le projet est découpé en itérations ou
étapes de courte durée qui permettent de mieux suivre
l’avancement global. A la fin de chaque itération une partie
exécutable du système final est produite, de façon incrémentale
(par ajout) ;
 Piloté par les risques : Les risques majeurs du projet doivent
être identifiés au plus tôt mais surtout levés le plus rapidement.
Jonathan Lucien
3. Les déclinaisons du PU
Le Processus Unifié étant générique, il peut être adapté selon le projet
et l’environnement de travail. Plusieurs déclinaisons en découlent, à savoir
RUP (Rational Unified Process), XUP (Extreme Unified Process) et 2TUP
(Two Tracks Unified Process).
Tableau 4 : Comparaison des principales variantes du Processus Unifié
III. ÉTUDE COMPARATIVE ET CHOIX DE LA METHODE

D’ANALYSE
Tableau 4 : Comparaison des principales variantes du Processus Unifié
Le tableau ci-dessous présente l’étude comparative entre MERISE et le
Processus Unifié, que nous avons effectuée afin de choisir la méthode d’analyse
et de conception, la mieux adaptée à notre projet.
Tableau 5 : Étude comparative MERISE et PU
Tableau 5:Étude comparative MERISE et PU
Jonathan Lucien
Cette étude comparative nous amène à choisir le Processus Unifié comme

méthode d’analyse de notre future application dans la mesure où :
• il regroupe les données et les traitements ;
• il utilise un seul niveau d’abstraction permettant l’utilisation de n’importe quel
modèle en fonction de l’aspect à décrire ;
• il prend en compte toutes les étapes de la conduite d’un projet depuis la
conception jusqu’au déploiement.
CHAPITRE V : CONCEPTION
Nous allons, dans le présent chapitre faire la conception de notre future

application en utilisant le langage UML et ses outils : les diagrammes, tout en se
basant sur le travail effectuer pour la conception du site.
I. BRANCHE FONCTIONNELLE
1. Identification des acteurs
Un acteur représente un rôle joué par une entité externe (utilisateur humain,
dispositifs matériels ou autres systèmes) qui interagit directement avec le
système étudié. Il peut consulter et/ou modifier directement l’état du système, en
émettant et/ou en recevant des messages susceptibles d’être porteurs de données.
Dans le cadre de notre étude, nous avons identifié 5 acteurs : Visiteur, Client,
Administrateur, Fournisseur, Livreur.
Tableau 6 : Présentation des acteurs de

PRODUITBAT
Jonathan Lucien
Tableau 6 : Présentation des acteurs de PRODUITBAT
Acteurs Details Rôles
C’est un utilisateur non

Les visiteurs inscrit sur ProduitBat. Il - Consulter les produits
n’a alors droit qu’aux présents sur l’application ;
informations publiques. - Effectuer des actions sur le
panier
- Consulter les produits
Utilisateur inscrit autoriser
Les clients présents sur l’application ;
à passer des commandes.
Et générer des devis - Effectuer des actions sur le
panier ;
- Passer des commandes ;
- Effectuer un devis
Un fournisseur pour notre - Ajouter les produits ;
Les fournisseurs site est un particulier ou - Mettre des produits en
une entreprise nous fournit promotion ;
les marchandises. - Confirmer les commandes
Les Livreurs C’est le livreur qui se - Livraison
chargera d’envoyer ses
marchandises au client si
ce dernier a choisi d’être
livré.
L’administrateur est - Gestion des comptes
L’administrateur chargé des comptes utilisateurs ;
utilisateurs, et la gestion - Gestions des commandes et
de la boutique. livraisons ;
- Gestions des produits
(Activé ou désactivé)
2. Modélisation des diagrammes de contexte

La modélisation du contexte d’un système se fait avec les diagrammes de
contexte statique et dynamique du système. Le diagramme de contexte statique
concerne le nombre d’occurrences de chaque acteur pouvant participer
simultanément à des échanges avec le système. Tandis que le second met en
relief les messages échangés entre le système et les acteurs.
Jonathan Lucien
a. Diagrammes de contexte statique

Ci-dessous présenté le diagramme de contexte statique du projet dans sa
globalité.
0.. * 0.. *
Visiteur
Client
PRODUITBAT
0.. *
0.. *
Administrateur
Fournisseur
0.. *
Livreur
Figure 4 : Diagrammes de contexte statique
Jonathan Lucien
b. Diagrammes de contexte dynamique

Ci-dessous présenté le diagramme de contexte dynamique du projet dans sa
globalité.
Consulter ()
Consulter ()
Acheter ()
Client Visiteur
PRODUITBAT
Consulter () Administrer ()
Ajouter Produits ()
Consulter ()
Livrer ()
Jonathan Lucien
Administrateur
Fournisseur
Livreur
Figure 5 : Diagrammes de contexte dynamique
3. Diagramme des cas d’utilisation

Les diagrammes de cas d’utilisation sont des diagrammes UML utilisés pour
donner une vision globale du comportement fonctionnel d’un système logiciel.
C’est la description du modèle vu par les acteurs du système. En effet, les cas
d’utilisation et les acteurs dans les diagrammes de cas d’utilisation décrivent ce
que le système fait et comment les acteurs l’utilisent, mais ne montrent pas
comment le système fonctionne en interne.
Ci-dessous le diagramme des cas d’utilisation du projet global PRODUITBAT.
Jonathan Lucien
Figure 6 : Diagrammes des cas d’utilisation
4. Diagramme de paquetage
Un paquetage est un regroupement de différents éléments d’un système 6
(classes, diagrammes, fonctions, interfaces…).
Le diagramme7 de paquetages est un diagramme structuré d’UML qui fournit
une représentation graphique de haut niveau de l'organisation de votre
application, et vous aide à identifier les liens de généralisation et de dépendance
entre les packages.
Jonathan Lucien
PRODUITBAT étant un vaste projet, il a été divisé en 4 pôles de gestion

(packages), qui sont décrit dans la figure présentée en dessous. En rappelant que
c’est la gestion des clients qui nous a été soumis comme projet.
Figure 7 : Diagramme de paquetages
5. Objectifs des domaines de gestions

Nous allons ici déterminer les objectifs de chacune des parties de
l’application dans le tableau ci-dessous.
Tableau 7 : Liste des objectifs

Tableau 7 : Liste des objectifs
Jonathan Lucien
Paquetage Objectif
AUTHENTIFICATION S'inscrire, se connecter
LIVREUR Livrer une commande
Traitement des commandes

Activer ou desactiver un produit
Administration des Modifier un produit

produits
GESTION ADMINISTRATIVES supprimer un produit
Création de catégories et sous catégories
supprimer un utilisateur
modifier les informations d'un utilisateur
Administration des clients
Activer ou desactiver un utilisateur
consulter les informations d'un utilisateurs
Soumettre un produit
modifier un produit
GESTION DES FOURNISEURS
supprimer un produit
mettre des produits en promotion
Consulter le catalogue de produit
Consulter les devis generer
Consulter les commandes
Rechercher un produit
modifier la quantité de produit dans le panier
Gestion du panier
Generer un devis
GESTION DES CLIENTS
Passer une commande
Chiosir le type de livraison
Gestion des commandes
Choisir methode de paiement
Generer une facture
Definir une adresse de livraison
Les adresses de livraison
Supprimer une adresse de livraison
6. Description textuelle des cas d’utilisation

Comme dit précédemment le travail qui nous as été soumis est la réalisation du
site vitrine de PRODUITBAT c’est-à-dire la partie qui est en interaction directe
avec le client. Cela implique qu’au niveau conceptuel nous nous concentrerons
uniquement sur le paquetage sur la « GESTION DES CLIENTS ».
Jonathan Lucien
Par conséquent, nous fournirons uniquement une description textuelle des cas
d'utilisation dans ce domaine pour assurer la conformité.
a. Cas « Identification »
Tableau 8 : Description textuelle du cas « S’identifier »

Tableau 8 : Description textuelle du cas « S’identifier »
Titre S'identifier
Acteur visiteur
Résumé le visiteur n'ayant pas encore un compte se connecte sur la plateforme

le visiteur se trouve sur l'interface d'incription de PRODUITBAT et est
Précondition
connecté a internet
1. Sur l'interface d'inscription 2. Le système analyse les informations et
l'utilisateur rempli un formulaire où il verifie que l'email est unique dans la base
renseigne : son nom et prenom , son de données.
numero, son email et un mot de passe 3. Le système envoie un code de
qu'il renseignera deux fois. verification a 5 chiffres au mail saisie.
Scénario nominal
4.L'utilisateur se rend dans sa boîte 6. Le système enregistre l'utilisateur dans
mail pour recuperer le code. la base de données.
5.L'utilisateur se rend sur l'application 7. Le système redirige l'utilisateur sur
pour saisir le code. l'interface de compte.
A1: les mots de passe ne sont pas identiques
A1 demarre au point 1 du scénario nominal,
1.1- le système informe de l'erreur et indique à l'utilisateur de corriger sa faute,
1.2- le scénario nominal reprend au poind 1
A2: l'email saisi n'est pas valide
Scénario alternatif 1.1- le système informe de l'erreur et indique à l'utilisateur de corriger sa faute,
A3: le code de verification expire
4.1- le système informe de l'erreur
4.2- l'utilisateur peut renvoyé un nouveau code.
Postcondition le visiteur devient un client de PRODUITBAT
b. Cas « Commander »
Tableau 9 : Description textuelle du cas « Commander »

Tableau 9 : Description textuelle du cas « Commander »
Jonathan Lucien
Titre Commander
Acteur Client
Résumé le client decide de commander ses articles
Précondition le client possede déjà des articles dans son panier

1. Le client valide sa selection des
articles, en appuyant sur un bouton.
2. Sur une autre interface le client
choisi d'etre livré ou non.
3. Le client peut choisir parmi ses
adresses, celle où il souhaite etre livrer.
4. Le client valide sa commande
5. L'utilisateur choisi son moyen de
Scénario nominal paiement.
6.Le client valide le paiement
7. Le système enregistre la commande.
8. Un message de s'affiche confirmant
la commande.
9. Le système redirige le client sur
l'interface d'acceuil.
10. le panier du client est vidé
A1: le clients n'as pas d'adresse de livraison
3.1- le client renseigne une nouvelle adresse de livraison avant de poursuivre
Scénario alternatif
A2: le solde du client est insufisant pour proceder au paiment
7.1- le système informe de l'erreur,
7.2- le scénario nominal reprend au poind 6,
Postcondition Le client recoit une facture pour sa commande
Jonathan Lucien
c. Cas « Ajout au panier »
Tableau 1010
Tableau : Description textuelle du textuelle
: Description cas « Ajout audu
panier
cas» « Ajout au panier »
Titre Ajout au panier
Acteur Client
Résumé le client ajoute des produits au panier
Précondition le client se trouve dans l'application PRODUITBAT

1. le client parcoure le catalogue
2. le client selectionne l'article qui
l'interesse
3. Affichage des détails du produit
Scénario nominal
4. Le client ajoute le produit au panier
en choisissans la quantité qu'il souhaite
Postcondition Le client peut passer une commande ou faire un devis
Jonathan Lucien
7. Elaboration des diagrammes de séquence

Le diagramme de séquence est une représentation de façon séquentielle du
déroulement des traitements et des interactions entre les éléments du système
et/ou de ses acteurs. Ce diagramme permet de décrire le scénario nominal de
chaque cas d’utilisation,
Les figures 8 à 10 présentent chacune un diagramme de séquence système pour
chaque cas d’utilisation identifié.
a. Cas « Identification »
Figure 8 : Diagramme de séquence cas

« Identification »
Jonathan Lucien
b. Cas « Commander »
Figure 9 : Diagramme de séquence

cas « Commander »
Jonathan Lucien
c. Cas « Ajout au panier »
Figure 10 : Diagramme de séquence

cas « Ajout au panier »
Jonathan Lucien
8. Diagramme de classes
Un diagramme de classes est un schéma représentatif des classes et de leurs
liens. Ce schéma représente aussi l’organisation des données et traitements de
l’application. C’est une représentation statique des objets du système qui
interagissent pour réaliser les cas d’utilisation.
En nous basant sur nos diagrammes de séquence, nous établissons ici le
diagramme de classes de notre système
Figure 11 : Diagramme de classe
Jonathan Lucien
CHAPITRE VI : OUTILS D’IMPLEMENTATION
L’implémentation d’une application passe impérativement par la sélection d’un

ensemble d’outils de développement adéquats. Dans notre cas, il a fallu tenir
compte de plusieurs contraintes techniques. En effet, PRODUITBAT étant une
application mobile, elle doit pouvoir s’utiliser sur les plateformes Android et
iOS.
Il nous faut donc une application pouvant répondre au mieux à cette contrainte
tout en restant performant pour chaque plateforme. De plus, une seconde
contrainte est relative au fait que l’application doit implémenter un système de
paiement. Enfin, les mises à jour de l’application ne devraient pas entraîner de
lourds déploiements. Les choix en matière d’outils d’implémentation ont donc
été faits dans ce sens.
I. CHOIX DE L’ARCHITECTURE DE DEPLOIEMENT

Tout système d'informations nécessite la réalisation de trois groupes de
fonctions : le stockage des données, la logique applicative et la présentation.
Ces trois couches sont reparties de différentes manières sur les postes de
déploiement d’un système. Ainsi, plusieurs types d'architecture existent
aujourd'hui mais celles cadrant au mieux avec notre travail sont l'architecture
dite n-tiers. Nous ferons donc une présentation de ces architectures dans
l'optique d'opter pour celle convenant au mieux aux besoins de notre application.
1. Architecture 1-tiers
Avec cette architecture, les trois couches s’exécutent sur une même machine, on
parle d’informatique centralisée. Les utilisateurs y accèdent par le biais de
simples terminaux. Ces terminaux sont du type passif car ils n’interviennent
nullement dans le traitement des données, ne servant qu’à transmettre, recevoir
et disposer à l’écran les données reçues.
Figure 12 : Architecture 1-tiers
Jonathan Lucien
Dans une architecture deux tiers, encore appelée client-serveur de première
génération ou client-serveur de données, le poste client se contente de déléguer
la gestion des données à un service spécialisé.
Ce type d'application permet de tirer parti de la puissance des ordinateurs
déployés en réseau pour fournir à l'utilisateur une interface riche, tout en
garantissant la cohérence des données, qui restent gérées de façon centralisée.
La gestion des données est prise en charge par un SGBD centralisé, s’exécutant
le plus souvent sur un serveur dédié. Ce dernier est interrogé en utilisant un
langage de requête qui, plus souvent, est SQL. Le dialogue entre client et
serveur se résume donc à l’envoi de requêtes et au retour des données
correspondant aux requêtes.
Cette architecture trois tiers, également appelée client-serveur de deuxième
génération ou client-serveur distribué sépare l'application en 3 niveaux de
services distincts, conformes au principe précédent :
 Premier niveau : l'affichage et les traitements locaux (contrôles de saisie,
mise en forme de données...) sont pris en charge par le poste client ;
 Deuxième niveau : les traitements applicatifs globaux sont pris en charge
par le service applicatif ;
Jonathan Lucien
 Troisième niveau : les services de base de données sont pris en charge par
un SGBD.
4. Choix d’une architecture

Au vu des descriptions en amont, des différentes architectures et compte tenu du
cadre professionnel et institutionnel du projet. Notre choix s'est porté sur une
architecture trois tiers puisque :
 Elle offre une grande marge d'évolution ;
 Elle est assez flexible et permet une meilleure répartition de nos
composants logiciels ;
 Elle offre la possibilité d'appliquer une sécurité à tous les niveaux de
manière indépendante, et permet la réduction des charges du poste client
ce qui le rend plus simple à manipuler pour les non-informaticiens ;
 C'est une architecture qui offre une grande fiabilité et disponibilité du
système.
Jonathan Lucien
II. FRONTEND
Le terme « frontend » désigne les éléments d’un site ou d’une application que
l’on voit à l’écran. Pour faciliter le développement de ces éléments, on utilise
généralement un Framework[W5]. Parmi les Framework frontend pour le
développement mobile, nous avons identifié trois (3) outils pouvant nous aider
dans la réalisation de notre projet :
 Flutter : Kit de développement d’interface utilisateur open source
développée par Google en 2017 avec les langages C, C++ et Dart. Utilisé
pour le développement des applications Android, iOS, Linux, Mac,
Google Fuchsia et le web à partir d’une seule base de code.
 React Native : Programmé en JavaScript, Java, C++, Objective-C et
Python par Facebook en 2015. Utilisé pour développer les applications
pour Android, iOS et UWP.
 Ionic : Framework open source créé en 2013 par Max Lynch, Ben Sperry,
et Adam Bradley. Permets de créer un code multisupport en utilisant des
outils Web comme HTML, CSS, JavaScript, afin de générer des
applications iOS, Android, Chrome, Windows Phone et bien d'autres.
Notre Framework frontend doit donc être un outil frontend complet et flexible
avec une bonne performance d’exécution.
De plus, pour les mises à jour futures de notre application, notre frontend doit
disposer d’une communauté robuste et du soutien des géants des technologies
pour s’assurer de sa pérennité.
Enfin, pour faciliter l’activité de maintenance, la plateforme doit offrir une
bonne documentation. Sur la base de toutes ces exigences, le tableau 10 suivant
présente une étude comparative de ces trois (3) technologies :
Jonathan Lucien
Tableau 11 : Comparative de technologies de

développement frontend
Tableau 11 : Comparative de technologies de développement frontend
Comme le montre le tableau ci-dessus, Flutter est la technologie la plus

complète des trois (3) aux vues de nos besoins. Et c’est elle que nous avons
choisie pour le développement de notre système.
Jonathan Lucien
III. BACKEND
Le terme « backend » désigne l’ensemble des éléments d’un système
informatique qui ne sont pas visibles à l’écran mais qui effectuent des services
en arrière-plan.
Afin de gérer correctement le nombre sans cesse croissant d’utilisateurs ainsi
que la quantité massive de données du projet PRODUITBAT, les technologies
backend doivent comporter une base de données robuste capable de gérer un
flux important de données.
- Laravel + MySQL : est un ensemble de composants PHP ainsi qu’un

Framework MVC (Modèle Vue Controller) libre écrit en PHP. Il fournit
des fonctionnalités modulables et adaptables qui permettent de faciliter et
d’accélérer le développement d’un site web.
- NodeJS 39 + Firestore 40 : dans ce premier cas de figure, la base de

données serait hébergée sur les serveurs de Google Firebase41. On aurait
donc une base de données NoSQL, accessible et modifiable grâce aux
APIs établis par Google.
- NodeJS + MongoDB43 : NodeJS semble être la bonne technologie

s’interfaçant avec MongoDB. En effet, MongoDB stocke des données
sous forme de collections et des collections sous forme d'objets, ce qui
s'intègre bien avec JavaScript et naturellement NodeJS qui n'est rien
d'autre que du JavaScript côté serveur ! MongoDB utilise JSON comme
format de document et NodeJS fonctionne aussi en termes de JSON. Par
conséquent, l'interaction est rapide entre les deux technologies.
Puisque nous sommes arrivés le train en marche au sein de l’entreprise

DEVISCADEAU SARL nous avons dû nous aligner sur les choix de l’entreprise
par soucis de conformité enfin de facilités les maintenances futures.
Et donc l’entreprise a opté pour une combinaisons PHP-MySQL en utilisant le
Framework Laravel.
Jonathan Lucien
IV. AGREGATEUR DE PAIEMENT

Un agrégateur de paiement est une entreprise qui vend une API qui est elle-
même connectée à d’autres API de paiement, comme les API de mobile money
ou les API de paiement par Carte Bancaire. Nous avons noté trois (03)
agrégateurs pour notre projet :
 CinetPay : fondé par 2 amis (Idriss MONTHE et Daniel DINDJI)
partageant une passion pour la technologie, l'entrepreneuriat et
l'inclusion financière. Lancée en 2016, la plateforme a plus de huit
(08) milliards de transactions. Il a un siège en Côte d’Ivoire ;
 SycaPay : Sa mission est simple : apporter une réponse concrète
qui prend en compte les besoins de l’ensemble des acteurs du
marché. Il a également un siège en Côte d’Ivoire ;
 HUB2 : HUB2 est une solution développée par CONNEKT4.
HUB2 est présent en Afrique de l’Ouest dans le but de proposer des
services de paiement innovants. Il a également un siège en Côte
d’Ivoire.
Encore une fois nous avons dû nous aligner sur le choix de l’entreprise qui est
CinetPay.
Ce choix a été motivé par les caractéristiques suivantes :
- La maturité dans les paiements en ligne de l’agrégateur ;
- Une sécurité accrue pour minimiser les risques de piratage ;
- Une bonne documentation pour l’intégration des services ;
- Un pourcentage de commission faible ;
- Une gestion clientèle de qualité.
Jonathan Lucien
V. BILAN DES OUTILS UTILISÉS

Le tableau ci-dessous résume l’ensemble des outils utilisés dans le
développement de l’application PRODUITBAT :
Tableau 12 : Technologies utilisées pour le développement

Tableau 12 : Technologies utilisées pour le développement de PRODUITBAT
de PRODUITBAT
TECHNOLOGIES ROLES VERSIONS PROPRIETAIRES SITES WEB
Frontend et
Flutter backend coté Flutter Google https://flutter.dev/
utilisateur
Backend coté
Laravel Laravel https://laravel.com/
serveur
Agrégateur de Idriss MONTHE et
CinetPay CinetPay https://cinetpay.com/
paiement Daniel DINDJI
Système de gestion
MySQL MySQL www.mysql.com
de base de données
Vs Code Ecriture du code Vs Code Microsoft https://code.visualstudio.com/
Jonathan Lucien
PARTIE III : REALISATION DE

L’APPLICATION
Dans cette partie nous présenterons à proprement parler les différentes interfaces
de l’application réalisée, ensuite nous effectuerons un bilan sur le
fonctionnement de l’application, et enfin une estimation du travail effectué.
Jonathan Lucien
CHAPITRE VII : PRESENTATION DES INTERFACES
Dans ce chapitre nous présenterons les interfaces maitresses de l’application à

l’aide de captures d’écran, qui seront suivi d’un bref résumé sur le
fonctionnement global de l’application.
I. PRESENTATION DES INTERFACES PRINCIPALES
Figure 15 : Interface d’accueil de PRODUITBAT

C’est cette interface qui s’affichera au démarrage de
l’application, il s’agit de l’interface d’accueil, il est possible
de voir sur cette interface : les publicités, les produits en
promotions, des illustrations des catégories, et les produits qui
composent le catalogue PRODUITBAT.
Jonathan Lucien
Figure 16 : Interface des catégories de PRODUITBAT

Cette interface présente les différentes catégories ainsi que les sous-
catégories et les soussous-catégories qui les compose. Cela a été fait
ainsi pour faciliter la recherche et la sélection du client, de sorte à
aller directement à la section qui l’intéresse sans perte de temps.
Figure 17 : Interface compte du client de PRODUITBAT

L’utilisateur après s’être authentifié, pourra avoir accès à cette
interface qui lui est dédiée. En effet cette interface montre un aperçu
des informations personnelles de l’utilisateur et fait un compte rendu
de l’activité de celui-ci sur l’application PRODUITBAT
Jonathan Lucien
Figure 18 : Interface des détails d’un Produit

Après recherche lorsque l’utilisateur sélectionne le produit qui
l’intéresse, c’est cette interface (dit « interface des détails ») qui
s’affichera ; elle affiche les différentes informations du produit.
Figure 19 : Logo de l’application PRODUITBAT
Jonathan Lucien
II. QUELQUES ACTIONS POSSIBLE SUR L’APPLICATION

PRODUITBAT
Figure 20 : Ajout d’un produit au panier

L’utilisateur peut ajouter le/les produit(s) de son choix au
panier ou a contrario l’enlever directement sur l’interface des
détails.
Figure 21 : Interface du panier

A partir de cette interface l’utilisateur peut soit générer
un devis, soit poursuivre sa commande.
Jonathan Lucien
Figure 22 : Validation de Commande

A partir de cette interface l’utilisateur a le choix d’être livré
ou non, peut choisir son adresse de livraison, ainsi que la
date de livraison. Il y’a afficher aussi les différentes
informations sur la commande du client.
Figure 23 : Choix de la méthode de paiement

Ici l’utilisateur fait son choix quant à son moyen de
paiement puis effectue son paiement.
Jonathan Lucien
Figure 24 : Recherche d’un produit

Pour aller plus vite dans sa recherche, l’utilisateur peut
directement chercher l’article qu’il souhaite en se servant de
la barre de recherche prévue à cet effet.
Figure 25 : Interfaces
d’authentification
Jonathan Lucien
CHAPITRE VIII : ESTIMATION DU PROJET
Pour l’évaluation du coût de notre application, nous allons utiliser le modèle de

base de la méthode COCOMO (Constructive Cost Model) car elle se trouve
adaptée à notre projet de type organique. Le tableau ci-dessous présente le
résultat du calcul de ce coût :
Tableau
Tableau 13financières
13 : Evaluation : Evaluation
du projet financières du projet
TEMPS COUT UNITAIRE

TACHES TOTAL(FCFA)
(JOURS-HOMMES) (FCFA)
Analyse et conception 20 20000 400000
Implementation 60 50000 3000000
Tests 30 20000 600000
Déploiement 10 30000 300000
COUT TOTAL 4300000
Jonathan Lucien
CONCLUSION
Le projet sur lequel nous avons travaillé tout au long de notre stage consistait à
développer la version mobile de la plateforme client de PRODUITBAT qui est
un services e-commerce de vente de matériaux de construction. Pour réaliser
cela, nous avons d’abord procédé à l’appréhension du fonctionnement du site, ce
qui nous a permis de mieux cerner le fonctionnement du système existant et de
comprendre les besoins des utilisateurs. Ensuite, nous avons fourni grâce à la
méthode UML, les diagrammes qui ont mis en exergue les données et les
traitements au projet. Et après une description des outils techniques choisis, nous
avons détaillé la réalisation de notre application.
Par ailleurs, ce projet a été d’un apport considérable, non seulement à notre
formation personnelle en matière de programmation informatique mais aussi à
notre intégration au milieu socio-professionnel. En outre, il a été le bienvenu car
il nous a permis d’approfondir nos connaissances en développement mobile
ainsi qu’en gestion de projets en équipe.
Finalement, nous nous réjouissons énormément d’avoir développé l’application
PRODUITBAT, néanmoins nous sommes conscients de la nature évolutive de
l’application qui aura certainement besoin de modifications et/ou améliorations
en vue de répondre aux besoins des clients de manière efficiente, à savoir
l’inclusion de la fonction du Bordereau Fournisseur qui permettra aux clients
d’avoir accès à des matériaux premium du catalogue PRODUITBAT, la gestion
du scan des commandes, l’amélioration de la sécurité et d’éventualité, des
fonctionnalités qui seront intégrer au fur et à mesures de l’évolution de
PRODUITBAT.
Jonathan Lucien
BIBLIOGRAPHIE
 [B1] - Dominique NANCI, Bernard ESPINASSE, Ingénierie des systèmes

d’information : MERISE deuxième génération, Vuibert, 4 e édition 2000,
538 pages ;
 [B2] - Pascal ROQUES, UML 2 par la pratique, Eyrolles, 5e édition 2006,
364 pages ;
 [B3] - Pascal ROQUES, Franck VALLEE, UML 2 en action : de
l’analyse des besoins à la conception, Eyrolles, 4e édition 2007, 381
pages.
 [B4] - Le Petit Larousse Illustré 2012,
 [B5] - TOUALY YERE JEAN REGIS, conception et réalisation d’une
plateforme de vente en ligne de matériaux de construction, 2020.
Jonathan Lucien
WEBOGRAPHIE
 [W1] - Historique de l’INP-HB. Site officiel de l’institut National

Polytechnique Félix Houphouët-Boigny [en ligne]. Consulté le
10/06/2022.
http://www.inphb.edu.ci/1/vues/presentation/index_historique.php
 [W2] - Interface de programmation. Wikipédia [en ligne]. Consulté le
12/06/2022. https://fr.wikipedia.org/wiki/Interface_de_programmation ;
 [W3] - Unified Process. Bawiki [en ligne]. Consulté le 19/06/2022.
http://www.bawiki.com/wiki/concepts/sdlc-process-models/unified-
process/ ;
 [W4] - https://fr.wikipedia.org/wiki/Processus_unifi%C3%A9
 [W5] - https://fr.wikipedia.org/wiki/Framework
Jonathan Lucien
TABLE DES MATIERES
PREFACE..................................................................................................................................I
DEDICACE..............................................................................................................................II
REMERCIEMENTS..............................................................................................................III
SOMMAIRE...........................................................................................................................IV
SIGLES.....................................................................................................................................V
LISTE DES FIGURES.........................................................................................................VII
LISTE DES TABLEAUX...................................................................................................VIII
AVANT-PROPOS..................................................................................................................IX
RESUME.................................................................................................................................XI
INTRODUCTION.....................................................................................................................1
PARTIE I : PRESENTATION DE LA STRUCTURE D’ACCEUIL ET DU THEME.............2
CHAPITRE I : PRÉSENTATION DE LA STUCTURE D’ACCEUIL.........................................................3
I. PRÉSENTATION DE DEVISCADEAU SARL................................................................................3
1. Contexte de création.......................................................................................................................3
2. Mission...........................................................................................................................................3
3. Domaine de compétence.................................................................................................................3
II. ORGANISATION ET SITUATION GÉOGRAPHIQUE DE L’ENTREPRISE...............................4
1. Structure organisationnelle.............................................................................................................4
2. Situation géographique...................................................................................................................4
CHAPITRE II : PRÉSENTATION DU PROJET ET PLANIFICATION......................................................5
I. PRÉSENTATION DU PROJET.........................................................................................................5
1. Contexte de réalisation...................................................................................................................5
2. Les objectifs....................................................................................................................................5
II. CAHIER DES CHARGES..................................................................................................................6
III. PLANIFICATION DES TACHES.....................................................................................................6
1. Liste des tâches...............................................................................................................................6
2. Diagramme de Gantt.......................................................................................................................7
PARTIE II : ETUDE APPROFONDIE DU PROJET...................................................................8
CHAPITRE III : ETUDE DE L’EXISTANT ET SPECIFICATION DES BESOINS...................................9
I. ETUDE DE L’EXISTANT.................................................................................................................9
1. Description de l’existant.................................................................................................................9
2. Critique de l’existant.....................................................................................................................10
II. SPECIFICATION DES BESOINS...................................................................................................10
1. Besoins fonctionnels.....................................................................................................................10
2. Besoins non fonctionnels..............................................................................................................11
CHAPITRE IV : METHODE D’ANALYSE ET DE CONCEPTION.........................................................13
I. MERISE............................................................................................................................................13
1. La démarche ou cycle de vie........................................................................................................13
2. La maîtrise ou cycle de décision...................................................................................................15
II. UML / PU..........................................................................................................................................16
Jonathan Lucien
1. Langage de modélisation unifié (UML).......................................................................................16

2. Le Processus Unifié (PU).............................................................................................................17
3. Les déclinaisons du PU.................................................................................................................18
III. ÉTUDE COMPARATIVE ET CHOIX DE LA METHODE D’ANALYSE...................................20
CHAPITRE V : CONCEPTION...................................................................................................................21
I. BRANCHE FONCTIONNELLE......................................................................................................21
1. Identification des acteurs..............................................................................................................21
2. Modélisation des diagrammes de contexte...................................................................................22
3. Diagramme des cas d’utilisation...................................................................................................25
4. Diagramme de paquetage.............................................................................................................26
5. Objectifs des domaines de gestions..............................................................................................27
6. Description textuelle des cas d’utilisation....................................................................................28
...............................................................................................................................................................30
7. Elaboration des diagrammes de séquence....................................................................................30
8. Diagramme de classes...................................................................................................................34
CHAPITRE VI : OUTILS D’IMPLEMENTATION....................................................................................35
I. CHOIX DE L’ARCHITECTURE DE DEPLOIEMENT.................................................................35
1. Architecture 1-tiers.......................................................................................................................35
4. Choix d’une architecture...............................................................................................................37
II. FRONTEND.....................................................................................................................................38
III. BACKEND.......................................................................................................................................40
IV. AGREGATEUR DE PAIEMENT....................................................................................................41
V. BILAN DES OUTILS UTILISÉS....................................................................................................42
PARTIE III : REALISATION DE L’APPLICATION................................................................43
CHAPITRE VII : PRESENTATION DES INTERFACES..........................................................................44
I. PRESENTATION DES INTERFACES PRINCIPALES.................................................................44
II. QUELQUES ACTIONS POSSIBLE SUR L’APPLICATION PRODUITBAT..............................47
CHAPITRE VIII : ESTIMATION DU PROJET..........................................................................................50
CONCLUSION.......................................................................................................................51
BIBLIOGRAPHIE................................................................................................................XII
WEBOGRAPHIE................................................................................................................XIII
TABLE DES MATIERES...................................................................................................XIV
Jonathan Lucien

Rapport Pfe 3a

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 Pfe 3a

Transféré par

Droits d'auteur :

Formats disponibles

11 République de la Côte d’Ivoire

MEMOIRE DE FIN DE CYCLE

En vue de l’obtention du Diplôme de Technicien Supérieur en Electronique,

REALISATION D’UNE APPLICATION MOBILE DE LA

Réalisé par : MASSONG CHARLES JONATHAN LUCIEN

ENCADREUR PEDAGOGIQUE : MAITRE DE STAGE :

Année Académique : 2021 – 2022

Ce mémoire de fin d’études est l’aboutissement de notre parcours dans

Il nous tient à cœur de dédier le travail réalisé aux personnes suivantes :

Nous tenons tout d’abord à remercier DEVISCADEAU SARL, et

PARTIE II : ETUDE APPROFONDIE DU PROJET...................................................................................8

PARTIE III : REALISATION DE L’APPLICATION................................................................................43

LISTE DES FIGURES

Figure 1 : Organigramme de DEVISCADEAU.....................................................................4

LISTE DES TABLEAUX

Tableau 1: Cycle de vie de merise.........................................................................................14

L’INP-CENTRE regroupe les écoles suivantes :

L’INP-SUD qui regroupe les écoles suivantes :

Le projet qui nous a été soumis vient du besoin de l’entreprise DEVISCADEAU

Mots-clés : PRODUITBAT, e-commerce, boutique, application,

Avec des progrès techniques considérables et une digitalisation de plus en

CHAPITRE I : PRÉSENTATION DE LA STUCTURE

I. PRÉSENTATION DE DEVISCADEAU SARL

II. ORGANISATION ET SITUATION GÉOGRAPHIQUE DE

Figure 1 : Organigramme de DEVISCADEAU

CHAPITRE II : PRÉSENTATION DU PROJET ET

II. CAHIER DES CHARGES

III. PLANIFICATION DES TACHES

L’organisation d'un projet est une activité qui consiste à prévoir

1. Liste des tâches

Quant à ce projet les taches à réaliser seront :

Le diagramme de Gantt est un outil de planification des tâches nécessaires pour

ETUDE DU PROJET 2 semaines

Figure 2 : Diagramme de GANTT

PARTIE II : ETUDE APPROFONDIE DU

CHAPITRE III : ETUDE DE L’EXISTANT ET

Figure 3 : Interface d’accueil de PRODUITBAT

Avec la mise en place du site vitrine PRODUITBAT, DEVISCADEAU SARL

II. SPECIFICATION DES BESOINS

indispensable d’y présenter les prix et les caractéristiques techniques de

 L’inscription et la connexion du client :

 L’ajout des produits au panier :

 Les modes de livraison :

 La fin de l’opération d’achat :

2. Besoins non fonctionnels

 La fiabilité : L’application doit fonctionner de façon cohérente sans

CHAPITRE IV : METHODE D’ANALYSE ET DE

Une méthode d'analyse et de conception informatique a pour objectif de

Tableau 1 : Cycle de vie de merise

Tableau 1: Cycle de vie de merise

C’est la représentation du domaine étudié à travers plusieurs modèles suivant un

Tableau 2 : Niveaux d'abstraction de MERISE

Tableau 2 : Niveaux d'abstraction de MERISE

2. La maîtrise ou cycle de décision

Tableau 3 : Cycle de décision de MERISE

Tableau 3 : Cycle de décision de MERISE

a. Les diagrammes statiques

 Le diagramme objets : représentation des instances de classes

 Le diagramme de composants : représentation des composants

 Le diagramme de déploiement : représentation des éléments

 Le diagramme des paquetages : représentation des dépendances

 Le diagramme de structure composite : représentation, sous

 Le diagramme de profils : spécialisation et personnalisation