OPTIMISATION DU TEMPS DE COURSE DANS UN SUPERMARCHE Avec Une Solution de SELF SCANNING

Dédicace
A MA FAMILLE.
i
Remerciements
L’accomplissement de ce travail a pu être possible grâce au soutien de plusieurs per-

sonnes :
— Dr. AZEUFACK Ulrich, pour sa supervision et ses conseils ;
— M. KAZE Roger, pour son encadrement et ses conseils ;
— M. GUIMEZAP Paul, Président Fondateur de l’IUC pour m’avoir permis d’avoir cette
formation d’ingénieurs ;
— M. NWOKAM Verlaine, Directeur de 3IAC pour son encadrement et ses démarches

mises en place pour cette soutenance ;
— Mme NOUBANKA Manuella, Ancienne Directrice de 3IAC pour sa généreuse collabo-

ration au cours de notre formation ;
— M. DJAMOU Dave, pour m’avoir donné ma chance, son soutien et son encadrement
professionnel ;
— M. KEPSEU DJOMO Gaspard, Directeur général d’Inet Consulting Sarl, pour m’avoir
permis de faire ce stage ;
— Tout le corps enseignant de l’Institut Universitaire de la Côte (IUC) pour leur aide,
leur enseignements et leurs encouragements ;
— Mes amis et camarades pour leur soutien.
ii
Avant Propos
Ce mémoire rentre dans le cadre de l’obtention du diplôme d’ingénieur de conception

informatique. Il étudie le moyen d’optimisation du temps de course dans les supermarchés
sur le territoire camerounais. L’idée de ce mémoire est venue du constat de congestion des
caisses observé dans les dits supermarchés (BAO, KADO, Spar, Carrefour, Super U) durant
les jours ordinaire ou les périodes événementielles, avec d’une part des clients possédant très
peu d’articles et d’autre part des clients avec de grand panier à se faire facturer. Ce qui génère
d’une part une perte de temps pour cette catégorie de client avec très peu d’articles (certain
quitte le magasin sans ses produits vu le temps de facturations de ces grands paniers).
D’autre part la catégorie ayant de grand panier mettent également plus de temps dans
le supermarché, car après avoir rempli son panier d’articles vient s’y ajouter le temps de
la facturation par unité au niveau de la caisse. Ce qui se voit problématique pour le chiffre
d’affaires des supermarchés. Il est important de noter également le risque élevé de propagation
de la COVID-19(qui fait son retour au Cameroun au moment de l’écriture de ce mémoire)
au sein des supermarchés cause de la congestion au niveau des caisses. Ce projet ce veut être
une solution efficace devant permettre :
— Aux différentes catégories de clients de réduire considérablement leur temps d’achat,

car les clients pourront effectuer eux même leur préfacturation via l’application Android
installée sur leur smartphone.
— De transférer si besoin sa facture à un compte distant pour effectuer une vérification

des éléments contenus dans le panier ou d’effectuer le paiement.
— De réduire le risque de contamination face à la pandémie COVID-19 qui refait son

retour au moment de l’écriture de ce mémoire.
— De permettre aux proches se trouvant l’étranger de payer les produits de leurs familles
au pays.
— De commander des articles depuis chez soi et se faire livrer cela à domicile.
iii
OPTIMISATION DU TEMPS DE COURSE DANS UN SUPERMARCHE avec une
Solution de SELF SCANNING
Bien que confronté aux difficultés, nous avons pu les contourner, afin d’obtenir des résultats
qui permettront à notre système d’entrer en vigueur. Étant donné que nous souhaitons
toucher tous les supermarchés, notre travail va s’appesantir sur le complexe de BAO.
Rédigé par NDANGA Jules iv

Résumé
L’avancée informatique de ces dernières années avait pour but de combler le fossé entre
le monde virtuel et le monde physique de l’information numérique. Cette vision a été ap-
pliquée à l’amélioration de la chaı̂ne d’approvisionnement dans le commerce de détail. Le
présent document fait office de mémoire de fin d’étude dont la problématique est appliquée
aux supermarchés du Cameroun (tels que le complexe Bao, Spar, Carrefour Market, Super
U. . .). En effet, le travail principal consistait à développer un système qui permettra aux
divers clients d’optimiser leur temps d’achats grâce au processus de préfacturation à partir
de leurs Smartphones. Pour ce faire, le client peut transférer le panier, si nécessaire, à un
compte distant pour s’assurer que tous les produits requis de la liste sont effectivement dans
le dit panier. Il peut également régler sa facture lui-même, ou la transférer à une tierce per-
sonne/utilisateur pour effectuer le paiement à distance via Orange Money, Mobile Money ou
carte visa. Cette solution vise d’une part à résoudre : le problème de file d’attente remarquée
régulièrement devant les caisses durant les jours ordinaires et les périodes évènementielles,
le problème de gain de temps et d’autre part de faciliter le processus de respect des mesures
barrières face à la pandémie de la COVID-19. Pour y parvenir, une analyse plus approfondie
de ce besoin a été faite, afin d’entrevoir la conception et la réalisation d’une application qui
permettra au client de scanner lui-même ces articles à partir du code barre et effectuer di-
rectement le paiement. Nous nous sommes dans un premier temps limité à l’implémentation
d’une solution pour le complexe de BAO et uniquement sur le système d’exploitation An-
droid. Cette implémentation a été précédée d’une modélisation à l’aide d’UML, adossé sur
la méthode Scrum Agile. Le résultat obtenu à ce jour est une application qui fonctionne à
74% des objectifs définis à l’avance. Toutefois, le travail se poursuit avec motivation puisque
ce qui est déjà fait est apprécié par le directeur technique d’Inet Consulting.
Mots-clefs : Code barre, Android, préfacturation, file d’attente,optimisation, supermaché,

self scanning.
v
Abstract
The computer advancement of recent years was intended to bridge the gap between the
virtual world and the physical world of digital information. This vision has been applied to
improving the supply chain in retail. The present document is a dissertation whose proble-
matic is applied to supermarkets in Cameroon (such as the Bao complex, Spar, Carrefour
Market, Super U...). Indeed, the main work consisted in developing a system that will al-
low the various customers to optimize their shopping time thanks to the pre-billing process
from their Smartphones. To do this, the customer can transfer the basket, if necessary, to
a remote account to ensure that all the required products from the list are actually in the
said basket. They can also pay the bill themselves, or transfer it to a third party/user to
make the payment remotely via Orange Money, Mobile Money or Visa card. This solution
aims on the one hand to solve : the problem of queues regularly noticed in front of the
cash desks during ordinary days and event periods, the problem of saving time and on the
other hand to facilitate the process of respecting the barrier measures against the COVID-19
pandemic. In order to achieve this, a more in-depth analysis of this need was carried out,
in order to envisage the design and implementation of an application that would allow the
customer to scan these items from the barcode and make the payment directly. Initially, we
limited ourselves to the implementation of a solution for the BAO complex and only on the
Android operating system. This implementation was preceded by a modelling using UML,
based on the Scrum Agile method. The result to date is an application that is 74% of the
predefined objectives. However, the work continues with motivation as what is already done
is appreciated by the technical director of Inet Consulting.
Keywords : Barcode, Android, pre-billing, queue, optimization, supermarket,self scan-

ning.
vi
Sommaire
Dédicace i
Remerciements ii
Avant Propos iii
Résumé v
Abstract vi
Sommaire vii
LISTE DES SIGLES ET ABREVIATIONS ix
Liste des figures x
Liste des tableaux xii
Introduction Générale 1
1 Etat de l’art 3
1.1 Supermarché . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Etude des systèmes de caisse actuels . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Théorie des files d’attente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5 Technologie de self Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.6 Étude de l’existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2 MATERIELS ET METHODES 33
2.1 Cahier de charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
vii
2.2 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.3 Étude Conceptuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3 IMPLÉMENTATION ET RÉSULTATS 92
3.1 Plateforme de développement mobile . . . . . . . . . . . . . . . . . . . . . . 92
3.2 Outils, technologies et résultats obtenus . . . . . . . . . . . . . . . . . . . . . 97
Références Bibliographiques 108
Table des matières 110
Rédigé par NDANGA Jules viii

LISTE DES SIGLES ET ABREVIATIONS
— API : Programmable Logic Controller
— CUP : Code produit universel
— HTTPS : Hyper Text Transfer Protocol Secure
— ISSN : Numéro de série international normalisé
— ISO : Organisation internationale de normalisation
— IDE : Environnement de développement intégré
— PDA : Assistance numérique personnelle
— POO : Programmation orienté Object
— QR Code : Code de réponse rapide
— RFID : Identification radiofréquence
— RE : Requirement Engineering
— SSL : Secure Socket Layer
— TLS : Transport Layer Security
— XP : eXtreme Programming
ix
Liste des figures
1.1 Le grand Bao Douala montée collège Saint-Michel Près de Chococam . . . . 4

1.2 Caddie Connecter de Caper . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 PDA smart shop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Pocket PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 File d’attente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.6 Démarche d’optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.7 Processus d’optimisation selon Asimow . . . . . . . . . . . . . . . . . . . . . 16
1.8 QR-Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.9 Comparaison entre un QR-code et un code barre . . . . . . . . . . . . . . . 18
1.10 Code-Barre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.11 Logo Smart Market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.12 Paiement et Enregistrement Amazon Go . . . . . . . . . . . . . . . . . . . . 25
1.13 Les caméras CIBO Express (Caméra de Vision nocturne infrarouge AHD
1920x1080Px) surveillent les achats Amazon GO . . . . . . . . . . . . . . . . 25
1.14 Disposition des capteurs et des cameras dans les magasins amazon Go . . . . 25
1.15 Application de super U Mon magasin U . . . . . . . . . . . . . . . . . . . . . 28
2.1 selfcheckout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.2 Rayon du grand Bao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3 Les temps moyens d’attente acceptable selon les clients . . . . . . . . . . . . 40
2.4 La fréquence à laquelle les clients viennent faire leurs courses . . . . . . . . 40
2.5 la fréquentation de ces 26 clients et la taille moyenne de leur panier . . . . . 41
2.6 Analyse SWOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.7 Diagramme de Gantt prévisionnel . . . . . . . . . . . . . . . . . . . . . . . 46
2.8 Formule Effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.9 Formule Temps de développement . . . . . . . . . . . . . . . . . . . . . . . . 54
x
2.10 Formule détermination nombres moyens de personnes pour le projet . . . . . 54

2.11 Formule du coût prévisionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.12 Les valeurs du manifeste Agile . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.13 Comparaison méthode classique et méthode Agile . . . . . . . . . . . . . . . 63
2.14 Rôle des acteurs de scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.15 Vue d’ensemble de la méthode Scrum . . . . . . . . . . . . . . . . . . . . . . 68
2.16 Diagramme UML 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.17 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 75
2.18 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
2.19 Diagramme de séquence scanner un produit . . . . . . . . . . . . . . . . . . 86
2.20 Diagramme de séquence supprimer produit . . . . . . . . . . . . . . . . . . . 87
2.21 Diagramme de composant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
2.22 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.1 Comparaison plateforme Native, Cross plateforme et hybride . . . . . . . . . 95

3.2 Architecture logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
3.3 Interface de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.4 Interface d’inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.5 Interface de réinitialisation du mot de passe . . . . . . . . . . . . . . . . . . 102
3.6 Interface de scannage du produit . . . . . . . . . . . . . . . . . . . . . . . . 103
3.7 Interface du Panier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Rédigé par NDANGA Jules xi

Liste des tableaux
1.1 Comparaison Code Barre et QR-Code . . . . . . . . . . . . . . . . . . . . . . 19

1.2 Comparatif de certaines solutions de l’étude de l’existant avec notre solution. 31
2.1 Chronométrage du temps moyen de passage et du panier des clients . . . . . 39

2.2 Évaluation et gestion des contraintes d’exécution du projet . . . . . . . . . . 47
2.3 Evaluation des risques et mesure de sécurités. . . . . . . . . . . . . . . . . . 50
2.4 Ressources humain du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.6 distribution des coefficients . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.7 résultats calculs méthode CoCoMo . . . . . . . . . . . . . . . . . . . . . . . 55
2.8 Présentation des AGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2.9 Description du cas d’utilisation choisir agence . . . . . . . . . . . . . . . . . 76
2.10 Description du cas d’utilisation scanné un produit . . . . . . . . . . . . . . . 77
2.11 Cas d’utilisation Ajouter produit au panier . . . . . . . . . . . . . . . . . . . 78
2.12 Description du cas d’utilisation Supprimer produit du panier . . . . . . . . . 79
2.13 Description du cas d’utilisation validé achats . . . . . . . . . . . . . . . . . . 80
2.14 Description du cas transférer panier . . . . . . . . . . . . . . . . . . . . . . . 81
2.15 Description du cas d’utilisation payé Orange Money . . . . . . . . . . . . . . 82
3.1 Outils de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

xii
Introduction Générale
L’innovation progresse rapidement dans tous les secteurs de l’industrie. Cette amélioration
et ce développement sont impératifs pour les industries. Certains sont à jour, d’autres
s’améliorent. Nous assistons déjà à l’ère de l’industrie dépendante de la technologie, où
la technologie joue un rôle clé dans les processus de fabrication. Ces nouvelles technologies
modifient le mode de fonctionnement des entreprises. Il est essentiel pour les supermarchés
qui se concentrent sur la fourniture d’un service rapide et fiable aux clients de suivre la
cadence.
Ces supermarchés ne cessent de croı̂tre chaque année au Cameroun, apportant avec elle
le problème de file d’attente à la caisse qui est de plus en plus croissant, les clients passant plus
de temps à la caisse de paiement que dans les rayons. Ceci est au cœur des préoccupations des
grandes surfaces de vente qui cherchent constamment de nouvelles solutions. Cependant il
est difficile de trouver un bon compromis entre la diminution de l’attente et les coûts que cela
pourrait engendrer. Plusieurs travaux scientifiques ont déjà été réalisé en occident dans ce
sens, mais il reste encore beaucoup à faire vu le contexte camerounais actuel. C’est pourquoi
nous nous sommes intéressés à la réduction du temps d’attente au niveau des caisses, ce
qui permettra au client de consacrer plus de temps au niveau du choix des articles dans les
rayons et de vérifier la facturation, afin de voir s’il a les moyens nécessaires pour payer.
L’objectif général ici est de réduire ou de supprimer le temps d’attente du client à la

caisse des supermarchés.
Comme objectif spécifique nous avons entre autres :
Pour le client :
— Permettre de faire les courses plus facilement et donc plus rapidement.
1
— Permettre à partir de l’application de s’orienter plus facilement à travers le supermarché

afin de trouver un produit.
— Permettre de dénicher plus facilement des bonnes affaires et promotions.
— Réduire le temps d’attente à la caisse.
— Permettre aux personnes âgées d’effectuer facilement les courses.
Pour les supermarchés :
— Donner une image moderne et innovante de leur enseigne
— Mettre en avant leurs promotions et vendre plus
— Économiser de l’espace et de l’argent
— Fidéliser les clients
— Faciliter le travail au niveau des caisses
Pour l’entreprise Inet Consulting :
— Faire connaı̂tre l’entreprise
— Agrandir son portefeuille client
Pour atteindre ses objectifs il sera intéressant pour nous de débuter par une revue de la
littérature, ensuite présenter les matériels et les différentes méthodes que nous allons utiliser,
faire une implémentation et enfin présenter une conclusion générale.
Rédigé par NDANGA Jules 2

CHAPITRE 1
Etat de l’art
Ce chapitre a pour but de faire le contour des différents concepts qui seront abordés dans
le projet pour avoir une idée de ce à quoi nous nous frotterons. Ici nous allons essayer de
comprendre les différents concepts qui seront abordés tout au long de la réalisation de ce
projet.
1.1 Supermarché
Afin de mieux comprendre la finalité du système que nous mettrons en place, nous nous
devons de le placer dans son contexte.
1.1.1 Définition
Un supermarché est un endroit où sont achetés et vendus, entre autres, des produits
alimentaires, d’hygiène et de soins personnels. La superficie varie entre 400 et 2500 mètre
[Carluer-Lossouarn, 2006].
3
Figure 1.1 – Le grand Bao Douala montée collège Saint-Michel Près de Chococam
1.1.2 Comment est née le premier supermarché ?
Clarence Saunders a été un pionnier en créant le premier supermarché au monde où l’idée
lui est venue de mettre des marchandises à vendre à la merci des acheteurs. Son objectif était
de gagner du temps et du travail pour le vendeur, et il a réussi. Ainsi naquit Piggly Wiggly
en 1916, la première chaı̂ne de supermarchés au monde dans laquelle le client pouvait acheter
et observer les produits et payer à la sortie [Carluer-Lossouarn, 2006].
1.1.3 Parcours d’achat du client
Les clients pénètrent dans l’établissement dans le but d’acquérir des biens pour leur
usage, qu’ils soient comestibles ou personnels. Ils le parcourent généralement avec un chariot
ou un panier pour pouvoir y loger tous les produits qu’ils souhaitent acheter. Les articles
sont organisés et distribués en sections qui ont été planifiées à l’avance et qui sont également
organisées selon les lignes de commercialisation pour obtenir une plus grande réussite com-

merciale. Par exemple, le fait qu’il existe certains produits en vue du consommateur au
détriment d’autres. Il est connu que les produits de première nécessité (œufs, lait, pain, pois-
son...) sont placés loin de l’entrée et sont répartis dans tout le supermarché de manière à ce
que le client puisse parcourir tout l’espace pour acheter plus d’épicerie pendant le trajet, par
exemple. Il y a aussi des exposants à la sortie, lorsque l’achat est à régler, avec des produits
tels que des bonbons, des chewing-gums, des piles, dont le but est l’achat impulsif pendant
que les produits passent en caisse. Dans les supermarchés, l’agencement, l’éclairage, l’ordre
et la distribution sont étudiés pour obtenir le plus grand effet sur les consommateurs et le
dernier objectif final est d’augmenter les ventes [Carluer-Lossouarn, 2006].
1.2 Etude des systèmes de caisse actuels

Zel Bianco a déclaré que les systèmes de caisse rapides étaient l’une des pièces les plus
importantes de la pièce du puzzle de la satisfaction client et que la dernière chose qu’un client
souhaite après avoir fait ses achats est de faire la queue pour payer [Bianco, 2014]. Le com-
portement d’achat du consommateur est influencé par de nombreux facteurs, notamment le
temps que le consommateur passe à faire la queue à la caisse. Les entreprises et les détaillants
qui utilisent des systèmes d’encaissement dans leurs activités dépensent des ressources pour
examiner les moyens d’améliorer les méthodes de paiement des clients [Musalem, 2013].
Il existe un besoin impérieux pour les entreprises de valoriser le temps des clients et
de mettre en place des systèmes de caisse plus efficaces afin d’améliorer l’efficacité des files
d’attente. Une enquête du Food Marketing Institute a révélé que 89% des acheteurs interrogés
ont indiqué qu’un processus de paiement rapide est l’une des priorités les plus importantes
dans leur choix d’un magasin qui répond à leurs attentes [Tomazelli, 2016].
1.2.1 Caisse automatique et caisse conventionnelle
Un développement relativement nouveau du processus de caisse au niveau des su-

permarchés a vu le jour à travers le libre-service, également connu sous le nom de self-
service, également appelé self-cashout ou self-scanning. Contrairement à la technique de

caisse conventionnelle qui est facilitée par un employé du supermarché qui aide le client
à enregistrer les produits, calcule le montant dû et accepte le paiement [Tycho, 2008]. Ce
nouveau processus d’encaissement est développé et introduit sur le marché afin de minimiser
les coûts de main-d’œuvre. Ce système de caisse innovant est appelé ”caisse automatique”
et permet au client d’effectuer la plupart des tâches de caisse sans l’aide d’un employé
[Bickers, 2009].
Ce concept efficace nécessite différents systèmes de caisse qui remplacent les caisses as-
sistées, du processus de caisse conventionnel. Il permet à un employé de magasin de s’occuper
de plusieurs systèmes de caisse et peut donc contribuer à réduire les coûts de main-d’œuvre.
L’avantage de ce nouveau processus de caisse est une plus grande intimité pour le client et
la perception d’une caisse plus rapide [Christopher, 2009]. Le magasin peut traiter plus de
clients en même temps et donc réduire les files d’attente, sans avoir à augmenter le nombre
de caissiers.
A - Assistants d’achat mobiles
L’accès aux applications, à l’internet et aux e-mails est considéré comme l’un des princi-
paux avantages de posséder un smartphone [Poushter, 2016].
Les applications mobiles qui permettent aux consommateurs d’interagir avec les pro-
duits du supermarché remonte à plusieurs années [Shintaro Okazaki, 2009]. Les premiers
prototypes étaient des dispositifs matériels personnalisés comme les assistants numériques
personnels (PDA) ou les ordinateurs de poche. Ils constituaient la plate-forme privilégiée
pour mettre en œuvre des prototypes de logiciels, qui ont ensuite été mis en œuvre sous
forme d’applications logicielles sur des téléphones mobiles. Certaines approches ont attaché
les assistants d’achat aux chariots ou aux paniers.
Dispositifs matériels
— AT and T Bell Laboratories a présenté un premier prototype expérimental d’un

système sans fil intérieur pour l’assistance personnalisée aux achats. Le système,
selon Schmidt (2015), se composait de serveurs dorsaux et d’un dispositif matériel

mobile qui pouvait être attaché à un chariot d’achat et présentait une interaction
vocale à l’aide d’un microphone et de casques. Il dirigeait les clients dans le ma-
gasin, fournissait des détails sur les produits qui les intéressaient grâce à son
écran intégré, effectuait des comparaisons de prix, indiquait les articles en solde
et réservait des listes de courses personnelles. Le système mettait également en
œuvre un lecteur de codes-barres.
— Selon Karpischeck (2012), l’initiative Future Store du groupe Metro a présenté

le système d’aide au shopping personnel (PSA). Personal Shopping Assistance
(PSA), un système composé d’une tablette PC avec une connexion réseau sans fil,
d’un écran tactile et d’un lecteur de code-barres. La tablette PC peut être fixée
sur le dessus d’un chariot d’achat et être personnalisée en scannant les cartes de
fidélité. Le PSA pourrait alors afficher les informations sur les produits et accélérer
la procédure de paiement en transmettant le contenu du panier à la caissière. Le
système a également renforcé le passage en caisse automatique et a été évalué par
des enquêtes auprès des clients [Kirthi Kalyanam, 2009]. Les utilisateurs de PSA
ont fait état d’un niveau élevé de satisfaction des clients et les ventes ont augmenté
grâce à l’utilisation du PSA. Des approches plus récentes ont également utilisé des
dispositifs matériels spécialisés pour mettre en œuvre des assistants commerciaux
mobiles dans des supermarchés.

Figure 1.2 – Caddie Connecter de Caper
Ordinateurs de poche
— Shopper’s Eye, un prototype idéaliste d’un agent logiciel basé sur la localisa-
tion et fonctionnant sur un PDA. et utilisant la localisation GPS et les objectifs
d’achat définis par l’utilisateur pour informer les utilisateurs de la disponibilité
et le prix des produits dans les magasins voisins a été présenté en 1998 par Fano
[Stephan Karpischek, 2009].
— Le projet SmartPad d’IBM a également été lancé et a permis d’offrir un accès

abondant au supermarché électronique et a fourni une plateforme pour gérer les
listes de courses à l’aide de PDA. Fleisch et Michahelles (2010) ont déclaré que
le Pocket Bargain Finder, un dispositif portable pour le commerce augmenté,
a été présenté lors de la première conférence internationale sur le commerce
électronique.

Figure 1.3 – PDA smart shop
— Ubiquitous Computing (HUC). Le prototype a été conçu pour scanner les codes-
barres des livres dans les librairies et trouver le meilleur prix accessible en ligne.
Une première évaluation a montré que la vitesse de la connexion Internet était le
facteur le plus limitant pour une large adoption par les utilisateurs. L’objectif de
ce travail était d’étudier l’effet prédit avec les applications mobiles actuellement
déployées pour les consommateurs dans les supermarchés.
— D’après Chan (2012), en 2001, un explorateur de projet au laboratoire des médias
du Massachusetts Institute de technologie (MIT) a travaillé sur des applications
qui associaient des services virtuels aux personnes, aux lieux et aux objets. Le
projet a mis en œuvre un assistant personnel d’achat (PSA) sur un Pocket PC
attaché à un panier d’achat. Les consommateurs pouvaient scanner les produits
à l’aide d’un scanner de codes-barres. Le système fournissait des informations
supplémentaires sur les produits scannés, telles que des informations nutrition-
nelles, des recettes et des recommandations de produits à l’aide d’une version
préliminaire d’un Object ONS (Object Naming Service) et de services web. Par la
suite, le système a été doté de fonctionnalités supplémentaires telles qu’un lecteur

RFID et des produits étiquetés avec des codes de produits électroniques (EPC) sur
les étiquettes RFID [Stephan Karpischek, 2009]. Selon Chan (2012) le système a
été évalué par des essais informels d’utilisateurs dans un supermarché. L’avantage
le plus important pour les clients était de voir le coût total des articles scannés.
Figure 1.4 – Pocket PC
B - Applications mobiles
Selon Ballagas (2007), le téléphone mobile a été le premier ordinateur véritablement

omniprésent. Shekar (2010) a présenté iGrocer, un prototype précoce d’un assistant d’achat
mobile mis en œuvre et fonctionnant sur un téléphone mobile. Le système était implémenté
en J2ME et lisait les codes-barres des produits avec un accessoire de lecture de codes-barres.
Il a été conçu pour aider les consommateurs à prendre des décisions d’achat sur le point de
vente en fonction de critères définis par l’utilisateur.
Adelmann et al. (2010) ont développé une boı̂te à outils rapide et fiable pour la lecture
des codes-barres, connue sous le nom de Batoo. Ses principales caractéristiques incluent

la possibilité de scanner les codes-barres sous n’importe quel angle. Les versions ultérieures
pouvaient même décoder des codes-barres dans des images floues, ce qui éliminait la nécessité
d’attendre l’autofocus de l’appareil photo. Karpischeck (2012) a comparé le Batoo à d’autres
scanners de codes-barres dans le cadre d’une une étude d’utilisateurs et a constaté que
Batoo était l’un des deux sur un total de 11 scanners de codes-barres mobiles avec une
fiabilité parfaite de 100 %. D’après Karpischeck (2012), l’autre lecteur de codes-barres avec
une fiabilité parfaite dans cette étude était ZXing.
Selon McMillan (2010), les recherches sur les assistants d’achat mobiles se sont jusqu’ici
concentrées sur des prototypes qui n’avaient pas été largement déployés et évalués à grande
échelle. Alors que d’autres applications mobiles ont fait l’objet de recherches à plus grande
échelle, tout comme l’utilisation des smartphones en général et que les chercheurs ont obtenu
de bons résultats en déployant des applications dans les boutiques d’applications(playstore).
1.2.2 Le processus de prise décision d’achat
Solomon et al. (2007) ont défini l’achat du consommateur comme une réponse à un besoin
où le consommateur subit une série d’étapes pour satisfaire ces besoins. Selon Kotler et Keller
(2008) l’achat du consommateur reflète le processus de prise de décision du consommateur,
dont les principales étapes sont l’identification du problème, la recherche d’informations,
l’évaluation des alternatives, la décision d’achat et l’après-achat. Solomon et al. (2007) ont
également expliqué que tous les processus de prise de décision n’étaient pas compatibles
avec ce modèle, car plusieurs facteurs externes pouvaient affecter la façon dont le consom-
mateurs progressent d’une étape à l’autre. Les achats sont considérés comme un processus
habituel de prise de décision. Les décisions relatives à la plupart des supermarchés exigent
un faible niveau de participation de la part des consommateurs, car elles sont fortement liées
à l’expérience d’achats antérieurs et aux routines d’achat [Solomon, 2007]. Les offres de pro-
duits des supermarchés et les autres environnements des magasins sont généralement associés
aux stimuli destinés à influencer le processus de décision du consommateur au moment de
l’achat.

Les clients sont généralement exposés aux présentoirs en magasin et aux catégories de
produits lorsqu’ils achètent. L’intensité de l’exposition étant influencée par plusieurs facteurs
contextuels tels que l’emplacement, le nombre d’allées, le type de déplacement et la partici-
pation à l’achat [Inman, 2014]. Les acheteurs sont motivés à l’achat par les stimuli auxquels
ils sont exposés en magasin. Ces stimuli sont influencés par un certain nombre de facteurs
tels que l’âge et le besoin d’un produit, l’impulsivité, le sexe, la taille du ménage, sans oublier
le revenu.
Maja (2014) a présenté une approche de l’utilisation des téléphones mobiles pour les
supermarchés. Elle a été divisée en quatre catégories : la publicité mobile (utilisation du
téléphone mobile par les détaillants), la technologie de localisation sans fil telle que le GPS
(pour ce repéré dans le supermarché), l’utilisation des téléphones mobiles lors dès l’achat
(pour avoir des informations sur certains produits) et les paiements mobiles.
Le marketing mobile par Bluetooth, qui appartenait principalement aux supermarchés,

mais cette forme de marketing à perdu peu à peu sa valeur lorsque les clients on commencer à
ne plus activé le Bluetooth du téléphone. D’après Maja (2014), la méthode la plus populaire
de marketing mobile avait été l’envoi d’offres promotionnelles et de ventes par SMS. Peu
à peu d’autres méthodes ont vu le jour comme l’utilisation des téléphones mobiles par les
clients pour rechercher le prix dans d’autres magasins en ligne, la liste d’achats sur téléphone,
le scan de QR et de codes-barres et bien d’autres encore.
La popularité des téléphones mobiles modernes a augmenté de manière très active. À

la fin de 2014, le pourcentage de Camerounais possédant un smartphone était passé de 9.8%
à 71% [BRM, ]. Wheeler et Jones (2011) ont déclaré que les détaillants ont remarqué un
potentiel massif dans le marketing mobile qui permettait l’acquisition de nouveaux clients et
le maintien de leurs clients. De nos jours, les entreprises commencent à explorer la référence
individuelle du consommateur pendant le processus d’achat.
Le développement technologique a permis aux détaillants de mettre en œuvre de nou-

veaux modèles commerciaux de stratégie de service à la clientèle qui comprenaient des solu-

tions de téléphonie mobile, comme le montre la figure 6. Selon Maja (2014), à l’avenir, les
supermarchés seront obligés d’intégrer l’utilisation des téléphones mobiles pour améliorer leur
relation avec les clients. Une recherche effectuée par KPMG International (2012) a déclaré
que les téléphones mobiles avaient une variété d’applications qui pourraient être utilisées
par les détaillants pour commercialiser leurs produits et tenir les clients informés des offres
spéciales, des arrivages de nouveaux produits et des ventes.
1.3 Théorie des files d’attente

Li et Han (2016) ont défini la file d’attente comme un phénomène omniprésent qui se
produisait principalement dans les supermarchés, les restaurants et les banques. Les gens
passaient un temps considérable à faire la queue et un long temps d’attente entraı̂nait une
expérience utilisateur épouvantable. Lane et Miluzzo (2010) ont déclaré que la gestion des
files d’attente est importante car elle permet de réduire l’allocation inefficace des ressources
et les pertes de revenus. Les téléphones mobiles constituent une plateforme attrayante pour
les applications axées sur les personnes [Rachuri, 2010].

Figure 1.5 – File d’attente
1.4 Optimisation
Parmi les problèmes rencontrés par le chercheur et l’ingénieur, les problèmes d’optimi-
sation occupent à notre époque une place de choix. Nous n’aborderons pas le problème de
l’optimisation d’un point de vue mathématique, mais simplement du point de vue générale.
L’optimisation c’est le fait de donner à quelque chose, à une machine, à une entreprise,
etc., le rendement optimal en créant les conditions les plus favorables ou en en tirant le
meilleur parti possible [(Auteur), 2021]. Il existe plusieurs types d’optimisation, notamment
l’optimisation du temps, du coût, de la main d’œuvre...etc.
Pour déterminer qu’elle serait l’axe d’optimisation que nous appliquerons aux super-
marchés nous avons eu à suivre la démarche présenté dans la figure si après :

Figure 1.6 – Démarche d’optimisation
Au ressortir de cette démarche, nous avons déterminé que nous pouvions optimisé le
temps de course des clients dans les supermarchés en réduisant le temps d’attente passé à la
caisse. Ce qui par ricochet augmentera les gains financiers des supermarchés.
Afin d’identifier qu’elles solutions nous utiliserons pour l’optimisation du temps de

course des clients dans les supermarchés, nous avons suivie un processus d’optimisation en
trois étapes : analyse, synthèse et évaluation [Balachandran, 1993].

Figure 1.7 – Processus d’optimisation selon Asimow
1.5 Technologie de self Scanning

Il existe un certain nombre de technologies de scannage utilisées aujourd’hui, dont cer-
taines sont dédiées au scannage par des appareils spéciaux ou au scanne avec des appareils
mobiles. La liste ci-dessous présente les technologies utilisées pour être scanner depuis des
dispositifs mobiles. Un dispositif mobile peut être utilisé à la place d’un dispositif de lecture
dédié, doté d’un lecteur intégré qui transmet des fréquences radio sur une étiquette ou d’une
caméra de dispositif appareil photo du dispositif mobile pour scanner un code à barres.
1.5.1 Technologies de scannage basées sur les téléphones mobiles
Ces technologies de scannage comprennent des processus de numérisation qui reposent

sur un utilisateur qui numérise physiquement des articles à l’aide d’un smartphone portable.
Certaines de ces technologies comprennent : QR-Code et le code barres.

A - QR-Code
QR-Code est l’abréviation de Quick Response Code. Selon Johannes Ullrich (2011), il
s’agit d’un type de code-barres matriciel ou bidimensionnel conçu initialement pour l’indus-
trie automobile au Japon. Un code à barres est défini comme une étiquette optique lisible
par une machine et contenant des informations sur un article auquel elle est attachée. La
figure suivante montre la structure du QR-Code [Bhardwaj, 2016] :
Figure 1.8 – QR-Code
Les QR-Code pouvaient être utilisés sur une variété de systèmes d’exploitation de
téléphone mobiles. Les appareils mobiles prennent en charge la redirection d’URL qui per-
met aux codes d’envoyer des métadonnées aux applications sur l’appareil. De nombreuses
applications mobiles gratuites permettaient de scanner les QR-codes et d’établir un lien di-
rect avec des URL externes [SO, 2010]. Un QR-code est une sorte de symbole bidimensionnel
développé par Denso Wave. La figure suivante montre la comparaison entre un QR-code et
un code à barres traditionnel. Cette technologie a été lancée en 1994 dans le but d’être un
symbole facilement interprétable par un scanner [Wave, 2014].

Figure 1.9 – Comparaison entre un QR-code et un code barre
Les QR-codes et les codes-barres sont des codes appartenant au domaine public, ce qui
signifie qu’ils sont libres de droits et qu’on à pas besoin de payer une licence pour les utiliser.
Les spécifications publiées et les exigences d’impression pour chaque code sont disponibles
auprès de l’organisation internationale de normalisation (ISO). Les normes ISO correspon-
dante pour chacun sont les suivantes :
— Les exigences relatives aux codes-barres sont spécifiées dans la norme internationale
ISO/IEC 16022.
— Les exigences relatives aux QR-codes sont spécifiées dans la norme internationale
ISO/IEC 18004.

Tableau 1.1 – Comparaison Code Barre et QR-Code
Type de code Code Barre ou Code de QR-code

donnée Matrix
Numérique : 3116 Numérique : 7089

Caractères alphanumériques : Caractères alphanumériques :
Capacité
2335 4296
maximale
Octets : 1556 Octets : 2953
10Ö10 cellules min 21Ö21 cellules min
144Ö144 cellules max 177Ö177 cellules max
Dimensions 1D 2D
Algorithme de Reed-Solomon Algorithme de Reed-Solomon
Capacité de correction d’erreurs La correction d’erreurs pour les
Correction
de 25 à 33% QR-codes peut être ajustée pour
des erreurs
obtenir une plus grande capacité
de correction d’erreurs.
Traçabilité de la chaı̂ne logis- Informations supplémentaires sur
tique, y compris le marquage di- le produit
Application rect comme pour les composants
électroniques
Lutte contre la contrefaçon via la Communication sur réseaux so-
sérialisation, par exemple pour les ciaux
emballages pharmaceutiques
Les QR-Codes utilisent quatre modes d’encodage standardisés, à savoir : numérique,

alphanumérique, octet ou binaire, pour stocker efficacement les données. Selon Stechz (2012),
les QR-codes sont constitués de points carrés noirs disposés dans une grille en forme de carré
sur un fond blanc. Ces points pouvaient être lus par des dispositifs d’imagerie tels que

des caméras et des scanners dédiés. L’image capturée est traitée en utilisant la correction
d’erreur Reed Solomon jusqu’à ce qu’elle puisse être interprétée de manière appropriée. Les
données ont été extraites des motifs des images présentées sur leurs composantes verticale et
horizontale. La quantité de données stockées dans un symbole de QR-Code dépend du type
de données, de la version et du niveau de correction des erreurs.
Utilisation des QR-codes : Selon Bhardwaj et Kumar (2016), les QR-codes étaient
plus couramment utilisés dans la publicité grand public. L’utilisation d’un smartphone
était privilégiée en tant que scanner de code qui pouvait convertir le code en données
utiles telles que l’URL standard d’un site web. Ainsi, l’utilisateur n’avait plus besoin
de taper l’URL dans un navigateur web. Les QR-codes ont également été utilisés dans
d’autres applications telles que le suivi commercial des marchandises, par exemple la
billetterie des spectacles et des transports, le marketing de produit ou de fidélisation
et l’étiquetage des produits en magasin.
Fonctionnement des QR-codes : Le QR code peut paraı̂tre assez complexe à com-

prendre pour les personnes qui ignorent tout de sa codification. En réalité, un QR code
est composé d’un élément qui génère le code et d’un autre qui contient le code et que
l’utilisateur doit scanner. Les motifs des QR codes sont binaires. Pour les décrypter et
accéder à l’information stockée, il faut utiliser un smartphone, une tablette ou un lec-
teur adapté. L’appareil photo du téléphone mobile ou le lecteur parvient à reconnaı̂tre
un QR code standard à travers l’élément qui génère le code (les 3 carrés). Puis, le lec-
teur de codes QR scanne le code en le décomposant en une grille constituée de plusieurs
petits carrés. Il attribue ensuite une valeur à chaque carré en fonction de sa couleur
(noire ou blanche) [Wave, 2014].
B- Code Barre
Comme l’ont souligné Kato et Tan (2007), les codes-barres ont été conçus pour transporter
un grand nombre de données. Les téléphones mobiles sont passés d’un appareil de communi-
cation vocale mobile à ce qu’ils sont aujourd’hui, une plate-forme informatique multimédia
mobile. Le développement récent de la technologie et l’intégration de ces deux éléments ont
donné lieu à des applications intéressantes et diverses des codes à barres dans les systèmes

d’applications mobiles et les services de commerce électronique. Kuha et Chintho (2014) ont
déclaré que dans les systèmes de commerce mobile, les codes à barres pourraient être utilisés
pour soutenir les activités de prévente, d’achat et de vente, et d’après-vente pour les tran-
sactions commerciales mobiles. Les codes-barres pourraient être utilisés comme publicités,
coupons ou matériels de promotion qui peuvent être capturés et décodés par l’utilisateur avec
des appareils mobiles. De plus, les codes-barres permettent aux appareils mobiles de devenir
un dispositif de point de vente qui lit le code-barres et facilite les transactions de paiement,
les codes-barres pourraient être utilisés par les clients comme un reçu ou une preuve d’achat
pour avoir accès aux biens et services achetés avec leurs téléphones mobiles [Zhang, 2014].
Application du code-barres dans les supermarchés : Selon Kuha et Chintho

(2014), les gens ont progressivement pris conscience de l’importance du code-barres et
de sa grande valeur d’application dans les supermarchés et magasin. Et cela pour les
raisons suivantes :
— Les code-barres constituent un nouveau canal de saisie efficace pour les clients
mobiles équipés d’appareils photo intégrés.
— Les code-barres deviennent une approche populaire pour présenter des données
mobiles sémantiques dans des formats standard.
— Les code-barres favorisent une nouvelle approche interactive et efficace entre les
clients mobiles et les systèmes d’application sans fil.
— La technologie des codes-barres peut être et est utilisée dans diverses applications
du commerce mobile.
Fonctionnement des codes-barres : C’est à ses esthétiques zébrures que le code-

barres doit son nom : les traits noirs et blancs qui le composent symbolisent des ca-
ractères, selon un code propre à chaque norme. La lecture du code-barres se fait grâce
à un scanner ou à une application mobile de scannage. Il s’agit d’un simple code bi-
naire (des 0 et des 1) : un trait blanc (0) ou un trait noir (1). Pour étiqueter les
produits, la grande distribution utilise la norme EAN 13(European Article Numbering
à 13 chiffres), sans aucun doute la plus familière. Le code-barres contient alors deux
nombres de six chiffres, chaque chiffre étant représenté par une série de sept traits. Le

premier nombre correspond à la référence du fabricant, le second à celle de l’article.

Mais d’autres normes existent, en fonction des secteurs d’activité, certaines ajoutant
le codage des lettres à celui des chiffres. Tout comme de nombreuses variantes sont
apparues. [Zhang, Ren & Xing, 2014]
Figure 1.10 – Code-Barre
1.6 Étude de l’existants

Il y a eu une introduction et une conception d’une nouvelle forme de supermarché où
les clients ont obtiennent des informations détaillées sur les produits et un processus de
paiement accéléré sans intervention humaine. Zheng et Meagher (2009) ont déclaré que l’une
des contributions qui a été apporté sur les supermarchés intelligents est le concept de ”payer
n’importe quand n’importe où” qui a donné aux clients une liberté complète lors de la
vérification et d’éliminer le temps perdu dans les files d’attente.
1.6.1 SMART MARKET
Roussos et College (2007) ont présenté une nouvelle forme de technologie de supermarché
intelligent, appelée Smart Market (SMart), qui poursuit trois objectifs :
— Le premier objectif est de permettre aux clients d’accéder facilement aux informations
sur les produits ou à d’autres fonctions du supermarché.
— Le deuxième objectif est d’offrir un passage en caisse rapide et souple, car le processus
actuel de passage en caisse est systématiquement considéré comme l’un des aspects les

plus négatifs des achats en supermarché.
— Le troisième objectif est d’améliorer l’efficacité de la gestion et de réduire les coûts de

main-d’œuvre.
Zheng et Meagher (2009) ont fourni un scénario pour expliquer davantage le fonction-
nement du SMart : un utilisateur se rend au terminal de service (ST) d’un supermarché et
saisit le numéro du produit. Le SMart affiche alors l’emplacement du produit et l’itinéraire
sur l’écran du ST. L’utilisateur doit ensuite localiser le produit qui possède une étiquette
RFID (Radio frequency identification) qui sera lue par le terminal de service. Le ST affiche
alors les informations sur le produit et les paiements qui suivent.
Figure 1.11 – Logo Smart Market
1.6.2 BarCroid
Benedict et Pacana (2016) ont conçu une application appelée BarCroid Scanner qui vi-
sait à aider les achats fastidieux et peu pratiques. Elle a été développée pour une meilleure

amélioration de l’expérience d’achat et des propriétaires de supermarchés également. Bar-

Croid était capable de générer des rapports et l’inventaire d’un supermarché, ce qui était une
grande aide pour les propriétaires de supermarchés. Il présente les caractéristiques suivantes :
scanne de codes-barres, informations sur les produits, disponibilité des produits, emplace-
ment dans le magasin, calculateur de budget, historique, inventaire, rapports générés et
mobilité.
Limites
Nous pouvons citez entre autres :
— De nombreux bugs
— Produits annulés après paiement
— Les commandes n’arrivent pas au complet, ce qui rend le service de livraison défectueux
— Service client injoignable
1.6.3 Amazon Go
Amazon a récemment introduit ce que de nombreux observateurs du secteur appellent

un ”changement de jeu” intitulé Amazon Go. Le tout nouveau concept d’Amazon permet
aux acheteurs de profiter d’un maximum de commodité en faisant leurs courses sans avoir
à s’arrêter et à passer à la caisse [Kasavana, 2017]. Ce processus, connu sous le nom de
” walkout shopping ”, permet de gagner du temps et de l’argent. Amazon Go n’a pas de
caisses ni de files d’attente car les clients n’ont pas besoin de passer à la caisse. Au lieu
de cela, ils s’enregistrent dans le magasin en utilisant une application Amazon Go sur leurs
smartphones. Des capteurs placés dans le magasin détectent ce que les clients prennent dans
les rayons, et les clients sont automatiquement facturés sur leur compte Amazon lorsqu’ils
quittent le magasin. On dit que c’est comme le vol à l’étalage, sauf que les clients paient les
produits lorsqu’ils sortent du magasin [Thoet, 2016].

Figure 1.12 – Paiement et Enregistrement Amazon Go
Figure 1.13 – Les caméras CIBO Express (Caméra de Vision nocturne infrarouge AHD
1920x1080Px) surveillent les achats Amazon GO
Figure 1.14 – Disposition des capteurs et des cameras dans les magasins amazon Go
Sécurité au sein des magasins Amazon go
La première chose qui vous accueille à la porte d’entrée est une rangée de trois tourniquets,
qui sont activés à l’aide d’un code QR unique trouvé dans l’application Amazon Go. Ces

tourniquets gardent ceux qui ne sont pas configurés avec l’application Amazon Go hors du
magasin tout en laissant ceux qui ont téléchargé l’application et l’ont liée à leur compte
Amazon. Ces tourniquets enregistrent les utilisateurs qui se trouvent dans le magasin et
quand ils partent.
Lorsqu’un utilisateur entre dans le magasin, il est encouragé à ramasser et à remettre

autant d’articles qu’il le souhaite. Lorsqu’un article est récupéré, le magasin l’ajoute auto-
matiquement au panier virtuel de l’utilisateur. S’il est remis en rayon, il sera supprimé du
panier d’achat en ligne. Lorsque le client quitte le magasin, il reçoit généralement un reçu
de son achat en quelques minutes seulement.
Le plafond du magasin est recouvert de caméras qui surveillent chacun de vos mouve-
ments pendant que vous êtes dans le magasin. À l’aide du code QR que vous avez scanné au
tourniquet, les caméras peuvent aider à enregistrer quel utilisateur récupère quel article. Les
caméras fonctionnent en tandem avec les tourniquets pour s’assurer que ce avec quoi vous
quitté le magasin correspond à ce que vous payez.
Amazon n’en dira pas beaucoup plus sur le fonctionnement de ce système de vidéosurveillance,
si ce n’est qu’il implique des logiciels sophistiqués de vision par ordinateur et d’apprentissage
automatique. Cela signifie qu’il n’y a pas de puces de suivi sur la marchandise dans le maga-
sin. C’est le placement des articles sur les étagères et les caméras au plafond qui permettent
de savoir qui a ramassé quoi.
Certains journalistes ont tenté, avec la permission d’Amazon, de voler à l’étalage du

magasin. Nick Wingfield du New York Times a écrit qu’il avait tenté de voler un pack
de quatre de soda à la vanille tout en l’enveloppant dans un sac à provisions avec celui-ci
toujours sur l’étagère, puis en le mettant sous son bras en sortant du magasin. Son expérience
a échoué et quelques minutes plus tard, il a reçu une notification indiquant qu’il avait été
facturé pour le soda [Shepard, 2018].

Limites
— Obligation de se connecter avant de pouvoir scanner les produits
— Problème de confidentialités des données
1.6.4 Mon Magasin U
C’est une application qui permet aux clients de scanner des produits dans les rayons des
supermarchés Super U, de les préfacturés (en ayant un visuel sur le contenu et le montant
de leur facture) et par la suite d’effectuer le paiement via sa carte Super U ou en espèce.
L’application est disponible en version Android et iOS. Néanmoins des limites sont observées
de par nos propres tests et les commentaires laissées par les utilisateurs sur Play Store.

Figure 1.15 – Application de super U Mon magasin U
Limites
— Connexion à l’application instable
— L’application a des difficultés pour sauvegarder le mot de passe
— D’après les commentaires laissés sur Play Store, U scanning est inopérante (difficulté
à payer avec sa carte Super U intégré à l’application, de fausses informations sur les
remises et promotion

— N’est pas encore intégré dans les supermarchés Super U du Cameroun
1.6.5 Limites de ces solutions conte tenue du contexte camerou-

nais
Ces différentes solutions ont plusieurs limites étant donné notre contexte camerounais
actuel. Quelques-unes de ces limites sont entre autres :
— Pour le paiement il est nécessaire d’avoir soit un compte bancaire ou une carte de
crédit.
— Les applications d’Amazon go ou de Smart Market nécessite des smartphones ayant les
derniers version Android (9 à 12), ce qui posera problème étant donné que la majeure
partie de la population est des smartphone Android, la plupart sont encore à des
anciennes version (4 à 7).
— Ce système est ouvert à tous les clients. Permettre à tous les d’avoir accès à ce système
dans les supermarchés au pays serait problématique contenu de la mentalité de certains
clients.
1.6.6 Positionnement de la solution envisagé
La fidélisation de la clientèle est un facteur de réussite pour le bon développement com-

mercial d’une entreprise quelconque. Il s’agit de fluidifier le passage des clients dans les
rayons, de simplifier aux maximum le processus de paiement ou de facturation. Donner
la possibilité aux clients de réaliser leu factures via l’application, de transférer si besoin
la facture à un compte distant pour le contrôle, permettre à ceux-ci de gagner un temps
considérable en effectuant rapidement leurs achats sur place ou par l’intermédiaire d’une
tierce personne.
Aux vues des limites énumérées plus haut lors de l’étude de l’existant, sans entrer dans
le cadrage du projet, nous pouvons positionner notre solution qui vient non seulement offrir
à aux clients une plus grande facilité d’utilisation, mais aussi de mieux garantir leur sécurité

en ces temps de COVID-19. Elle intègrera les fonctionnalités citées plus haut en addition
aux fonctionnalités innovants.

Tableau 1.2 – Comparatif de certaines solutions de l’étude de l’existant avec notre solution.
Eléments Mon Magasin U AMAZON GO Solution Final

Nom Application Mon Magasin U Amazon Go Scan and Go
Nationalité Française Amercaine Camerounaise
Type de concurrent National National Aucun pour le moment
Version minimum Android 7.1 Android 9.0 Android 4.0
Application Android Oui Oui Oui
Application iOS Oui Oui Prochainement
Création du compte Oui Oui Oui
Authentification Oui Oui Oui
Lecteur de scan Oui Oui Oui
Flash Non Oui Oui
Lecteur Code Barre Non Oui Oui
Lecteur QR Code Non Oui Non(sera introduit par la
suite)
Panier Oui Oui Oui
Modification du pa- Oui Oui Oui
nier
Suppression du Panier Oui Oui Oui
Historique Oui Oui Oui
Carte de fidélité Oui Non Oui
Réduction offerte Oui Oui Oui
Paiement intégré Oui Oui Oui(ajout des paiements lo-
caux telque Orange Money
et Mtn mobile money)
Transférer le panier Non Non Oui
Paiement distant Non Non Oui
Ergonomie Moyenne Bonne Bonne
Lisibilité textuelle Oui Oui Oui

Au vu de ce qui précède, pour un résultat optimal, il est judicieux pour nous de procéder
à un cadrage du projet.
Le but de ce chapitre étant de faire une revue de littérature pour présenter les concepts
qui seront abordés dans ce projet, nous avons fait le tour des notions et concepts et nous
sommes à présent armés de connaissances qui nous seront utiles pour la suite du projet.

CHAPITRE 2
MATERIELS ET METHODES
Il s’agit d’une description des techniques choisies pour atteindre les objectifs du système
proposé. Il s’agit de décrit les méthodes utilisées pour mener la recherche, la façon dont la
solution a été mise en œuvre, les outils et les techniques utilisés.
2.1 Cahier de charges
2.1.1 Context
La vision de la technologie consiste à combler le fossé entre le monde virtuel et le

monde physique de l’information numérique. Ces dernières années, cette vision a été ap-
pliquée à l’amélioration de la chaı̂ne d’approvisionnement dans le commerce de détail et à
l’amélioration de la manutention des marchandises dans la logistique grâce à la radiofréquence
(RFID) comme technologie motrice. Plus récemment, son intérêt pour les utilisateurs quoti-
diens a été progressivement reconnu [Ropraz, 2008].
Les applications et les appareils mobiles offrent aux supermarchés bien plus que la
simple possibilité d’entrer en contact avec les consommateurs. Les appareils mobiles offrent
notamment la possibilité d’associer les fonctionnalités du téléphone, l’interaction et la re-
cherche d’informations pendant l’utilisation d’un produit ou les achats en magasin. Un appa-
reil mobile est le compagnon permanent d’un client, un accès à la relation entre le détaillant
et le consommateur. Cela fait de l’appareil mobile un canal complémentaire de la vente au
supermarché physique et de la vente à distance [Shankar et al., 2010].
Arvidson (2011) a déclaré qu’Internet a intensément transformé le visage du commerce

des supermarchés, en donnant aux consommateurs d’énormes quantités d’informations pour
prendre des décisions d’achat et en créant une plateforme permettant aux consommateurs de
donner leur avis aux détaillants et aux marques sur la qualité de leurs produits et services.
33
Les consommateurs peuvent échapper complètement à un magasin de détail tradition-

nel en associant les prix et en lisant les avis d’autres utilisateurs en ligne avant d’effectuer un
achat. Les consommateurs utiliseraient les appareils mobiles et les sites de réseaux sociaux
pour les aider à prendre leurs décisions. Chacune de ces tendances a rendu la survie des
supermarchés physiques plus difficile à moins qu’ils ne s’adaptent et apprennent à utiliser
Internet [Lee, 2017].
Amazon a récemment fait la publicité d’un système de selfcheckout à la pointe de la

technologie qui utilise la vision par ordinateur, des algorithmes d’apprentissage profond et
la fusion de capteurs. L’entreprise envisage que les clients d’Amazon Go puissent choisir ce
qu’ils veulent dans les rayons et repartir avec, les articles étant automatiquement facturés
sur leur compte Amazon [Kennedy, 2016].
Figure 2.1 – selfcheckout
La main-d’œuvre est le coût les plus importants supermarchés, en plus des produits
vendus, et les épiciers prennent déjà des mesures pour rendre les caissiers obsolètes grâce
aux caisses automatiques. Amazon a modifié le marché du travail du supermarché en mini-
misant la main-d’œuvre [Jake , 2018]. De plus, une évaluation réalisée par CISCO Internet
Business Solution a montré que les principales raisons pour lesquelles les clients utilisaient
les innovations technologiques étaient les suivantes :
— Gagner du temps (47%), trouver le coût le plus abordable (63%),

— Trouver une combinaison exceptionnelle (26%) et trouver la valeur et la meilleure

qualité (25%).
2.1.2 Énoncer du problème
L’une des plus grandes difficultés auxquelles les gens sont confrontés dans les super-
marchés est la longueur des files d’attente aux caisses. ACox (2015) a mené une enquête
auprès de 2 500 personnes pour connaı̂tre leurs habitudes d’achat au supermarché. Cela à
montrer que les longues files d’attente aux caisses sont un problème majeur et qu’il n’existe
pas de technologie efficace pour y remédier au Cameroun. Les clients finissent généralement
par abandonner les files d’attente et certains sont immédiatement rebutés par les longues files
d’attente lorsqu’ils entrent dans les supermarchés [Barclays, 2015]. Certains des problèmes
qui entraı̂nent longues files d’attente lors du passage en caisse sont les méthodes de paiement
proposées dans les supermarchés, telles que l’argent liquide, l’utilisation de la carte de crédit
et le paiement mobile. Il y a généralement des retards soit de la part du client du client ou
du supermarché qui facilite ces retards.
2.1.3 Objectifs de la recherche
— Identifier les difficultés rencontrées par les clients en raison d’un système de caisse lent.
— Déterminer les technologies existantes qui facilitent les achats dans les supermarchés
de détail.
— Concevoir, développer et tester une application mobile permettant aux clients de scan-
ner et de régler leurs achats au supermarché.
— Valider l’efficience et l’efficacité de l’application mobile.
2.1.4 Questions de recherche
— Quelles sont les difficultés rencontrées par les clients en raison d’un système de caisse
lent ?
— Quelles sont les technologies actuelles qui facilitent les achats ?

— Comment l’application mobile peut-elle être utilisée pour scanner les articles et régler
les achats au supermarché ?
— Quels sont les résultats des tests et de l’évaluation de l’application développée ?
2.1.5 Justification de recherche
Nous avons réalisé une enquête sur les habitudes d’achat des gens afin de déterminer la
liste des choses que les clients détestent dans supermarché. L’un des principaux problèmes
est la longueur des files d’attente aux caisses. 62% des personnes interrogées ont déclaré que
c’était leur principal problème et la plupart d’entre elles partent sans rien acheter.
A - Notre démarche d’enquête
Nous avons pris contact avec les responsables de caisse de différentes grandes surfaces.
Certains ont refusé de travailler avec nous pour diverses raisons évoquées (données confi-
dentielles, étude déjà effectuée en interne, manque de temps). Deux enseignes ont accepté
de collaborer (Spar situé à Akwa et le grand BAO situé au vers le collège Saint-Michel près
de Chococam), nous avons préféré travailler avec le supermarché BAO) plutôt qu’avec le
supermarché de quartier Spar. En effet, pour ce dernier, la surface de vente est petite tout
comme le panier moyen ; la clientèle est fidèle et peut attendre un peu plus en caisse. La
diminution de l’attente n’est pas la principale demande du client dans les supermarchés de
quartier.
Figure 2.2 – Rayon du grand Bao

B - Ce qui créer l’attente au niveau de la caisse
— Affluence imprévue de clients (sortie de bureau, car de touriste...)
— Temps mis par le client pour emballer ses achats
— Temps mis par le client pour payer (chercher le mode de paiement)
— Code barre de l’article non reconnu
— Article mal étiqueté
— Changement de caissière
— Caisse bloquée
— Contestation du prix d’un article ce qui entraı̂ne une vérification en rayon
— Le facteur le plus important est la variance entre les clients (différence de temps de
passage entre un gros caddie ou un petit panier)
C - Point de vue du Responsable de Caisse (M. Moussa David)
Ici nous avons proposé un ensemble proposition et posé certaines questions au responsable
de caisse pour ainsi recueillir son avis sur notre thème de recherche.
Moyen pour indiquer aux clients les caisses où il y a moins d’attente : Il
faut éviter au maximum de faire se déplacer le client. C’est au magasin de suivre les
mouvements de personnes, par exemple si le magasin est sur plusieurs niveaux, ce
seront les caissières qui changeront de niveau.
Moyen pour rendre l’attente plus agréable si on n’arrive pas à la réduire

(téléviseurs, occupation des enfants...) : Le problème actuel est la prolifération
des messages d’information aux abords des caisses, le téléviseur permettrait de limiter
les points d’affichage et pourrait divertir le client.
Augmenter le nombre de rollers (appareils permettant de scanner les codes-

barres) pour augmenter la réactivité si un code ne passe pas : Il est difficile
d’augmenter le nombre de rollers car cela a un coût et s’ils sont trop nombreux, ils
peuvent rester inoccupés s’il n’y a pas de souci.

Placer une aide pour emballer les articles en bout de tapis / si dans la
file d’attente, il y a des petits caddies ou paniers, un employé pourrait en
cas d’affluence pré-scanner leurs articles pour que la caissière n’ait qu’à
encaisser : Ces solutions impliquent l’embauche de personnes supplémentaires ce qui
a un coût et il faut des systèmes de scannage mobiles. En théorie, l’hôtesse de caisse
doit aider le client à emballer ses articles lorsqu’elle a fini le scanning mais en pratique,
cela n’est pas toujours réalisé.
Instaurer quelques caisses de scanning client dans l’hypermarché (réservé à

certains modes de paiement) : Il faut cependant instaurer une politique de contrôle
aléatoire des caddies scannés par les clients de façon à limiter la fraude. Ceci ne pourrait
s’appliquer que pour les paiements par carte bancaire, par carte de fidélité de l’enseigne
ou par les moyens de paiement mobile.
D - Questionnaires et Chronométrages client
Il n’y a par contre aucune donnée en ce qui concerne le temps que passe un client entre le
moment où il entre dans la file d’attente et le moment où il quitte la caisse avec ses articles
empaquetés. Nous avons donc effectué des chronométrages afin d’avoir une idée de ce temps.
D’autre part, nous avons questionné une centaine de clients afin de déterminer dans
quelle mesure le temps d’attente est important pour eux. Notre questionnaire client compor-
tait les questions suivantes :
— Quelle est, selon vous, la durée moyenne d’attente acceptable ?
— Faites-vous régulièrement vos courses dans cet hypermarché ?
— A quelle fréquence ?
— Quelle est en général la taille de votre panier moyen ?
— Seriez-vous prêt à changer de supermarché si l’attente vous semble trop importante ?
Chronométrages client
Résultats des chronométrages : Ils ont été réalisés le premier soir des soldes et le
samedi après-midi suivant. Caisse(77 clients sur les 2 jours)

Tableau 2.1 – Chronométrage du temps moyen de passage et du panier des clients
Date 30/06/2022 01/07/2022 Sur les 2 jours
Temps moyen de passage 4,708333 7,09434 6,350649

(min)
Panier moyen (Nombre 9 13 12
d’articles)
Analyse : Pour le premier jour des soldes, les plannings ont été réalisés en prévoyant
l’affluence, en conséquence, nous n’avons pas observé de très longues files d’attente.
En moyenne, un client met 6 min et 20 secondes à passer un jour d’affluence. Dans

le magasin étudié, le panier moyen est assez faible (12 articles en moyenne).
On constate qu’un client avec un caddie rempli va mettre plus de temps à passer (10
à 13 minutes) et ce temps se répercute sur les clients suivants qui arrivent dans la file
pendant que le premier y est. L’attente est moindre si le client suivant arrive lorsqu’il
est en train de passer en caisse.
Questionnaires client
Résultats des questionnaires
Les questions ont été posées à 105 clients, dans plusieurs caisses à divers endroits du
magasin. Le diagramme suivant présente les temps moyens d’attente acceptable selon
les clients :

Figure 2.3 – Les temps moyens d’attente acceptable selon les clients
Le diagramme suivant présente la fréquence à laquelle les clients viennent faire leurs
courses :
Figure 2.4 – La fréquence à laquelle les clients viennent faire leurs courses
En étudiant les résultats plus en profondeur, nous nous apercevons que, sur 61 clients
réguliers (soit environ 58% des personnes interrogées), 26 (soit 42%) seraient prêts à
changer d’hypermarché si le temps d’attente devenait trop long.
Nous avons traduit l’incidence d’une telle perte pour le magasin par le diagramme
qui suit. Il présente la fréquentation de ces 26 clients et la taille moyenne de leur panier
(entre parenthèses) :

Figure 2.5 – la fréquentation de ces 26 clients et la taille moyenne de leur panier
On remarque que la perte de clients ne venant que 2 fois par mois est autant à prendre en
compte que celle des clients venant plus souvent, car leur panier est plus important.
2.1.6 Analyse swot
Le SWOT (Forces, faiblesse, opportunité et menace) est un outil de stratégie d’entreprise

inventé par un groupe de professeurs de Harvard : Learned, Christensen, Andrews, et Guth
destiné à identifier les options stratégiques d’une entreprise ou d’un projet. Il permet de
définir les objectifs en se basant sur les facteurs internes et externes pour les atteindre
[Dufour, 2022].

Figure 2.6 – Analyse SWOT
2.1.7 Cadrage du projet
Il est difficile de parler d’un projet avant d’avoir fait une analyse détaillée du travail à
faire. Il est cependant nécessaire d’effectuer une première estimation générale pour pouvoir
cadrer le projet. Le cadrage permettra entre autres de rappeler l’enjeu ou les intérêts et
les objectifs du projet. Elle a également pour objectifs, d’aligner les besoins à satisfaire.
C’est également l’occasion d’identifier les moyens nécessaires à la mise en œuvre du projet.
Pour assurer notre cadrage, nous avons appliqué la méthode CPS (Cadrage pragmatique et
Synthétique). Cette méthode est un moyen utile pour :
— Cadrer dans ses grandes lignes un programme ou un projet avant d’entrer dans les

détails
— Le présenter de façon pédagogique et synthétique à l’aide de 7 planches projetables
— C’est un élément import dans le cadre de la communication
— Il s’agit de ressortir de quoi, le comment et l’organisation
A - De quoi S’agit-il ?
Notre projet consiste à concevoir et à implémenter une application Android qui viendra
optimiser le processus d’achat des articles dans un supermarchés. La solution sera intitulée
Scan & Go.
Les intérêts et objectifs
L’implémentation d’un tel système à pour intérêts :
— Optimiser le processus de facturation des articles
— Optimiser le temps de courses
— Fidéliser la clientèle
— Augmenter le chiffre d’affaires des supermarchés
— Faciliter le processus de respect de mesure barrière face à la pandémie COVID-19
L’implémentation d’un tel système a pour objectifs :
— Résoudre le problème de congestion au niveau des caisses
— Permettre aux clients de pré facturer son panier via son téléphone
— Permettre aux clients de transférer le contenu du panier pour une vérification des
éléments à distance par un autre utilisateur
— De régler soit même sa facture ou de transférer à un compte distant pour effectuer le

paiement par Orange Money ou Mobile Money en fonction du supermarché
— Partager une base données centralisée
— Réduire le risque de contamination du COVID-19
Les spécifications fonctionnelles

Le volet fonctionnel spécifie les exigences que l’application doit remplir pour satisfaire
tous les besoins des utilisateurs du système. Ils sont entre autres :
— Scanner les codes-barres des produits
— Ajouter un article au panier
— Modifier ou supprimer son panier
— Transférer la facture à une tierce personne pour paiement
— Valider ou annuler la facture
— Choix et confirmation du mode de paiement
— Créer son comptes utilisateur
— Consulter le rapport des paiements effectués
Les spécifications non fonctionnelles
Ces exigences spécifient les critères utilisés pour évaluer le fonctionnement du système.
Elles ont été assemblées en accord avec les exigences fonctionnelles qui définissent les fonc-
tions et le comportement spécifiques. Elles comprennent :
— La facilité d’utilisation : L’interface du système doit être facile à utiliser et à inter-

agir.
— Disponibilité et fiabilité : Le système doit être fiable et toujours disponible pour

effectuer les tâches demandées par l’utilisateur.
— Évolutivité : Le système doit être capable de mettre en œuvre des fonctionnalités

supplémentaires. Les données supplémentaires doivent être faciles à intégrer.
— Intégrité : Le système doit garantir que les données collectées et stockées ne sont pas
modifiées ou corrompues.
— Performance : Le système doit avoir un temps de réponse tolérable lors de l’exécution

de ses fonctions.
— Sécurité : Le système doit permettre aux seuls utilisateurs autorisés d’utiliser ses
fonctionnalités.
Approche pour assurer le respect des fonctionnalités

Les tests sont un aspect essentiel du développement d’application. Car ils permettent de
vérifier que l’application fonctionne correctement et garantir la meilleur expérience utilisateur
possible. Lest tests préviennent et garantissent le niveau de qualité du produit sur une
période déterminée. Ils donnent aussi des indications de fiabilité. Tout cela, permet de vérifier
l’adéquation du produit aux besoins exprimés par le client et donc de satisfaire la demande
du client. Les tests suivants nous permettrons d’assurer la qualité de notre application :
— Test unitaire : En programmation informatique, le test unitaire est une procédure

permettant de vérifier le bon fonctionnement d’une partie précise d’un logiciel ou d’une
portion d’un programme.
— Test d’intégration : C’est un test qui vise à s’assurer du bon fonctionnement de la

mise en œuvre conjointe de plusieurs unités de programme testés lors du test unitaire.
— Test fonctionnelle : C’est un test permettant de tester les fonctionnalités d’une

application ou d’un logicielle.
— Test de performance : c’est un test dont l’objectif est de déterminer la performance

d’un système informatique.
— Test de régression : c’est un test ayant pour but de détecter les régressions intro-
duites dans un logiciel après un changement effectué dans celui-ci.
B - Planification et risque du projet
Planification prévisionnels du projet (Diagramme de Gantt)
La planification est une phase très importante dans la réalisation des projets infor-
matiques car elle vise à connaı̂tre exactement les délais de mise en place de la solution
informatique. Le système informatique sera conçu et réalisé sur une période de 6 mois.
Le diagramme de Gantt est un outil utilisé en ordonnancement et en gestion de projet

et permettant de visualiser dans le temps les diverses tâches composant un projet et ainsi
de voir graphiquement l’avancement du projet [Gantt, 2022].

Figure 2.7 – Diagramme de Gantt prévisionnel
Evaluation et gestion des contraintes susceptibles de ralentir l’exécution du

projet
Compte tenu du fait que les attaques informatiques (physique ou logique) sont presque
inévitables, nous devons prendre les dispositions adéquates afin de garantir le respect du
temps dédié à l’exécution du projet. Ces dispositions peuvent être à titre de prévention pour
éviter complètement une quelconque intrusion, soit atténuer leurs effets néfastes.

Tableau 2.2 – Évaluation et gestion des contraintes d’exécution du projet
Contraintes Impact Mesure préventive
En absence d’internet durant Acquérir dans la mesure du pos-

Problèmes l’exécution, le délai de livraison sible modem avec un forfait
de risque d’être prolongé auprès du meilleur fournisseur
connexion d’accès à internet.
Ceci pourrait être le vol Installation des dispositifs d’anti-
d’équipements et serveurs, vol, d’alarme, d’incendie, installa-
Attaques
incendie, inondation, coupure tion du groupe électrogène et on-
Physiques
électrique etc. duleurs pour assurer la continuité
des services.
Utiliser les systèmes de version-
ning tels que Github, Gitlab pour
récupérer en cas de problème la
dernière version du code de notre
application.
Ralentissement ou blocage anor- Audit de sécurité régulière et la
male du PC, modification des mise à jour régulière des installa-
Programmes
programmes, affichage des mes- tions antivirales.
malveillants
sages sans raison
Évaluation, gestion des risques liés à la mise en production et mesure de

sécurité
Notre application mobile doit être sécuriser dans la mesure où elles manipulent des
données personnelles et accèdent à des informations sensibles. La sécurité des applications
mobiles comprend différents aspects :

— La sécurité des applications mobiles elles-mêmes (version Windows phone, iOS ou

Android)
— La sécurité des APIs
— La sécurité des serveurs
La sécurité du Backend (APIs et serveur) est généralement plus critique que la sécurité du
frontend (application iOS, Windows, Android), mais ceci dépend du contexte technique et
fonctionnel de l’application elle-même.
Pour renforcer la sécurité de notre application, il est nécessaire de rechercher et cor-

riger les vulnérabilités à la fois côté serveur et côté applicatif (à minima les APIs, mais
dans certains cas aussi les applications mobiles elle-même). Il est questions pour nous de
présenter les vulnérabilités les plus souvent exploitée lors d’attaques sur les applications
mobiles. Nous détaillerons également les bonnes pratiques et mesures à implémenter pour
corriger ces vulnérabilités et réduire les risques.
Nous pouvons citer :
Vulnérabilité serveur : Étant un élément central dans le fonctionnement d’une appli-

cation, le serveur est la cible privilégiée d’attaque, qui réussissent souvent en raison de
vulnérabilités au niveau de la configuration de ce dernier ou des contrôles effectués par
celui-ci. En cas de mauvaise configuration ou si des contrôles ne sont pas effectués, de
nombreuses failles peuvent être exploitées et conduit à la compromission des données
qui transitent, voire à la prise en main du serveur par des personnes malveillantes.
Faille d’injection : Les failles d’injection sont les répandues, les plus dangereuses et
les plus diverses (injection SQL, de code, XSS, XPath etc.). Il s’agit pour un attaquant
d’envoyer des requêtes ou des commandes de backend permettant d’exécuter un code
malveillant si les contrôles ne sont pas mis en place côté serveur. Par exemple, lors
d’une attaque d’injection SQL, en manipulant une requête SQL, un attaquant peut
récupérer des enregistrements de base de données ou manipuler le contenu de la base
de données.

Attaque IDOR (Insecure Direct Object Reference) : Elle repose sur les in-
jections, en s’appuyant sur le manque de contrôle de droits côté serveur, il devient
possible pour un utilisateur de modifier le comportement d’une application, héberger
des malwares, voler, altérer ou supprimer des données sensibles.
Stockage non sécurité des données : Une application mobile peut stocker différents
types de données (cookie, fichier, textes, paramètres, etc.) via divers moyens de sto-
ckages (base données SQL, magasins de données, fichiers XML, fichiers PLIST, carte
SD etc.). HTTP (Hyper texte transfert protocole) est la norme en matière de communi-
cation client-serveur. Cependant les communications peuvent potentiellement être in-
terceptés, modifiées ou rédigées. Car ce protocole n’intègre aucun dispositif de sécurité.
Sécurité d’échange des données : Les fonctionnalités de la plupart des applications

reposent sur la communication avec un serveur. Suivant les besoins métiers, une appli-
cation envoie ou reçoit différents types de données : identifiants de connexion, données
de session utilisateur, données personnelles, données bancaires etc.
Attaque du Man in the Middle : Une des attaques courantes utilise l’empoisonne-
ment de cache ARP. Cette technique permet à un attaquant de détourner des flux de
communications transitant entre une application et une passerelle : routeur, box etc.
En somme, c’est une attaque Man in the Middle dans laquelle un attaquant envoie
de faux messages pour empoisonner le cache ARP d’un utilisateur et ainsi lier son
adresse MAC à l’adresse IP légitime. Ce faisant, il peut ensuite intercepter, modifier
ou supprimer toute communication qui transite entre l’application et le serveur.
Sécurité des composants tiers : La plupart des applications mobiles utilise des
composants tiers : librairies, Framework, API tierces etc. L’utilisation de ces compo-
sants permet de réduire considérablement le temps nécessaire entre la conception d’une
application et sa mise sur le marché. Ils peuvent cependant représenter un risque de
sécurité important, avec des possibilités de vulnérabilités diverses : injections, XSS,
mauvaise configuration etc.
Les solutions ci-dessous sont envisagés pour assurer notre politique de sécuritaire :

Tableau 2.3 – Evaluation des risques et mesure de sécurités.
Risques Mesure de sécurité
Vulnérabilité du serveur Il est nécessaire de mettre en place un système de validation des entrées
pour écarter tout risque de compromission des données.
Faille d’injection SQL Il est recommandé d’utiliser les requêtes préparées, permettant de
contrôler les informations envoyées par un utilisateur. En effet s’il y’a
un seul aspect de sécurité à retenir en réponse à cette problématique, de
ne jamais considérer toutes les données envoyées par un utilisateur ou
tout système comme étant sûres.
Attaque IDOR Il est très fortement conseillé d’intégrer une couche de sécurité en amont
de la publication de vos applications mobiles sur les stores.
Stockage non sécurisé des Pour un stockage sécurisé, il est essentiel que les données soient protégées
données et chiffrées efficacement. Pour les applications mobiles, cela signifie chif-
frer et appliquer les autorisations appropriées. Android et iOs offrent tous
deux magasins de stockage sécurisé apppelé Keychain pour iOS et Keys-
tore pour android, qui permettent de chiffrer des données
Sécurité d’change des Il suffit d’utiliser le protocole de sécurité TLS (successeur de SSL) ou
données et attaque Man the SSL pour rajouter une couche de sécurité qui garantit la confidentialité
Middle et l’intégrité des données qui transitent grâce au chiffrement des données.
En effet les deux sont des protocoles de chiffrement pour la couche de
transport d’internet. Seul TLS 1.3 est utilisé. SSL 2.0 et SSL 3.0 sont
obsolètes et pas considérés comme sûrs. Il en va de même des anciennes
versions de TLS 1.0 et 1.1(qui ne seront bientôt plus supportés).
Disponibilité Pour assurer la disponibilité de notre serveur, nous allons dupliquer notre
base de données en mode Load Balancing, de manière à ce que si un
serveur ne répond pas d’autre soit capable d’assurer la relève.

Nous pouvons renforcer concrètement la sécurité de nos applications mobiles est de

réaliser un test d’intrusion. Il s’agit de mettre à l’épreuve notre application en testant
méthodiquement un périmètre pour identifier les failles de sécurité et proposer des correctifs
appropriés.
Un test d’instruction d’application mobile permet de déceler des vulnérabilités sur la

couche serveurs ainsi que sur la couche applicative (failles des applications web pour les APIs
et failles des applications mobiles pour les apps iOS et Android). Les tests combinent une
analyse statique et une analyse dynamique de l’application.
Estimation des charges du projets
Méthode COCOMO :
Le coût d’un logiciel est fonction de l’effort de développement, il inclut : la spécification,

l’analyse, la conception, la programmation, les tests (vérification et validation) et
la maintenance. L’effort, c’est la quantité de travail nécessaire, indépendamment du
nombre de personnes qui vont réaliser ce travail. Il s’exprime en homme/jour, homme/mois,
homme/année.
Le modèle d’estimation COCOMO (COnstructive COst MOdel : modèle constructif

de coûts) a été introduit en 1981 par Barry Boehm. On dit de ce modèle d’estimation
des charges projet qu’il est constructif car il permet de mieux prendre en compte la
complexité logicielle et donc de mieux appréhender l’estimation du projet.
Ce modèle cherche à limiter les erreurs de budget et les retards de livraison, qui sont
monnaie courante dans l’industrie du développement logiciel. Pour les projets basés sur
une technologie traditionnelle, le modèle original de 1981 est encore valable, d’autant
plus qu’il est maintenant rodé et bien documenté. COCOMO 81 est en fait constitué
de trois modèles :

— Modèle de Base : Le modèle de base est assez simpliste. Il estime l’effort (le nombre de
mois-homme) en fonction du nombre de lignes de code, la productivité (le nombre de
lignes de code par personne par mois) et un facteur d’échelle qui dépend du type de
projet. Les 3 types de projet identifiés sont :
— Organique, organisation simple et petites équipes expérimentées. (ex : système de

notes dans une école)
— Semi-détaché, entre organique et imbriqué. (Exemple : système bancaire interac-

tif)
— Imbriqué, techniques innovante, organisation complexe, couplage fort avec beau-

coup d’interactions. (Exemple : système de contrôle aérospatial.)
— Modèle Intermédiaire : Le modèle intermédiaire introduit 15 facteurs de productivité

(appelés cost drivers), représentants un avis subjectif et expert du produit, du matériel,
du personnel, et des attributs du projet. Chaque facteur prend une valeur nominative
de 1, et peut varier selon son importance dans le projet. Ils sont semblables aux points
de fonction utilisés par d’autres modèles. Les 15 facteurs sont multipliés pour donner
un facteur d’ajustement - qui vient modifier l’estimation donnée par la formule de base.
— Modèle Expert : Le modèle expert inclue toutes les caractéristiques du modèle in-
termédiaire avec une estimation de l’impact de la conduite des coûts sur chaque étape
du cycle de développement : définition initiale du produit, définition détaillée, codage,
intégration. De plus, le projet est analysé en termes d’une hiérarchie : module, sous
système et système. Il permet une véritable gestion de projet, utile pour de grands
projets [estimancy, 2018].
Resource humaine
Également appelées ressource de travail, ces ressources sont les plus importantes, car
ce sont justement celles qui exécutent le travail. Regroupant à la fois les individus, les
groupes d’individus et les personnes morales, elles contribuent à effectuer les tâches
nécessaires au bon déroulement et la réalisation du projet.

Tableau 2.4 – Ressources humain du projet
Acteurs Rôle Action réalisée
Hervé NONO Product Owner Lecture et Modification

Dave DJAMOU Scrum Master Lecture et Modification
NDANGA jules Scrum Team (concepteur et Lecture et écriture
développeur)
Kisito MOMO Scrum team(UX/UI designer) Lecture et écriture
Resource matérielles du projet C’est tout ce dont l’équipe projet va avoir be-
soin pour mener à bien le projet. Le tableau ci-dessous nous présente l’équipement
nécessaire :
Équipements Caractéristiques mini- Quantité Prix unitaire Prix

mum
Laptop HP Disque dur 1 To RAM 12 01 230 000 230 000
Go, Carte graphique 2.2 Go,
Processeur core i5 1.8 Hz
Laptop Lenovo Think- Disque dur 1 To RAM 12 01 280 000 280 000
pad Go, Carte graphique 2.7 Go,
Processeur core i7 2.6 Hz
Clé USB 32 Go Sandisk 01 8 000 8 000
Modem 4G Lite CAMTEL 01 30 000 30 000
Onduleur 500 V A minimum 01 70 000 70 000
Rallonge 100 V minimum 01 5 000 5 000
TOTAL EN FCFA 623 000

Coût total prévisionnel du projet
Evaluer le coût d’un logiciel ou d’une application c’est évaluer l’ensemble des dépenses
à réaliser par le MOA(maı̂tre d’ouvrage) pour s’approprier un service informatique.
Tableau 2.6 – distribution des coefficients
Mode(Type) a b C
Organique 2.4 1.05 0.38
Semi-détaché 3.0 1.12 0.35
Imbriqué 3.6 1.20 0.32
Notre projet utilisera le modèle de base organique et on estimera à 2000 le nombre total de
ligne de codes.
Figure 2.8 – Formule Effort
A.N : effort = 2.4x(2)exp(1.05) Effort=5HM
Figure 2.9 – Formule Temps de développement
A.N : Temps Développement = 2.5(5)exp(0.38) Temps Développement =6 mois
Figure 2.10 – Formule détermination nombres moyens de personnes pour le projet
A.N : FSP=5/4=1.25

Tableau 2.7 – résultats calculs méthode CoCoMo
Tâches EFFORT Temps

Développement
Expression des besoins et 0.8 0.76
planification
Conception détaillée 1.3 2.52
Programmation et tests uni- 2.1 2.52
taires
Tests et intégrations 0.8 0.72
En estimant le salaire moyen d’un ingénieur de travaux a 200 000 FCFA/mois.
Figure 2.11 – Formule du coût prévisionnel
AN : Cout prévisionnel = 6x200000+623000 =⇒ Cout prévisionnel = 1 823 000 FCFA
2.2 Méthodologie de développement

Une facette du domaine du génie logiciel se spécialise dans l’étude de la démarche
utilisé pour la création des logiciels. Les approches de développement se concrétisent par
des méthodes, afin de témoigner des efforts nécessaires concernant l’application à réaliser.
L’évolution des technologies et le manque de ressources sont des facteurs qui contribuent à la
difficulté d’exécution d’un projet. Il est important de trouver des approches adéquates à leur
contexte organisationnel. Nous avons d’une part les méthodes classiques qui sont souvent
lourdes et coûteuses à gérer et d’autre part les méthodes agiles qui représentent une vision
différente du développement logiciel.

2.2.1 Méthode classique
Les méthodes traditionnelles dégagent plusieurs modèles de production de logiciel ainsi

appelés ≪ Cycle de vie logiciel ≫. Ces modèles servent de références théoriques. Ils mettent
en relief les phases du processus et leur ordonnancement [Guyot, 2018].
A - Présentations de quelques méthodes classiques
Nous pouvons citer parmi les différentes méthodes classiques :
Le modèle ad-hoc : Ce fût le premier moyen utilisé au début de l’aire informa-

tique. Il s’est avéré inapproprié pour de gros logiciels et livrait des produits qui ne
correspondaient pas aux attentes des utilisateurs.
La modèle en cascade : Il fut le standard industrie dans les années 70, il est apparu
suite à la crise du logiciel. Il présente une série d’étapes subséquentes réalisées l’une
après l’autre. Une documentation était intégrée à chaque étape et des vérifications était
faites sur tous les livrables.
Cependant, la rigidité du modèle est fortement critiquée. Il est difficile d’évaluer cor-
rectement le projet au départ, car peu d’informations sont disponibles. Les spécifications
écrites permettent difficilement à l’utilisateur d’anticiper le système, ce qui limite les
chances de respecté les attentes.
Le modèle en V : c’est une première amélioration de la méthode en cascade. Il a

été créé pour pallier le manque de réactivité du modèle en cascade. Il permet de créer
des spécifications qui sont validées à un niveau de précision équivalente, ultérieurement
dans le processus, formant ainsi un modèle en V. Il met en évidence la nécessité d’an-
ticiper et de préparer l’étape suivante. Les éléments nécessaires à la validation sont
préparés lors des spécifications.
Cependant cette méthode reste toujours rigide. En effet, il est difficile de revenir à
une phase lorsqu’elle est terminée. Bien que cela puisse être un handicap dans certains
projets logiciels, qui demandent une certaine flexibilité. On peut l’utiliser dans un

projet dont le cahier des charges ne change pas en cours de route. Par exemple dans
des projets lancés à partir d’un appel d’offres où le client a documenté ses exigences
très clairement.
Le modèle par prototype : Il fût créé du fait qu’il était difficile d’obtenir les
spécifications au début d’un projet. Ce modèle consiste à construire une version réduite
ou théorique du système, afin d’obtenir les approbations. Les commentaires permettent
de raffiner les spécifications. Ce modèle peut se greffer à un modèle en cascade ou
itératif.
Cependant, il est coûteux, a une mauvaise documentation en raison de l’évolution

constante des exigences des clients. De même il peut y avoir trop de variations dans les
exigences. Les clients exigent parfois que le produit réel soit livré peu de temps après
avoir vu un premier prototype. Il peut y voir des solutions sous-optimales en raison de
développeurs pressés de construire de prototypes.
Le modèle en spirale : Il a été conçu pour inclure les meilleurs éléments du prototy-
page et du modèle en cascade. Il introduit la notion d’évaluation des risques, pouvant
mener à l’arrêt du projet si ceux-ci sont jugés majeurs. Le terme spirale est utilisé pour
décrire la forme que prend le modèle. Il propose des solutions qui sont évaluées par le
client puis enrichies dans un cycle ultérieur. Il propose des solutions qui sont évaluées
par le client puis enrichies dans un cycle ultérieur. Comme l’approche par prototypage,
une première version est produite et raffinée suite aux évaluations.
Cependant, ce modèle est couteux, plus complexe que les autres modèles de cycle
de vie. Il dépend fortement de l’analyse des risques et nécessites une expertise très
spécifique.
B - Ingénierie des exigences avec les méthodes traditionnelles
L’ingénierie des exigences implique un certain nombre de processus de collecte, des exi-
gences en fonction des besoins et des demandes des utilisateurs et des parties prenantes du
produit logiciel. Ils impliquent certaines fonctionnalités importantes qui sont l’élicitassions,

l’analyse, la documentation et la gestion des exigences. Dans ces modèles, l’ingénierie des
exigences est présentée comme la première phase du processus de développement. Cette ap-
proche traditionnelle du processus RE(requirement Engineering) se concentre sur la collecte
de toutes les exigences et la préparation du document de spécification des exigences avant
de passer à la phase de conception.
Dans la méthode en cascade par exemple, le projet est séparé en étapes distinctes et
les engagements doivent être pris à un stade précoce, ce qui rend difficile la modification
des exigences si les clients changent d’avis. Ainsi, la cascade est plus appropriée lorsque les
exigences ne seront probablement pas modifiées pendant la période de mise en œuvre.
En conclusion, les modèles traditionnelles adoptent un point de vue statique de l’ingénierie

des exigences en ignorant des problèmes tels que la volatilité des exigences et son impact sur
les phases antérieures de développement.
2.2.2 Méthode agiles
Avec l’évolution des technologies, les méthodes traditionnelles de développement logiciel

s’avèrent trop lourdes dans plusieurs situations. D’où la nécessité de trouver des alterna-
tives plus structurées. Les méthodes dites ≪ Agiles ≫ proposent une vision différente du
développement logiciel. L’agilité exige de s’adapter aux changements que proposent ces ap-
proches. Ces changements pouvant être au niveau des spécifications, des intervenants, des
procédures et des technologies. C’est dans cette optique que Jil HIGHSMITH définit l’agi-
lité ainsi : ≪ L’agilité est l’habilité conjointe de créer et de répondre aux changements d’un
environnement turbulent au profit de l’entreprise. ≫ [Highsmith, 2021].
A - Présentation des méthodes agiles
La plupart des méthodes agiles ont été élaborés et proposées par des praticiens dont
l’intention est de développer des approches innovantes de développement de logiciels qui
vont permettre à l’organisation de réagir rapidement et de s’adapter aux exigences et aux

technologies volatiles. Il existe plusieurs types de méthodes Agiles telles que XP, Scrum, le
développement de logiciels Crystal. . .
La méthodes XP : eXtreme Programming(XP) est une méthode agile qui comporte

un ensemble de pratiques interdépendantes qui demandent beaucoup de rigueur, afin
de puiser le maximum d’efficacité des équipes de développement. Le plus important
dans la vision de Beck l’inventeur de la méthode XP, est l’interaction sociale, afin de
changer la manière dont les gens se traitent les uns les autres et comment ils sont traités
par l’organisation. XP prône les valeurs de communications, la simplicité, le feedback
et le courage. Elle s’adresse principalement aux petites équipes composées de deux
à douze (02 à 12) personnes travaillant dans un espace commun. Elle demande une
grande implication du client et exige de pouvoir automatiser les tests. Elle augmente
la productivité et offre de meilleurs résultats.
Cependant, l’implémentation de cette méthode engendre une charge de travail supplémentaire,

des coûts relativement élevés, requière de l’autodiscipline pour la mise en œuvre.
La méthode Scrum : Scrum(mêlée) est un processus de contrôle empirique de

développement logiciel. Il permet aux équipes de produire des logiciels de manière
opérative incrémentale, favorisant ce qui a le plus de valeur pour l’entreprise. Scrum
est un processus léger. Il se concentre sur l’augmentation de la productivité des équipes
tout en réduisant les gaspillages et les activités. Scrum est une amélioration du pro-
cessus itératifs et de l’approche incrémentale pour le logiciel orienté objet, initiale-
ment documenté par Pittman, puis par Booch. Plusieurs éléments de SCRUM sont
des métaphores référant au rugby. Le développement est perçu comme un jeu d’équipe
allant de trois à neuf (03 à 09) personnes.
Cependant, toutes les cultures d’entreprise ne sont pas prêtes pour des changements
aussi drastiques que requiert la culture Agile Scrum. La confiance, la flexibilité, les in-
certitudes sont des variables qui peuvent être incompatibles avec les valeurs d’une entre-
prise. Cette méthode impose une collaboration sans limites, du temps supplémentaire
et un engagement plus important.

La méthode Crystal : Crystal est une plateforme méthodologique. La famille de

méthode Crystal comporte présentement quatre membres, qui ne sont pas encore tous
documentés. Présentement, seul Crystal Orange et Clear ont été décrit dans différents
ouvrages [Cockburn, 2001]. Crystal est une méthode ouverte qui permet d’intégrer des
pratiques provenant d’autres méthodes. Ce qui constitue le noyau de cette méthode,
c’est les propriétés appliquées à travers différentes stratégies et techniques. La commu-
nication est le point fort de Crystal Clear. Cette méthode demande que l’équipe soit
très proche et dans une aire ouverte. I faut que les soient à porter d’oreille afin que les
conversations d’arrière-plan puissent être comprises. C’est une manière très rapide et
efficace pour obtenir les commentaires des autres membres de l’équipe.
Cependant, elle reste limitée à des équipes de taille inférieure à 6 personnes. Les
processus et pratiques de Crystal conviennent parfaitement pour des petites structures.
B - Ingénierie des exigences avec les méthodes agiles
Selon divers chercheurs, la méthodologie Agile est basée sur les principes suivants également
connus sous le nom de manifeste Agile. Ces principes sont assez simples dans leur concept,
mais sont profondément ancrés dans la pratique. Agile suppose que l’ingénierie des exigences
se poursuit tout au long de la durée de vie d’un système. Dans Agile, RE est réalisé grâce à
une collaboration continue tandis que la collecte, le développement et les tests des exigences
évolutives qui suggère que les exigences doivent évoluer avec le temps. La notion de manifeste
agile sous-entend l’idée d’une déclaration formelle. Elle préconise les valeurs suivantes :

Figure 2.12 – Les valeurs du manifeste Agile
Dans Agile, les exigences métier sont listés et documentées sous la forme d’histoires
d’utilisateurs (user stories), qui sont présentées du point de vue de l’utilisateur. Ces user
stories sont utilisées comme unité de travail principale et continuent de croı̂tre tout au long
du cycle de vie du projet. La méthode agile implique une planification continue, c’est-à-dire
la planification des versions, la planification des interactions et la planification au niveau des
tâches. La planification des itérations est effectuée pour chaque itération qui s’étend sur une
à trois semaines.
2.2.3 Comparaison des Méthodes classiques face aux Méthodes

Agiles
Il a été constaté que le processus d’exigence classique est un processus complexe où
dans la vie réelle, le développement nécessite un logiciel d’exigence efficace qui doit avoir un
processus flexible et rapide. Pour un projet réussi, un processus RE efficace est nécessaire.
L’objectif de RE reste le même dans toutes les méthodes logicielles.

Cependant, des variances remarquables sont trouvées dans le processus de réalisation

des activités RE, dans les méthodes Agiles par rapport aux méthodes classiques. La méthode
classique est confrontée à de nombreux défis tels que les lacunes en matière de communica-
tions, la portée excessive, la hiérarchisation des exigences, le validation et l’implication des
clients.
Ces problèmes sont résolus par des pratiques agiles telles que la communication en face
à face pour minimiser les lacunes en matière de documentation et de communication, le détail
progressif des exigences pour réduire la portée excessive, la hiérarchisation des exigences par
les clients en fonction de la valeur de l’entreprise pour gérer la validation des exigences et une
interaction étroite de la part de l’équipe et du client afin d’éviter le manque de participation
du client.
La différenciation a été clairement établi et on constate que les méthodes classiques

et les méthodes agiles sont deux approches différentes en ce qui concerne leurs règles et
leurs activités. La comparaison entre deux approches différentes en ce qui concerne leurs
réglés et leurs activités. La comparaison entre les deux montre pourquoi les gens sont passés
des méthodes classiques aux méthodes agiles. L’idée sous-jacente de ce changement apparent
était de faire la lumière sur l’ampleur du développement Agile pour un processus d’ingénierie
des exigences efficace.

Figure 2.13 – Comparaison méthode classique et méthode Agile
En raison du nombre de membres de l’équipe, de la possibilité d’itérer et d’incrémenté

la solution au tant de fois que possible, de la relation client etc, nous optons pour le choix
de la méthode Agile Scrum d’où la présentation détaillée de celle-ci dans la suite de notre
travaille.
2.2.4 Présentation de la méthodologie adoptée : Agile Scrum
Scrum (mêlée) est un processus de contrôle empirique de développement logiciel élaboré

par Jeff SUTHERLAND et Mike BRRDLE. Il permet aux équipes de produire des logiciels de
manière itérative incrémentale, favorisant ce qui a le plus de valeur pour l’entreprise. Scrum
est un processus léger. Il se concentre sur l’augmentation de la productivité des équipes tout
en réduisant les gaspillages et les activités.

2.2.5 Présentation de la méthodologie adoptée : Agile Scrum
Scrum (mêlée) est un processus de contrôle empirique de développement logiciel élaboré

par Jeff SUTHERLAND et Mike BRRDLE. Il permet aux équipes de produire des logiciels de
manière itérative incrémentale, favorisant ce qui a le plus de valeur pour l’entreprise. Scrum
est un processus léger. Il se concentre sur l’augmentation de la productivité des équipes tout
en réduisant les gaspillages et les activités.
A - Vocabulaire de Scrum
Plusieurs éléments de Scrum sont des métaphores de référant au rugby qui est un sport
où l’équipe est soudée et avance dans la même direction. Le développement est donc perçu
comme un jeu d’équipe.
Backlog produit : Liste des éléments techniques et fonctionnels à produire dans un

avenir prévisible pour obtenir le produit complet. Inclue ce qui est défini et ce qui reste
à préciser.
Sprint Backlog : Liste des éléments et fonctionnels à produite au cours d’un sprint.
C’est un sous-ensemble du backlog produit. Elle comporte des éléments suffisamment
définis pour qu’ils soient réalisés au cours de la période du sprint.
Sprint : Une période de 30 jours maximum où un ensemble de travaux sont effectués
pour créer un livrable.
Scrum : Rencontre journalière de l’équipe pour vérifier l’avancement et replanifier les

empêchements.
Règlement des rencontres Scrum : Protocole des réunions pour être efficaces. Afin
de minimiser la logistique, une série de règles uniformise la dynamique des rencontres.
Equipe Scrum : Equipe multidisciplinaire qui travaille sur les éléments du sprint.
Toutes les personnes (vente, service, clientèle, etc.) impliquées dans le projet sont
invitées à se joindre à l’équipe.

B - Les acteurs de Scrum
Les rôles Scrum sont assez différents des autres méthodes de développement de produit.
Scrum définit trois rôles dans une équipe Scrum définit trois rôles dans une équipe Scrum :
le product Owner, le scrum master et l’équipe de développement scrum. Pour la suite de
notre développement il est important de comprendre la notion d’équipe scrum.
Une équipe Scrum est équipe agile composée d’un groupe de personnes qui vont
travailler ensemble pendant les sprints pour développer un produit de valeur. Deux ca-
ractéristiques majeures sont importantes dans une équipe scrum :
— L’équipe projet agile doit être auto organisée. Il n’y a pas de figure de chef ou de
responsable. Chaque membre doit se sentir suffisamment engagé pour réaliser ses tâches
et contribue au succès de l’équipe de manière totalement autonome.
— Chaque équipe doit être inter fonctionnelle, en associant à tous les membres, elle doit
disposer de toutes les connaissances et compétences nécessaire au développement du
produit.
Concernant la taille de l’équipe, il est recommandé d’avoir une équipe de trois à neuf (3 à
9) personnes : le groupe doit être suffisamment petit pour faciliter la communication, mais
suffisant pour collaborer afin de faire vivre le produit et/ou le service ; Comme expliqué plus
haut, il y a trois rôle Scrum, dont les responsabilités sont :

Figure 2.14 – Rôle des acteurs de scrum
C - Les phases de Scrum
Cette méthode se décline principalement en trois phases à savoir :
La phase initiale : Elle est consacrée à préparer le travail à faire. Cette phase doit
construire la liste des éléments que comportera cette version de produit. Elle comporte
les objectifs suivants :
— Planning
— Architecture
— Mise en place d’un backlog produit (liste des éléments à effectuer)
— Définition l’équipe analyse des risques Budget
Les phases de sprints : Ce sont phases itératives qui réalisent concrètement les

éléments qui composent le produit. Ce travail étant plus chaotique, il est aussi qualifié
de ≪ boı̂te noire ≫. Elle comporte les objectifs suivants :
— Un sprint backlog est sélectionnée cette liste sera suivie et réalisé.
— Période d’environ 30 jours, au cours de laquelle l’équipe est isolé des influences
extérieures. C’est-à-dire que la liste des éléments reste inchangée.
— Réunion quotidienne Scrum
— Comporte au dernier jour, une réunion post-sprint de présentation des résultats
La phase de clôture : Elle prépare la documentation, finalise les tests et rend la ver-
sion fonctionnelle et présentable, à savoir documentation finale, préparatif et livraison.
D - Les contrôles Scrum
Les variables d’un projet de développement de système sont les risques, les fonctionnalités,
les coûts, le temps et qualité. Ces variables sont généralement estimées au début du projet.
Chacune d’elle changera en cours de projet. Il existe une interrelation entre les variables. Par
exemple, nous pouvons améliorer les fonctionnalités en investissant plus de temps et d’argent.
Afin de permettre un suivi, différents contrôles existent dans scrum. Chaque élément peut
être quantifié, afin de permettre l’extraction de métriques qui permettent le suivi. On y
retrouve notamment :
Le backlog projet liste toutes les fonctionnalités et caractéristiques qui seront

complétés dans l’ensemble du projet.
Les problèmes sont des éléments qui doivent être solutionnés par un membre de
l’équipe, afin de permettre la réalisation des objets liés au backlog produit.
Un changement est l’activité réalisée pour résoudre un problème ou implanter une

solution
Un risque peut être associé à un problème, un enjeu ou un élément du backlog.
Ces contrôles sont mesurés, corrélés et suivis. Les principaux contrôles sont le backlog
et les risque. Le backlog doit être de haut niveau pour commencer et raffiné en cours de

projet. La liste des risques se rédige lorsque le backlog, les enjeux et les problèmes sont plus
détaillés. Lorsque le logiciel est complété, les risques sont rendus à un niveau acceptable.
Figure 2.15 – Vue d’ensemble de la méthode Scrum
Certains prétendent que scrum pourrait se voir étendre à divers secteurs de l’entreprise.
C’est un retour aux sources, car à son origine, scrum ne s’adressait pas au développement
logiciel. Puisant ses racines au milieu des années 1980, scrum amène une dynamique différente
de la gestion de projets des développements logiciels. Elle propose un équilibre entre la
portion définie et portion chaotique de développement de produit. Cette méthode ne précise
pas de technique de réalisation prise. Elle laisse cet aspect à la discrétion de l’équipe. Cette
ouverture permet l’inclusion de pratique provenant d’autres méthodes. En détachant l’aspect
logiciel et en portant cette approche a d’autre domaine d’ingénierie.
2.3 Étude Conceptuelle

Dans le domaine informatique, l’analyse et la conception de Système Informatiques est
formalisés par des méthodes et/ou langages de conception et de modélisation. Il est donc
question pour nous de définir le langage utilisé tout au long du projet afin de modéliser d’une
manière claire et précise la structure et le comportement de notre système indépendamment
de tout langage de programmation.

2.3.1 Présentation du langage UML
Le langage de modélisation unifié, de l’anglais Unified Modeling Language (UML). Est

un langage standard, pour spécifier, visualiser, concevoir et documenter tous les aspects
d’un système d’information. Il fournit un support de communication, un langage graphique
comportant 13 diagrammes standards (UML 2.0). Il permet d’exprimer et d’élaborer des
modèles objet, indépendamment de tout langage de programmation. UML est la fusion de 3
langages la modélisation objet des années 90 :
— OMT créer par James RUMBAUGH : elle représente les vues statiques et fonctionnelles
d’un système
— Booch créer par Grady Booch : Elle utilise 7 diagrammes pour représenter un système
orienté objets.
— OOSE créer par Ivar Jacobson : elle se base sur l’analyse fondée sur la description des
besoins des utilisateurs (use cas)
UML spécifie plusieurs objectifs pour la conception d’un système :
— Comprendre et décrire les besoins
— Spécifier, édifier et documenter un système à base de logiciel
— Établi l’architecture logicielle
— Ils ne perdront plus de temps à attendre à la caisse
2.3.2 Intérêt de concevoir avec UML
Nous pouvons citer comme intérêt :
— C’est un langage très proche de la programmation orienté objet (POO)
— C’est un langage formel normalisé
— Gain de précision
— Gage de stabilité
— Encourage l’utilisation d’outil
— C’est un support de communication performant

— Il cadre l’analyse
— Il facilite la compréhension des représentations abstraites complexes
— Il est souple et polyvalent, ce qui le rend universel
— UML n’est pas une méthode mais une notation qui laisse la liberté de conception
— Il permet de modéliser tous les types de système d’information, mais qui nécessite
toutefois une méthodologie de conception.
2.3.3 Les types de digrammes UML
UML définit un modèle à l’aide de diagrammes. Un diagramme est une représentation

graphique d’un aspect d’un système d’information ou d’une structure précise. Ces digrammes
UML donnent une vue globale du système, selon les aspects statiques et dynamiques du
modèle.
Les diagrammes sont représentés selon deux aspects : Statique (structure) et compor-
temental (qui embarque un aspect d’interaction).
Figure 2.16 – Diagramme UML 2.0

Ces diagrammes, d’utilisé variable selon les cas, ne sont pas nécessairement tous pro-
duits à l’occasion d’une modélisation. Les plus importants pour la maitrise d’ouvrage sont
les diagrammes d’activités, cas d’utilisation, de classe, d’objets, de séquence et d’état transi-
tions. Les diagrammes d’œuvre qui permettent de formaliser les contraintes de la réalisation
et la solution technique. Dans notre cas pour notre travail, nous utiliserons parmi les 13
diagrammes proposés par UML :
— Le diagramme de cas d’utilisation
— Le diagramme de classe
— Le diagramme de séquence
— Le diagramme de composant
— Le diagramme de déploiement
2.3.4 Concept générale
La conception d’un système d’information n’est pas évidente car il faut réfléchir à l’en-
semble de l’organisation que l’on doit mettre en place. La phase de conception nécessite
des méthodes permettant de mettre en place un modèle sur lequel on va s’appuyer. La
modélisation consiste à créer une représentation virtuelle d’une réalité de telle façon à faire
ressortir des points auxquels on s’intéresse. Ces différents modèles sont réalisés dans des AGL
(Atelier Génie Logiciel).
A - Atelier Génie Logiciel
Visio, StarUML, ArgoUML, Enterprise Architect, Power AMC. . . etc, sont des alterna-
tives populaires qui aident surtout les programmeurs, les ingénieurs système pour concevoir
des diagrammes UML. Ils sont produits avec un grand nombre de fonctionnalités, ainsi que
des options de personnalisations et inclus tous les outils nécessaires pour aider les utilisateurs
à réaliser des schémas de conception à des fins diverses. Concernant notre projet, nous avons
jeté notre dévolu sur l’outil de conception StarUML. Afin de justifier le choix de notre AGL,
une étude comparative est nécessaire. Le tableau ci-dessous décrit les AGL cités plus haut
et justifie le choix de notre environnement.

Tableau 2.8 – Présentation des AGL
NOM Description
PowerAMC c’est un outil cher (entre 2000 et 7000 ¿) mais permet une
modélisation extrêmement complète et performante. Ce logiciel est
plus adapté à un travail de groupe, il ouvre également la possibilité
à un freelance d’avoir un outil des plus performants sur le marché
de par ses fonctions d’analyse ou de partage de données. Il permet
la modélisation de données, la modélisation de processus métier,
la conception et la rétroconception. Le tout basé sur la méthode
Merise.
ArgoUML supporte sept types de diagrammes UML : cas d’utilisation, classes,
séquence, état, collaboration, activité et déploiement. La génération
du code à partir du diagramme de classe est supportée dans les
langages java, C++, C# et SQL.
StarUML Il a été cédé par son éditeur à la communauté open source. Elle
ce se substitue à des solutions commerciales coûteuses. Il n’a pas
été maintenu à jour depuis 2008 d’après son site, mais il permet
néanmoins de gérer la plupart des diagrammes d’UML.
Enterprise Architect Bien plus qu’un modeleur UML, Enterprise Architect permet de
s’interfacer avec les outils de développement IDE Visual Studio ou
Eclipse. Il est disponible en 6 versions (Corporate, Professional,
Desktop, Ultimate, Systems Engineering et Business). Une Version
d’évaluation limitée dans le temps est proposée.
A parti de ce tableau, nous justifions notre choix sur StarUML, car c’est un outil qui
permet d’analyser, de dessiner tous types de diagramme UML et de générer le code source
à partir de diagramme et d’élaborer la documentation.

B - Captures des besoins
Suite à l’analyse des besoins dans le cahier de charges, nous avons capturé les besoins
en fonction de l’acteur(client) dont les fonctionnalités respectives sont énumérées ainsi qui
suit :
— Scanner les codes-barres ou QR-Code des produits à l’aide du téléphone
— Réaliser l’enregistrement des produits au maximum dans le panier
— Modifier la quantité d’articles contenus dans son panier
— Transférer le contenu du panier à un compte distant pour contrôle ou pour paiement
— Valider ou annuler la facturation des produits se trouvant dans son panier d’achat
C - Diagrammes UML
Modélisation du Diagramme de cas d’utilisation
— Principe du diagramme de cas d’utilisation
Le diagramme de cas d’utilisation modélise le comportement d’un système et permet

de capturer les exigences du système. Il décrit les fonctions générales et la portée d’un
système. Ce diagramme identifie également les itérations entre le système et ses acteurs.
Les cas d’utilisation et les acteurs dans le diagramme de cas d’utilisation décrivent ce
que le système fait et comment les acteurs l’utilisent, mais ne montrent pas comment
le système fonctionne en interne.
Le diagramme de cas d’utilisation illustre et définis le contexte et les exigences d’un

système entier, ou des parties essentielles d’un système. Nous pouvons modéliser un
système complexe ave un diagramme de cas d’utilisation, ou créer de nombreux dia-
grammes de cas d’utilisation pour modéliser les composants du système. Ce diagramme
est essentiel dans les premières phases d’un projet, c’est pour cette raison que nous
nous y référerons tout au long du processus de développement.

Les différents éléments d’un diagramme de cas d’utilisation sont entre autres :
Les acteurs : un acteur représente un ensemble cohérent de rôles joués par les
utilisateurs des cas d’utilisation en interaction avec le système. En règle générale,
un acteur représente un rôle qu’un Homme, une machine ou même un autre
système joue avec le système. On distingue 4 grandes catégories d’acteurs.
— Les acteurs principaux : Cette catégorie regroupe les personnes qui utilisant
les fonctions principales du système.
— Les acteurs secondaires : Cette catégorie regroupe les personnes qui effectuent
des tâches administratives ou de maintenance.
— Le matériel externe : Cette catégorie regroupe les dispositifs matériels avec

les quels le système interagit comme les périphériques.
— Les autres systèmes : Cette catégorie regroupe les systèmes avec lesquels le
système interagit.
Les relations entre les cas d’utilisation : UML définit trois types de relations
standardisée entre les cas d’utilisations :
— La relation d’inclusion : formalisée par le mot clé include, implique que le cas
d’utilisation de base doit incorporer explicitement un autre de façon obliga-
toire.
— La relation d’extension : formalisée par le mot clé extend, implique que le cas
d’utilisation de base en incorpore explicitement un autre, de façon optionnelle.
— La relation de généralisation ou spécification : les cas descendants, hérite de

la description de leur parent commun. Chacun entre eux peut néanmoins
comprendre des interactions spécifiques supplémentaire.
— Diagramme de cas d’utilisation de notre projet

Figure 2.17 – Diagramme de cas d’utilisation
— Description textuelle des cas d’utilisation
— Cas d’utilisation choisir agence (Un supermarché peu avoir plusieurs agence différente
repartie dans la ville ou le pays)

Tableau 2.9 – Description du cas d’utilisation choisir agence
Acteur Principal Client
Objectif Choisir une agence

Précondition Ouvrir l’application
Scénario Normal
— Cliquer sur l’icône de l’agence dans laquelle le client
se trouve
— Le serveur traite la requête
— Les requêtes envoyées se feront sur la base de

données de l’agence choisie
— L’interface de scan s’ouvre
Alternative Le système affiche un message d’erreur en cas dans le

cas où l’agence n’existe pas ou qu’il a une erreur de
connexion au serveur
— Cas d’utilisation scannée un produit

Tableau 2.10 – Description du cas d’utilisation scanné un produit
Objectif Afficher prix

Précondition Ouvrir l’application
Scénario Normal
— Ouverture du lecteur de scanne de code barre
— Le client scanne le code barre
— Le Système compare le code récupéré à celui de la

BD
— Le serveur traite la requête et fournit les données

requises
— Le système affiche à l’écran le prix du produit
Alternative Le système affiche un message d’erreur en cas dans le cas

où le produit en BD n’existe pas ou qu’il a une erreur
de connexion au serveur
— Cas d’utilisation Ajouter produit au panier

Tableau 2.11 – Cas d’utilisation Ajouter produit au panier
Objectif Ajouter au panier

Précondition
— Choisir l’agence
— Scanné le produit
Scénario Normal
— Le client reçoit le prix du produit
— Incrémente la quantité désirée puis click sur le bou-

ton ajouter
— Puis le panier est mis à jour
Alternative Le client click sur le bouton annuler puis sur refaire le

scan ou quitter l’application
— Cas d’utilisation supprimé produit dans le panier

Tableau 2.12 – Description du cas d’utilisation Supprimer produit du panier
Objectif Supprimer un produit du panier

Précondition
— Scanner produit
— Consulter son panier
Scénario Normal
— Le client clique sur l’icône du panier
— Une fois la liste affichée, le client sélectionne le pro-

duit à supprimer
— Après le traitement des données par le serveur, il

envoie un message de validation
— Le client confirme son action
— Le système affiche à l’écran le produit supprimer

avec succès
— Puis le panier est mis à jour
Alternative Le système affiche un message d’erreur au cas d’une in-

disponibilité
— Cas d’utilisation valider les achats

Tableau 2.13 – Description du cas d’utilisation validé achats
Objectif Valider les achats

Précondition
— Scanner produit
— Ajouter au panier
Scénario Normal
— Le client clique sur le bouton valider achat
— Après le traitement des données par le serveur, il

envoie un message de validation
— Le client valide la facturation des produits
— Génération du lien de paiement
Alternative Le client annule l’achat des produits du panier
— Cas d’utilisation transférer panier

Tableau 2.14 – Description du cas transférer panier
Objectif Transférer le panier à un compte distant pour contrôle

ou paiement
Précondition
— Scanner produit
— Ajouter au panier
Scénario Normal
— Le client clique sur le bouton valider achat
— Le client clique sur le bouton transférer
— Entrer le numéro du client distant puis cliquez sur

envoyer
— Le système affiche un message de confirmation
— Le client valide, puis le système affiche un message

de succès
Alternative Le client annule l’action ou le serveur renvoie une erreur

de connexion
— Cas d’utilisation payé via Orange Money

Tableau 2.15 – Description du cas d’utilisation payé Orange Money
Objectif Effectuer le paiement via son compte Orange Money

Précondition Valider achat des éléments dans le panier
Scénario Normal
— Le client clique sur l’icône payé via Orange Money
— Ouverture de l’interface
— Renseignement des informations nécessaire à la

transaction
— Le client approuve la transaction
— Le système affiche un message de succès
Alternative LLe client annule la transaction ou il y a une erreur de

connexion au serveur
Modélisation du Diagramme de classe
— Principe du diagramme de classe
Le diagramme de classe appartient à l’un des six types de diagramme structurel. Il

est fondamental pour le processus de modélisation des objets et modélisant la structure
statique d’un système. Suivant la complexité d’un système, nous pouvons utiliser un
seul diagramme de classe pour modéliser un système complet ou bien nous pouvons
utiliser différents diagrammes de classes pour modéliser les composants d’un système.
Le diagramme de classe est le plan de notre système ou sous-système. Nous utilisons

ce diagramme de classe pour modéliser les objets qui constituent le système, pour
afficher les relations entre les objets et pour décrire ce que ces objets font et les services

qu’ils fournissent. Les différents éléments qui composent un diagramme de classe sont :
— Un objet : C’est une entité qui a un sens dans le contexte de l’application
— Classe d’objet : Ils décrivent un groupe d’objet ayant des propriétés similaires, un
comportement commun, des relations communes à tous les objets d’une classe.
— Une opération : Elle est associée à une classe. C’est une fonction ou une transfor-
mation qui peut être appliquée aux objets d’une classe. Une opération peut avoir
des paramètres.
— Un identifiant : C’est une propriété particulière d’un objet telle qu’il n’existe pas
deux occurrences de cet objet pour lesquelles cette propriété pourrait prendre une
même valeur.
— Une association : Appelé aussi relation, est un lien sémantique entre plusieurs
classes. Une association peut relier une, deux, ou plusieurs classes. Elle est dite
n-aire dans le cas où elle relie deux classes, elle est dite binaire. Les classes des
relations sont représentés par des hexagones dont l’intitulé décrit le type de re-
lation qui relie des classes d’entités (généralement un verbe d’action). On peut
éventuellement ajouter des propriétés aux classes de relations.
— Diagramme de classe du projet

Figure 2.18 – Diagramme de classe
Modélisation du Diagramme de séquence
— Principe du diagramme de séquence
Un diagramme de séquence est un diagramme qui représente la séquence de mes-

sages entre les objets au cours d’une interaction. Un diagramme de séquence comprend
un groupe d’objets, représentés par des lignes de vie et les messages que ces objets
échangent lors de l’interaction. Il décrit les interactions entre un groupe d’objet en
montrant de façons séquentielles, les envois de message qui interviennent entre les ob-
jets. Il peut également montrer les flux de données échangées lors des envois messages.
Le diagramme de séquence est composé de :
— Cadre d’interaction : Il fournit un contexte ou une limite pour le diagramme de

séquence dans lequel nous créons des éléments tels que des lignes de vie ou des
messages et dans lequel vous observez les comportements.

— Lignes de vie : Cela représente les objets entrant dans une interaction. Dans un
scénario d’un supermarché par exemple, les lignes de vie peuvent représenter des
objets commet le système de facturation ou un client. Chaque instance d’une
interaction est représentée par une ligne de vie.
— Messages : Un message est un élément qui définit un type particulier de communi-

cation entre les instances au cours d’une interaction. Un message fait circuler des
informations d’une instance, représentée par une ligne de vie, à une autre instance
au cours d’une interaction.
— Fragments combinés : Les fragments combinés sont des regroupements logiques

représentés par un rectangle et contenant les structures conditionnelles qui af-
fectent le flux de message. Il contient des opérandes d’interaction et est défini par
un opérateur d’interaction.
— Utilisation des interactions : Permet de construire une séquence complète et com-

plexe à partir d’interactions plus petites et plus simples.
— Diagramme de séquence scanner produit

Figure 2.19 – Diagramme de séquence scanner un produit
Pour effectuer ses achats, le client ouvre l’application, choisis l’agence. L’appareil de
photo s’ouvre et il scanne le produit. Après le scanne, le système envois une requête
au serveur pour traiter les informations envoyées. Si les informations sont correctes
le client prendra connaissance du prix du produit et pourra ainsi l’ajouter ou non au
panier ou refaire un scan, sinon un message d’erreur sera affiché.
— Diagramme de séquence supprimer produit

Figure 2.20 – Diagramme de séquence supprimer produit
Lorsque le client veut supprimer un ou plusieurs produits, il demande la liste des

produits du panier, ensuite il choisit celui à supprimer. Le système envoie une requête
au serveur pour traiter les informations envoyées, si la requête est valide, le message de
suppression avec succès s’affiche sinon un message d’erreur sera affiché. La modification
d’un produit suit le même scénario.
Modélisation du Diagramme de composant
— Principe du diagramme de composant

Dans UML le diagramme de composant représente la structure du système logiciel,

qui décrit les composants du logiciel, leurs interfaces et leurs indépendances. Nous
pouvons utiliser le diagramme de composant pour modéliser des systèmes logiciels à
un haut niveau ou pour afficher des composants à un niveau inférieur, au niveau du
package. Ce type de diagramme prend en charge le développement à base de compo-
sant, dans lequel un système logiciel est divisé en composants et interfaces qui sont
réutilisables et remplaçables. Le diagramme de composants est utile pour les raisons
suivantes :
— Définition des aspects exécutables et réutilisables d’un système logiciel
— Mise en évidence des problèmes de configuration logicielle à travers les relations

de dépendance
— Représentation précise d’une application logicielle avant que vous n’y apportiez
des changements ou des extensions
Les éléments qui composent le diagramme de composants :
— Composants : Les composants sont les éléments du modèle qui représentent des les
éléments indépendants, interchangeables d’un système. Ils respectent et réalisent
une ou plusieurs interfaces fournies et obligatoire, qui déterminent le comporte-
ment des composants.
— Instances de composant : Ce sont des éléments de modèle qui représentent des

entités réelles dans un système.
— Package : Il regroupe des éléments de modèle associés de tout type, y compris

d’autres packages.
— Artefacts : Ce sont des éléments de modèle qui représente les entités physiques
dans un système logiciel. Les artéfacts représentent des unités physiques d’implémentation,
telles que des fichiers exécutables, des bibliothèques, des composants de logiciel,
des document et bases de document.
— Interfaces : Ce sont les éléments de modèle qui définissent des ensembles d’opérations
que d’autres éléments de modèle, tels que des classes ou des composants, doivent

implémenter. Un élément de modèle d’implémentation réalise une interface en

remplaçant chacune des opérations que l’interface déclare.
— Relations dans le diagramme de composants : C’est une connexion entre les

éléments du modèle.
— Diagramme de composant du projet
Figure 2.21 – Diagramme de composant
Modélisation du Diagramme de déploiement
— Principe du diagramme de déploiement
Le diagramme de déploiement modélise l’architecture physique d’un système. Il af-

fiche les relations entre les composants logiciels et matériels du système, d’une part et

la distribution physique du traitement, d’autre part. Il présente la disposition physique

des nœuds dans un système réparti, mes artefacts qui sont stockés sur chaque nœud
et les composants. Les nœuds représentent des périphériques matériels tels que des
ordinateurs, des détecteurs et des imprimantes, ainsi que d’autres périphériques qui
prennent en charge l’environnement d’exécution d’un système. Les chemins de com-
munication et les relations de déploiements modélisent les connexions dans le système.
Les différents éléments de ce modèle de diagramme de déploiement sont entre autres :
— Nœud : Représentés par des cubes, sont des éléments de modèle qui représentent
les ressources informatiques d’un système, telles que les ordinateurs personnels,
les détecteurs, les périphériques d’impression ou de serveurs. Les nœuds peuvent
être connectés à l’aide de chemins de communications pour décrire les structures
de réseau.
— Instance de Nœud : C’est un élément de modèle qui représente une instanciation

ou une occurrence réelle d’un nœud. Les instances de nœuds sont basées sur des
nœuds existants.
— Composants : représentés par des boı̂tes rectangulaires avec deux rectangles sor-
tant du côté gauche, sont les différentes parties du système étudié.
— Artefacts : Ce sont des éléments de modèle qui représente les entités physiques
dans un système logiciel. Les artefacts représentent des unités physiques d’implémentation,
telles que des fichiers exécutables, des bibliothèques, des composants de logiciels,
des documents et bases de documents.
— Instances d’artefact : Ce sont des éléments de modèle qui représentent une ins-
tanciation ou une occurrence réelle d’un artefact. Les instances d’artefacts sont
basées sur des artefacts existants.
— Relation : C’est une connexion entre des éléments de modèle. Elle ajoute une
sémantique à un modèle en définissant la structure et le comportement entre les
éléments du modèle.
— Diagramme de déploiement

Figure 2.22 – Diagramme de déploiement
Ce chapitre est d’une grande importance pour la suite du travail, du fait qu’il projette
les notions théoriques vues dans l’étude bibliographique, sans laquelle la réalisation ne pourra
se faire comme il se doit. Dans ce chapitre nous avons d’abord décrit le fonctionnement
général de notre application, puis expliqué le fonctionnement détaillé de chaque sous-système
composant le système global par le moyen des schémas explicatifs et une modélisation par
des diagrammes UML. Le chapitre suivant du rapport sera consacré à l’implémentation.

CHAPITRE 3
IMPLÉMENTATION ET RÉSULTATS
Ce chapitre est constitué des sections qui corresponde respectivement à la plateforme de

développement, au choix de la technologie, l’architecture du système, le résultat, la discussion
et les perspectives.
3.1 Plateforme de développement mobile

Une application mobile est un logiciel applicatif développé pour un appareil électronique
mobile, tel qu’un assistant personnel, un téléphone portable, un smartphone, un baladeur
numérique, une tablette tactile, ou encore certains ordinateurs fonctionnant avec le système
d’exploitation Windows Phone ou Chrome OS. Elles sont pour la plupart distribuées de-
puis des plateformes de téléchargement (parfois elles-mêmes contrôlées par les fabricants
de smartphones) telles que l’App Store (plateforme d’Apple), Google Play (plateforme de
Google pour Android) ou encore le Microsoft Store (plateforme de Microsoft pour Windows
Mobile). Le développement des applications déployées sur ces différents environnements peut
se faire en : Hybride, Natif ou Cross plateforme.
3.1.1 Présentation des plateformes de développement
Développement natif : Le développement d’applications mobiles natives est la manière

traditionnelle de créer des applications pour chaque système d’exploitation mobile, en
utilisant différents langages de programmations et en tenant compte des fonctionna-
lités de chaque plate-forme. Les applications en natif sont appréciées des développeurs
pour leur facilité d’intégration au système d’exploitation. Elles peuvent être utilisées
sur toutes les plateformes de développement.
La principale caractéristique de ce type d’application c’est qu’elle n’est compatible

qu’avec des terminaux mobiles correspondant au système d’exploitation sur lequel elle
92
été développée. Cela veut dire que si l’application native est développée en langage de
programmation Java ou Kotlin (dans l’IDE Android Studio), elle ne pourra fonctionner
qu’avec un smartphone ou une tablette dont le système d’exploitation est Android. Si
en revanche elle est développée en xCode, Swift ou Objective-C (dans un environnement
Apple), elle ne sera compatible qu’avec un iPhone ou un iPad. Ou encore si elle est
développée en C# (dans l’IDE Visual Studio de Microsoft), elle ne pourra fonctionner
qu’avec un smartphone ou une tablette dont le système est Windows.
Développement hybride : Les applications hybrides sont logées dans un conteneur

natif qui utilise une plateforme mobile WebView. Lors de l’utilisation de l’application,
ce système affiche un contenu web en son sein grâce à l’utilisation de technologie web
(CSS, JavaScript, HTML, HTML5). Il s’agit en réalité de page web adapté pour un
affichage WebView sur téléphone. Cet affichage du contenu web peut avoir lieu dés
l’ouverture de l’application ou bien se produire sur certaines parties de l’application
uniquement (sur le tunnel de vente seulement par exemple).
L’avantage de l’application hybride est qu’elle est plus facile et plus rapide à développer
qu’une application native. La maintenance de l’application sera également plus facile
puisqu’il n’y a qu’une seule version à revoir pour plusieurs plateformes. Cordova, Phone-
Gap, Ionic sont par exemple des technologies qui permettent de réaliser une application
hybride.
Développement Cross Plateforme : Le développement d’une application passe

souvent par la question de la plateforme sur laquelle on souhaite la rendre dispo-
nible (sur ordinateur, sur le web ou sur mobile). Créer une application qui pourra être
utilisé par tout le monde implique en théorie de devoir développer plusieurs fois la
même application pour chacune des plateformes ciblées. Le développement en mode
cross vient donc proposer de nombreuses solutions pour développer une application
une seule fois et la rendre disponible sur toutes les plateformes souhaitées sans ef-
forts supplémentaires. Cela réduit le coût de développement, de maintenance, avec une
équipe de développeur unique. Flutter, React Native, Xamarin sont par exemple des
technologies qui permettent de réaliser une application en Cross plateforme.

3.1.2 Limites de ces plateformes de développement
Développement natif :
— Elle doit être réécrite à chaque fois qu’on la destine à une plateforme bien précise,
elle pose un problème de transférabilité des codes.
— Consommation du temps : Pour toucher une cible très large, il est donc nécessaire
d’adapter à chaque fois le langage de programmation à la plateforme ciblée, ce qui
exige un effort de programmation (écriture de code) et a un impact sur le nombre
d’heure de travail.
— Coût (augmentation des effectifs) : Il faudra au besoin recruter des développeurs

ayant des compétences spécifiques et propres à chaque système d’exploitation.
Cette particularité peut avoir un impact sur le coût de développement de l’appli-
cation.
Développement Cross Plateforme :
— Interface utilisateur limités : l’interface utilisateur n’est pas fluide, les possibilités
(3D par exemple) sont aussi limitées du fait de l’application du WebView qui ne
permet pas d’exploiter tout le potentiel du smartphone.
— La difficulté d’exploiter toutes les capacités des plateformes : chaque plateforme,

iOS ou Android, a des capacités uniques qu’un développeur peut souhaiter exploi-
ter. Avec une application hybride, il faut combiner des plugins et code spécifique
à la plateforme.
— Performances : Les transitions entre les pages sont plus lentes
— Vitesse : Elle dépend de la vitesse du navigateur.
Développement Cross Plateforme :
— Une performance moindre : La latence observée est problématique si l’applica-

tion présente plusieurs fonctionnalités. Il est conseillé pour des applications assez
simples et standard, qui n’ont pas besoin de performances trop levées.
— Une dépendance au Framework : Afin d’assurer la compatibilité de votre applica-

tion il est nécessaire de suivre les mies à jour du Framework.

— Les interfaces utilisateurs : En matière de design, les interfaces sont moins im-
mersives comparer aux applications natives, l’aspect est standard sur toutes les
plateformes et manque souvent de personnalisation.
— Communauté développeur plus réduite
Figure 3.1 – Comparaison plateforme Native, Cross plateforme et hybride
3.1.3 Plateforme de développement choisie
A - Pourquoi le choix du développement natif ?
Bien que le terme d’application native ne soit pas très connu du grand public, cela
représente la grande majorité des applications que nous téléchargeons chaque jour. Ce mode
de développement offre une expérience utilisateur inégalée parmi toutes les applications mo-
biles et offre d’excellentes performances. Il est généralement envisagé lorsque la fréquence
d’utilisation de l’application est très régulière.
Une fois téléchargées et installées dans la mémoire d’un smartphone ou d’une tablette,
les applications natifs permettent aux utilisateurs de tirer pleinement profit de toutes les
fonctionnalités de son appareil et d’avoir accès sans limites à différents services tels que :
— Le GPS

— Appareil photo
— Vidéo
— Contact
— Accéléromètre etc.
Cependant, il ne permet pas seulement d’avoir des performances accrues et d’accéder à

toutes les fonctionnalités du téléphone. Lorsqu’elles sont bien pensées et réalisées, les appli-
cations natives respectent les codes design de chaque plateforme. Elles permettent également
de s’adapter à chaque plateforme afin de proposer à vos utilisateurs une expérience optimale.
En somme nous pouvons justifier notre choix du développement natif par les différents points
suivants :
— Performances extrêmement rapides et réactives
— Personnalisation avancée car elle est facile à configurer
— Bonne Expérience utilisateur, grâce aux interface fluide et belle
— Mise à jour instantanée possible au lancement de l’application
— Sécuritaire, fiable et stable
— Processus de test facilité par un émulateur durant l’implémentation
— Rend me processus de fidélisation plus simple grâce aux notification push
— Possibilité de communication avec d’autres d’applications installées
— Possibilité d’y accéder en mode hors connexion
B - Pourquoi le choix d’une application Android ?
Aujourd’hui plus que jamais auparavant, les smartphones sont au cœur de nos vie et
nous accompagnent au quotidien. Les applications que nous téléchargeons pour combler
nos besoins confirment bien cette tendance. Concernant le marché des applications mobiles,
Google et Apple dominent sur Windows. Android de Google représente environ 80% du
marché tandis que son principal concurrent, iOS qui est développé par Apple, représente un
peu moins de 20% du marché.

Face à cette différence considérable observée sur le marché, l’équipe projet prend la
résolution d’implémenter dans un premier temps une version Android afin de toucher la plus
grande partie des utilisateurs. Ce système d’exploitation se différencie principalement de ses
concurrents par le fait qu’il soit ouvert (Open Source). Le modèle économique de Google
semble très pertinent, l’adoption d’Android par les fabricants sera probablement rapide du
fait de la gratuité d’utilisation pour le constructeur.
Nous avons vu plus haut la notion de développement d’application mobile à travers

ses différentes plateformes de développement. Il en ressort que nous portons notre attention
sur le développement natif Android. La suite de notre travail consiste à présenter les outils
que nous avons utilisé, l’architecture générale du projet, les maquettes et le résultat.
3.2 Outils, technologies et résultats obtenus

Après avoir effectué une conception qui répondra aux besoins de l’application, nous conti-
nuons avec l’étape de réalisation en exposants le choix des différents outils et langages de
développement utilisés lors de la réalisation, l’architecture de la solution ainsi qu’un aperçu
sur les interfaces de notre application Android.
3.2.1 Outils, technologies et langages de développement
A - Outils et technologie de développement
Le développement d’un tel système nécessite l’utilisation de quelques outils. Dans ce qui
suit, nous citons les outils qui ont été utilisé.

Tableau 3.1 – Outils de développement
Nom Description
Postman Postman permet de construire et d’exécuter des requête HTTP, de les stocker
dans un historique afin de pouvoir les rejouées, mais surtout de les organiser
en Collections.
WampSever c’est un ensemble de logiciels permettant de mettre en place un serveur web
local, un serveur FTP et un serveur de messagerie électronique. La version
utilisée est 3.2.1, Apache 2.4.48, MaraiDB 10.4.21, PHP 8.0.10, phpMyAdmin
5.1.1
MySQL (My Structured Query Language) version 5.7.19 est une base de données re-
lationnelle libre et Apache(serveur web), basé sur un modèle client-serveur.
Son rôle consiste à stocker et à gérer une grande quantité de données en les
organisant sous forme de table.
Android Studio c’est un environnement pour développement et programmation entièrement
intégré qui a été lancé par Google pour le système Android.
Software De- c’est une collection d’outils de développement logiciel dans un seul package
velopment Kit installable. Le développement d’une application Android sur la plateforme Java
(SDK) nécessite un kit de développement Java.
Gradle c’est un moteur de production fonctionnant sur la plateforme Java. Il permet
de construire des projets Java.
JDK (Java De- désignent un ensemble de bibliothèque logicielle de base de langage de pro-
velopment Kit) grammation java. C’est un outil avec lequel le code java est compilé.
JAVA c’est un langage qui permet la programmation des applications Android, des
logiciels pour Windows et linux et des librairies.
Firebase c’est un ensemble de services d’hébergement pour n’importe quel type d’appli-
cation. Il propose d’héberger en NoSQL et en temps réel des bases de données,
du contenu, de l’authentification sociale, et des notifications, ou encore des
services, tel que par exemple un serveur de communication temps réel.

A - Architecture logiciel du projet
Opérer une connexion directe à la base de données depuis le téléphone Android n’est pas
conseillé d’un point de vue architecture logicielle. Il est don nécessaire d’avoir une couche
serveur intermédiaire qui sera habilité à se connecter à la base donnée, ce qui est plus sécurisé.
Nous allons écrire les scripts en PHP pour gérer la base de données et exécuter ces scripts
en utilisant le protocole HTTPS.
En fait, si nous parlons de l’architecture 3-tiers, le client est la plateforme Android,

le serveur web est le PHP, le serveur de base de données est MYSQL et Firebase. Lorsque
notre application Android s’exécute, elle va être connectée au serveur web qui va récupérer les
données depuis la base de données MySQL en utilisant les services web. Ensuite les données
seront encodées au format JSON et envoyées au système Android. L’application va obtenir
ces données codées. Elle les analysera et les affichera sur le mobile. En faite notre projet est
divisé en deux parties à savoir l’écriture des script PHP, et le développement de l’application
Android.
Figure 3.2 – Architecture logiciel

3.2.2 Résultat
En résumé, il est question pour notre client une fois l’application installée et ouverte, il
pourra faire le choix de l’agence dans laquelle il se trouve, de scanner un produit, approuver
l’ajout au panier en renseignant sa quantité, de visualiser le contenu de son panier, de
modifier son panier, supprimer un élément, valider le paiement, transférer sa facture à un
compte distant pour le paiement ou le contrôle. Voici les captures des maquettes :
Figure 3.3 – Interface de connexion
Sur cette interface de connexion, le client entre ces informations d’identification qui ont
été créé lors de l’inscription.

Figure 3.4 – Interface d’inscription
Sur cette interface si, le client s’inscrit en entrant son nom, son email et son mot de passe.
Les informations demandé on été allégé pour ne pas alourdir l’inscription sur la plateforme.

Figure 3.5 – Interface de réinitialisation du mot de passe
Sur cette interface si, le client peut réinitialiser son mot de passe en cas d’oubli d son
mont de passe.

Figure 3.6 – Interface de scannage du produit
Sur cette interface, le client scan les différents produits qui veut ajouter à son panier.

Figure 3.7 – Interface du Panier
Sur l’interface suivante, le client peut voir les produits qu’il vient de scanner et le total
du prix de ceux-ci.
3.2.3 Interprétations et discussion des résultats
A - Discussion des résultats obtenus
Durant la réalisation de ce travail, nous avons rencontré un certain nombre de difficultés

parmi lesquelles :
— L’implémentation du lecteur du code barre

— La vérification entre le code barre en base de données et celui scanner par le client
Bien que nous soyons heurtés à ces difficultés, nous avons su trouver voie et moyen pour
palier à ces difficultés et accomplir 80% de notre travail.
Tâches Test
Version minimum Android 5.1(lollipop) Fait
Nombre d’interface (11) 7/11
Lecteur de Code barre Fait
Panier Fait
Page connexion Fait
Page Inscription Fait
Modification panier Fait
Ergonomie Fait
Lisibilité textuelle Fait
Paiement intégré (Api Orange Money) En cours
Profile Fait
Historique de paiement En cours
Transférer panier En cours
Application iOS En cours
Lecteur de QR-code En cours
B - Perspective
Nous pouvons à présent dire que le challenge de concevoir une application Android pour
l’optimisation du temps de course est atteints à un certain pourcentage, car sur l’univers du
développement des application, il n’existe aucunement de politique de sécurité et fiabilité à
100%. Il n’en demeure pas moins vrai que des améliorations soient possibles. Ces éventualités
sont :
— Intégrer les moyens de paiements électronique (Orange Money)

— Permettre au client de faire ses achats depuis son domicile ou au bureau ou encore peu
importe sa situation géographique de se faire livrer
— Permettre au client d’imprimer lui-même sa facture
— Développer un version iOS de l’application
— Faire un penteste de sécurité de l’application pour trouver d’éventuel faille et les cor-
rigés
Nous devons indubitablement reconnaı̂tre que ce travail nous a permis d’affuter nos compétences
en matière e systèmes d’informations, notamment dans le domaine du développement mo-
bile.

Conclusion Générale
Dans le cadre de notre mémoire de fin d’étude, il nous a été demandé d’optimiser le
temps de course dans un supermarché. Pour y parvenir nous avons commencé par faire des
études préliminaires qui nous ont permis de cerner les contours et les rouages du projet. Par
la suite nous sommes passé à la conception détaillée en nous appuyant sur la méthode de
développement Agile Scrum et le langage UML qui nous a permis de modéliser le système
en le matérialisant comme un ensemble d’objets. Pour l’implémentation de notre applica-
tion nous avons opté pour les choix des technologies suivante : Java, PHP, Xml. . . Durant
l’exécution de notre projet, nous avons rencontré des difficultés (l’implémentation du lecteur
de code barre, la connexion de notre API avec la base de données. . . etc.), certains ont pu
être résolue. Des perspectives ont été envisagées (intégré les solutions de paiement mobile,
développer la version iOS, permettre aux clients de faire des achats depuis leur domicile ou
ailleurs et de ce faire livrer) pour l’extension de l’application.
La réalisation de notre projet a été très bénéfique pour nous, car elle nous a permis
d’approfondir nos connaissances apprises tant théorique que pratique durant notre parcours
universitaire à travers la conception des systèmes d’informations et de développement des
logiciels d’application. Nous avons essayé de réaliser ce projet dans le but de réduire, voire
de supprimer la pénible attente des clients au niveau des caisses. Mais également de fidéliser
d’avantage la clientèle des supermarchés sur le territoire camerounais en leur permettant
d’optimiser leur processus d’achat. Nous avons appliqué autant que faire se peut les règles
de bases permettant d’avoir une solution performante et nous souhaitons que cette solution
trouve les conditions nécessaires pour entrer en vigueur.
107
Références Bibliographiques
[(Auteur), 2021] (Auteur), C. (2021). Petit Larousse Illustré 2022. Larousse.
[Balachandran, 1993] Balachandran (1993). Processus d’optimisation selon Asimow.
[Bhardwaj, 2016] Bhardwaj, N., . K. R. (2016). Decoding Algorithm for color QR code :A
Mobile Scanner Application. Fifth International Conference on Recent Trends in Informa-
tion Technology. ieeexplore.
[Bianco, 2014] Bianco, Z. (2014). Speedy checkout wins retail technology of the year. retail-
customerexperience.
[Bickers, 2009] Bickers, J. (2009). Self-Checkout.
[BRM, ] BRM. Le taux de pénétration du mobile au cameroun est passé de 9,8 à 71%
entre 2004 et 2014. https ://www.investiraucameroun.com/telecom/1512-5922-le-taux-de-
penetration-du-mobile-au-cameroun-est-passe-de-9-8-a-71-entre-2004-et-2014. Vue le 10-
08-2022.
[Carluer-Lossouarn, 2006] Carluer-Lossouarn (2006). L’Aventure des premiers super-

marchés. Linéaires.
[Christopher, 2009] Christopher, A. (2009). Do-It-Yourself ’ : Self-Checkouts,Supermarkets,

And The Selfservice.
[Guyot, 2018] Guyot, M. (2018). Méthode agile vs méthode classique, quelle est la meilleure
façon de gérer son projet ? https ://www.marine-guyot.ovh/methode-agile-ou-classique/.
Vue 11-07-2022.
[Inman, 2014] Inman, J. J., F. R. . W. (2014). Where the rubber meets the road : A model
of in-store consumer decision-making. cba edu.
[Kasavana, 2017] Kasavana (2017). How amazon go is reinventing retail and its possible. re-
trieved from kioskmarketplace. https ://www.kioskmarketplace.com/blogs/how-amazon-
go-is-reinventing-retail-andits-possible-impact-on-micro-market-kiosks/. Vue 11-07-2022.
108
[Kirthi Kalyanam, 2009] Kirthi Kalyanam, R. L. . G. W. (2009). Retailing in the 21st Cen-
tury.
[Musalem, 2013] Musalem, Y. L. . A. (2013). Measuring the Effect of Queues on Customer

Purchases.
[Poushter, 2016] Poushter, J. (2016). Smartphone Ownership and Internet Usage Continues
to Climb in Emerging Economies. Pew Research Center.
[Rachuri, 2010] Rachuri, M. (2010). EmotionSense : a mobile phones based adaptive platform
for experimental social psychology research.
[Shintaro Okazaki, 2009] Shintaro Okazaki, M. H. (2009). Effects of displace-

ment–reinforcement between traditional media, pc internet and mobile internet. Inter-
national Journal of Advertising.
[SO, 2010] SO, L. C. (2010). QR Codes in Education. Journal of Education Technology

Development and Exchange. sicet.
[Solomon, 2007] Solomon, Bamossy, . A. (June 2007). Consumer Behavior : A European

perspective, 3rd Edition. SAGE.
[Stephan Karpischek, 2009] Stephan Karpischek, Florian Michahelles, F. R. E. F. (2009).

Mobile sales assistant-an nfc-based product information system for retailers. IEEE.
[Tomazelli, 2016] Tomazelli (2016). The effects of store environment elements on customer-
tocustomer interactions involving older shoppers.
[Tycho, 2008] Tycho, H. (2008). A Hybrid Checkout System.
[Wave, 2014] Wave (2014). QR code. Retrieved from qrcode.
[Zhang, 2014] Zhang, R. . X. (2014). Secure barcode-based visible light communication for
smartphones. ieeexplore.

Table des matières
Dédicace i
Remerciements ii
Avant Propos iii
Résumé v
Abstract vi
Sommaire vii
LISTE DES SIGLES ET ABREVIATIONS ix
Liste des figures x
Liste des tableaux xii
Introduction Générale 1
1 Etat de l’art 3
1.1 Supermarché . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Comment est née le premier supermarché ? . . . . . . . . . . . . . . . 4
1.1.3 Parcours d’achat du client . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Etude des systèmes de caisse actuels . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Caisse automatique et caisse conventionnelle . . . . . . . . . . . . . . 5
1.2.2 Le processus de prise décision d’achat . . . . . . . . . . . . . . . . . . 11
1.3 Théorie des files d’attente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
110
1.5 Technologie de self Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.5.1 Technologies de scannage basées sur les téléphones mobiles . . . . . . 16
1.6 Étude de l’existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.6.1 SMART MARKET . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.6.2 BarCroid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.6.3 Amazon Go . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.6.4 Mon Magasin U . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.6.5 Limites de ces solutions conte tenue du contexte camerounais . . . . . 29
1.6.6 Positionnement de la solution envisagé . . . . . . . . . . . . . . . . . 29
2 MATERIELS ET METHODES 33
2.1 Cahier de charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.1.2 Énoncer du problème . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.1.3 Objectifs de la recherche . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.1.4 Questions de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.1.5 Justification de recherche . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.1.6 Analyse swot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.1.7 Cadrage du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.2 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.2.1 Méthode classique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.2.2 Méthode agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.2.3 Comparaison des Méthodes classiques face aux Méthodes Agiles . . . 61
2.2.4 Présentation de la méthodologie adoptée : Agile Scrum . . . . . . . . 63
2.2.5 Présentation de la méthodologie adoptée : Agile Scrum . . . . . . . . 64
2.3 Étude Conceptuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.3.1 Présentation du langage UML . . . . . . . . . . . . . . . . . . . . . . 69
2.3.2 Intérêt de concevoir avec UML . . . . . . . . . . . . . . . . . . . . . . 69
2.3.3 Les types de digrammes UML . . . . . . . . . . . . . . . . . . . . . . 70
2.3.4 Concept générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3 IMPLÉMENTATION ET RÉSULTATS 92
3.1 Plateforme de développement mobile . . . . . . . . . . . . . . . . . . . . . . 92
3.1.1 Présentation des plateformes de développement . . . . . . . . . . . . 92
3.1.2 Limites de ces plateformes de développement . . . . . . . . . . . . . . 94
3.1.3 Plateforme de développement choisie . . . . . . . . . . . . . . . . . . 95
3.2 Outils, technologies et résultats obtenus . . . . . . . . . . . . . . . . . . . . . 97
3.2.1 Outils, technologies et langages de développement . . . . . . . . . . . 97
3.2.2 Résultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.2.3 Interprétations et discussion des résultats . . . . . . . . . . . . . . . . 104
Références Bibliographiques 108
Table des matières 110

OPTIMISATION DU TEMPS DE COURSE DANS UN SUPERMARCHE Avec Une Solution de SELF SCANNING

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

OPTIMISATION DU TEMPS DE COURSE DANS UN SUPERMARCHE Avec Une Solution de SELF SCANNING

Transféré par

Droits d'auteur :

Formats disponibles

Dédicace

L’accomplissement de ce travail a pu être possible grâce au soutien de plusieurs per-

— Dr. AZEUFACK Ulrich, pour sa supervision et ses conseils ;

— M. KAZE Roger, pour son encadrement et ses conseils ;

— M. NWOKAM Verlaine, Directeur de 3IAC pour son encadrement et ses démarches

— Mme NOUBANKA Manuella, Ancienne Directrice de 3IAC pour sa généreuse collabo-

— Mes amis et camarades pour leur soutien.

Ce mémoire rentre dans le cadre de l’obtention du diplôme d’ingénieur de conception

— Aux différentes catégories de clients de réduire considérablement leur temps d’achat,

— De transférer si besoin sa facture à un compte distant pour effectuer une vérification

— De réduire le risque de contamination face à la pandémie COVID-19 qui refait son

Rédigé par NDANGA Jules iv

Mots-clefs : Code barre, Android, préfacturation, file d’attente,optimisation, supermaché,

Keywords : Barcode, Android, pre-billing, queue, optimization, supermarket,self scan-

Avant Propos iii

LISTE DES SIGLES ET ABREVIATIONS ix

Liste des figures x

Liste des tableaux xii

2.2 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . . . 55

Références Bibliographiques 108

Table des matières 110

Rédigé par NDANGA Jules viii

— API : Programmable Logic Controller

— CUP : Code produit universel

— HTTPS : Hyper Text Transfer Protocol Secure

— ISSN : Numéro de série international normalisé

— ISO : Organisation internationale de normalisation

— IDE : Environnement de développement intégré

— PDA : Assistance numérique personnelle

— POO : Programmation orienté Object

— QR Code : Code de réponse rapide

— RFID : Identification radiofréquence

— SSL : Secure Socket Layer

— TLS : Transport Layer Security

1.1 Le grand Bao Douala montée collège Saint-Michel Près de Chococam . . . . 4

2.10 Formule détermination nombres moyens de personnes pour le projet . . . . . 54

3.1 Comparaison plateforme Native, Cross plateforme et hybride . . . . . . . . . 95

Rédigé par NDANGA Jules xi

1.1 Comparaison Code Barre et QR-Code . . . . . . . . . . . . . . . . . . . . . . 19

2.1 Chronométrage du temps moyen de passage et du panier des clients . . . . . 39

3.1 Outils de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

L’objectif général ici est de réduire ou de supprimer le temps d’attente du client à la

Comme objectif spécifique nous avons entre autres :

— Permettre de faire les courses plus facilement et donc plus rapidement.

— Permettre à partir de l’application de s’orienter plus facilement à travers le supermarché

— Permettre de dénicher plus facilement des bonnes affaires et promotions.

— Réduire le temps d’attente à la caisse.

— Permettre aux personnes âgées d’effectuer facilement les courses.

 Pour les supermarchés :

— Donner une image moderne et innovante de leur enseigne

— Mettre en avant leurs promotions et vendre plus

— Économiser de l’espace et de l’argent

— Fidéliser les clients

— Faciliter le travail au niveau des caisses

 Pour l’entreprise Inet Consulting :

— Faire connaı̂tre l’entreprise

— Agrandir son portefeuille client

Rédigé par NDANGA Jules 2

1.1.2 Comment est née le premier supermarché ?

1.1.3 Parcours d’achat du client

Rédigé par NDANGA Jules 4

1.2 Etude des systèmes de caisse actuels

1.2.1 Caisse automatique et caisse conventionnelle

Pour les supermarchés :

Pour l’entreprise Inet Consulting :

Fonctionnement des QR-codes : Le QR code peut paraı̂tre assez complexe à com-

Application du code-barres dans les supermarchés : Selon Kuha et Chintho

Fonctionnement des codes-barres : C’est à ses esthétiques zébrures que le code-