République Tunisienne

Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique

Université de Tunis El Manar

Faculté des Sciences de Tunis

Département des Sciences de l’informatique

RAPPORT DE PROJET DE FIN D ETUDES

Présenté en vue de l’obtention du

Diplôme National de licence en Ingénierie des

systèmes Informatique

Par Ayari Ibtihel

Mise en place d’une solution

de gestion des picklists

Organisme d’accueil : Sagemcom

Encadré par : Mme. Younes Sana

Supervisé par : Mr. Choura Morched

Année Universitaire : 2021-2022

 FICHE DE SYNTHÈSE

Dans le cadre de la gestion informatisée des stages de PFE et de l’archivage

des rapports de PFE, nous vous demandons de renseigner les items suivants :

- Formation : LCE3

- Session (Principale / Juillet / Septembre) : Principale

- Auteur(s) (Nom, prénom) : Ayari Ibtihel

- Titre du rapport : Conception et développement d’une application de gestion

des picklists

- Organisme d’accueil : Sagemcom Tunisie

- Pays d’accueil : La Tunisie

- Responsable de stage (nom et prénom) : Mr Messaoudi Mohamed Marouene

- Email du Responsable de stage :mohamed-marwene.massaoudi@sagemcom.com

- Tél. du Responsable de stage : 50 544 331

- Mots-clés caractérisant votre rapport (4 à 5 mots maximum) : Agile scrum,

Picklist, US.

1
 CHARTE DE NON PLAGIAT
PROTECTION DE LA PROPRIÉTÉ
INTELLECTUELLE

Tout travail universitaire doit être réalisé dans le respect intégral de la pro-
priété intellectuelle d’autrui. Pour tout travail personnel, ou collectif, pour
lequel le candidat est autorisé à utiliser des documents (textes, images, mu-
siques, films etc.), celui-ci devra très précisément signaler le crédit (référence
complète du texte cité, de l’image ou de la bande-son utilisés, sources internet
incluses) à la fois dans le corps du texte et dans la bibliographie. Il est pré-
cisé que l’UCO dispose d’un logiciel anti-plagiat, aussi est-il demandé à tout
étudiant de remettre à ses enseignants un double de ses travaux lourds sur
support informatique.

Je soussigné(e), Ayari Ibtihel étudiant(e) en Licence en Ingénierie des sys-

tèmes Informatique m’engage à respecter cette charte.

Fait à Tunis, le 06/06/2022

- Pays d’accueil : La Tunisie

Signature :

2
 DÉDICACES

A mon cher père, aucun mot ne peut exprimer le sentiment que j’éprouve à
ton égard. C’est grâce à ton amour, ta patience, tes sacrifices et tes encourage-
ments tout au long de mon parcours que j’ai pu être là où je suis maintenant.
J’espère avoir été digne de ton affection et ta confiance.

À ma chère mère, la lanterne qui éclaire mon chemin et m’illumine de douceur

et d’amour, les mots me manquent pour exprimer toute la reconnaissance, la
fierté et le profond amour que je te porte pour les sacrifices que tu as consenti
à faire pour ma réussite.

A ma chère sœur et mes chers frères, pour leur soutien durant toutes ces
années. Je vous dédie ce travail en vous souhaitant un avenir radieux, plein
de bonheur et de succès.

A tous les membres de ma grande famille, petits et grands, pour votre soutien
tout au long de mon processus académique et pour tous vos encouragements
et sens de fierté.

À tous mes meilleurs amis, pour les moments précieux que nous avons partagé
durant toutes ses années, pour leur aide, leur patience et leur générosité.

A tous ceux qui me sont chers, de tout l’encouragement qu’ils ont consenti
pour me permettre de suivre mes études dans les meilleures conditions.

i
 REMERCIEMENTS

C’est avec un grand plaisir que je réserve cette page, en signe de gratitude et
profonde reconnaissance à tous ceux qui m’ont aidé à aboutir ce projet de fin
d’études.

Je remercie tout d’abord Dieu tout puissant de m’avoir donnée l’ardeur, l’éner-
gie et la patience d’achever ce modeste travail.

Je voudrais bien exprimer mes plus vifs remerciements et mon grand respect
à toutes les personnes qui, de près ou de loin, ont bien voulu m’apporter
l’assistance nécessaire au bon déroulement de ce travail.

Je tiens à exprimer ma gratitude à les membres de jury pour l’honneur qu’elle

m’a fait d’accepter de juger mon travail .

J’adresse mes plus vifs remerciements à Madame Sana Younes, mon enca-
drante pédagogique pour le temps consacré aux réunions qui ont permis
d’orienter mon travail d’une manière pertinente. Je la remercie aussi pour
sa disponibilité pour encadrer ce projet à travers ses critiques et ses proposi-
tions d’amélioration.

L’expression de ma profonde gratitude est adressée à Monsieur Morched

Choura avec qui j’ai eu l’honneur et le privilège de travailler, et j’ai fait profiter
de son assistance, son encadrement et son expérience professionnelle.

ii
Et enfin, mes remerciements vont à tous mes enseignants et mes professeurs
qui n’ont pas cessé de m’encourager et d’enrichir mes connaissances durant
mon cursus académique.

iii
 TABLE DES MATIÈRES

Introduction Générale 1

1 ÉTUDE PRÉLIMINAIRE 3
1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Services de Sagemcom . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Valeurs de Sagemcom . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1 Différence entre la méthodologie classique et la méthodologie agile 8
1.4.2 Méthodes agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.3 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Formalisme utilisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 ANALYSE ET SPÉCIFICATIONS DES BESOINS 12

2.1 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 14

iv
TABLE DES MATIÈRES TABLE DES MATIÈRES

2.2 Pilotage du projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.1 Identifications de l’equipe de SCRUM . . . . . . . . . . . . . . . . . 15
2.2.2 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Diagramme de Gantt du projet . . . . . . . . . . . . . . . . . . . . 17
2.2.4 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Diagrammes de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . 19
2.4 Diagramme de classes global . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.1 Environnement Matériels . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.2 Environnement logiciel et développements . . . . . . . . . . . . . 21
2.6 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6.1 Architecture physique de l’application . . . . . . . . . . . . . . . . . 24
2.6.2 Architecture logique de l’application . . . . . . . . . . . . . . . . . 25

3 SPRINT 1 « MISE EN PLACE D’UNE APPLICATION MOBILE » 27

3.1 Objectif du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.1 Diagramme de cas d’utilisation« Mise en place d’une application
mobile» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.2 Description de cas d’utilisation« Mise en place d’une application
mobile» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 Conception du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.1 Diagramme de classe détaillé . . . . . . . . . . . . . . . . . . . . . . 30
3.4.2 Diagrammes de séquences détaillées . . . . . . . . . . . . . . . . . . 31
3.5 Implementation du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6 Test relatif au sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6.1 Test des services web . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6.2 Test de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4 SPRINT 2 « MISE EN PLACE D’UNE APPLICATION WEB » 45

4.1 Objectif du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

v
TABLE DES MATIÈRES TABLE DES MATIÈRES

4.3 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.3.1 Diagramme de cas d’utilisation« Mise en place d’une application
web » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.2 Description de cas d’utilisation« Mise en place d’une application
web » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4 Conception du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4.1 Diagramme de classe détaillé . . . . . . . . . . . . . . . . . . . . . 49
4.4.2 Diagrammes de séquences détaillés . . . . . . . . . . . . . . . . . . 49
4.5 Implémentation du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.6 Test relatif au sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.6.1 Test des services web . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.6.2 Test de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Conclusion Générale 69

Netographie 71

vi
 TABLE DES FIGURES

1.1 « Logo Sagemcom » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 « Processus de Scrum» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 « Scrum» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 « Diagramme de Gantt» . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 « Planification des sprints» . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 «Diagramme de cas d’utilisation global» . . . . . . . . . . . . . . . . . . . 19
2.4 « Diagramme de classes global» . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5 « Visual Studio Code» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6 « Microsoft Visual Studio» . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7 «SQL Server» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8 « Android Studio» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9 « Angular» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.10 « Bootstrap» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.11 « Java» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.12 « Architecture physique de l’application» . . . . . . . . . . . . . . . . . . . 25
2.13 « Architecture logique MVC » . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1 « Diagramme de cas d’utilisation «Sprint 1» . . . . . . . . . . . . . . . . . 29

3.2 « Diagramme de classes du sprint 1» . . . . . . . . . . . . . . . . . . . . . 30
3.3 «Diagramme de séquences « Authentification d’employé» . . . . . . . . . . 31
3.4 « Diagramme de séquences « Scanner un produit » . . . . . . . . . . . . . 32

vii
TABLE DES FIGURES TABLE DES FIGURES

3.5 « Interface authentification « Employé » . . . . . . . . . . . . . . . . . . . 33

3.6 « Interface de barre latérale de navigation» . . . . . . . . . . . . . . . . . . 34
3.7 « Interface des picklists » . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.8 « Interface de recherche des picklists » . . . . . . . . . . . . . . . . . . . . 36
3.9 « Interface des us» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.10 « Interface de scan de code» . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.11 « Interface de scan des us» . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.12 « Test des services web : Authentification d’employé » . . . . . . . . . . . . 40
3.13 « Test des services web : Consultation des picklists » . . . . . . . . . . . . 41
3.14 « Test des services web : la consultation des us» . . . . . . . . . . . . . . . 42
3.15 « Test des services web : Changement du statut» . . . . . . . . . . . . . . 43

4.1 Diagramme de cas d’utilisation« Sprint 2» . . . . . . . . . . . . . . . . . . 47

4.2 « Diagramme de classes du Sprint 2» . . . . . . . . . . . . . . . . . . . . . 49
4.3 « Diagramme de séquences « Authentification d’administrateur » . . . . . 50
4.4 « Diagramme de séquences « Ajouter un employé » . . . . . . . . . . . . . 51
4.5 « Diagramme de séquences « Supprimer un employé » . . . . . . . . . . . . 52
4.6 « Diagramme de séquences « Ajouter une picklist » . . . . . . . . . . . . . 53
4.7 « Diagramme de séquences «Supprimer une picklist» . . . . . . . . . . . . 54
4.8 « Interface d’authentification d’administrateur » . . . . . . . . . . . . . . . 55
4.9 « Interface de dashboard » . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.10 « Interface de gestion des employés » . . . . . . . . . . . . . . . . . . . . . 57
4.11 « Interface d’ajout d’employé » . . . . . . . . . . . . . . . . . . . . . . . . 58
4.12 « Interface de suppression d’un employé » . . . . . . . . . . . . . . . . . . 59
4.13 « Interface des Picklists » . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.14 « Interface d’ajout d’une Picklist » . . . . . . . . . . . . . . . . . . . . . . 61
4.15 « Interface de suppression d’une Picklist » . . . . . . . . . . . . . . . . . . 62
4.16 « Test des services web : Authentification d’administrateur» . . . . . . . . 63
4.17 « Test des services web : Ajout d’un employé » . . . . . . . . . . . . . . . . 64
4.18 « Test des services web : Suppression d’un employé » . . . . . . . . . . . . 65
4.19 « Test des services web : Ajout d’une picklist » . . . . . . . . . . . . . . . 66
4.20 « Test des services web : Suppression d’une picklist » . . . . . . . . . . . . 67

viii
 LISTE DES TABLEAUX

2.1 Equipe Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Description de cas d’utilisation du sprint 1 . . . . . . . . . . . . . . . . . . 29

4.1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2 Description de cas d’utilisation du sprint 2 . . . . . . . . . . . . . . . . . . 48

ix
 INTRODUCTION GÉNÉRALE

Dans un environnement industriel caractérisé par une concurrence féroce, l’entreprise

estime plus que jamais nécessaire de répondre aux exigences de productivité, de qualité,
de coûts et de délais. Pour maintenir cet équilibre, elle cherche à éliminer les préjugés qui
existent dans son système de travail en s’appuyant sur le principe que tous les problèmes
partent du principe des opportunités d’amélioration.
La picklist (liste de picking) est utilisée en entrepôt pour organiser l’ordre de prélèvement
des produits.
Le picking est l’opération consistant à prélever et rassembler plusieurs articles dans les
stocks d’une entreprise avant leur expédition. L’accroissement de la pression concurren-
tielle a conduit les entreprises à augmenter leur productivité et à réduire leurs délais de
livraison. Dans ce contexte, le picking devient un enjeu central pour la performance de
l’entreprise.
En effet,la préparation des picklists est une étape parfois complexe lorsqu’une quantité
importante de produits de différentes natures doivent être expédiés simultanément. Toute
la gestion du picking logistique dépend de la qualité des processus de l’entreprise. S’ils
sont efficients, il est possible de rationaliser au maximum la chaîne logistique et de réaliser
des gains de performance significatifs.
D’autre terme, l’entreprise peut espérer un réel gain de productivité, une amélioration de
la qualité du service et de son image.
C’est dans ce cadre que s’inscrit notre projet de fin d’étude effectué au sein de l’entreprise
SAGEMCOM. Ce projet consiste à mettre en place une solution qui permet à l’employé le

1
suivi, la préparation des picklists et le scan des produits en changeant leur statut à l’aide
d’une application mobile. Et à travers une application web, l’administrateur peut faire la
gestion des picklistes ainsi que des employés.
La synthèse des travaux réalisés tout au long du projet de fin d’études feront l’objet de
ce rapport qui s’articule autour de quatre chapitres.
Le premier chapitre « Etude de l’art » présentera le contexte général du projet, l’étude
de l’existant ainsi que les critiques qui vont à son encontre et les outils choisis.
Le second chapitre, intitulé « Analyse et Spécification des besoins », porte sur la
planification et la spécification des besoins de notre projet ainsi que la description de
l’architecture de l’application.
Le troisième chapitre, intitulé «Mise en place d’une application mobile » comporte le
1er sprint qui est la première partie dans l’application du cadre méthodologique SCRUM.
Le quatrième chapitre, intitulé «Mise en place d’une application web » illustre le
deuxième sprint de notre projet.
Enfin une conclusion générale récapitulera tout le travail que nous avons réalisé et clô-
turera le projet tout en exposant les perspectives offertes après la réalisation de notre
solution.

2
 CHAPITRE 1

ÉTUDE PRÉLIMINAIRE

Introduction
Le premier chapitre met le travail dans son contexte général. En premier lieu, nous
présenterons la société dans laquelle nous avons effectué notre stage de fin d’études. Par
suite nous mettrons notre projet dans son cadre général, la troisième de présenter l’étude
de l’existant. Nous clôturons ce chapitre par l’explication du choix de la méthodologie.

1.1 Présentation de l’organisme d’accueil

Avec beaucoup de motivation, nous avons effectué notre stage au sein de la société
SAGEMCOM. Ce stage nous a permis non seulement d’approfondir nos connaissances
mais aussi d’enrichir et de développer nos aptitudes à la communication et à l’intégration
au sein de l’entreprise.
Sagemcom est un groupe français et un leader européen sur le marché des terminaux de
communication de haute qualité (décodeurs, box internet, compteurs électriques, etc.).
Sagemcom est présent sur trois marchés majeurs : le haut débit, les villes intelligentes
et l’Internet des objets (IOT). Grâce à ses usines et partenaires industriels sur tous les
continents, Sagemcom conçoit, fabrique et fournit chaque année plus de 40 millions de
terminaux dans le monde. [1]

3
 CHAPITRE 1. ÉTUDE PRÉLIMINAIRE

‘SAGEM TUNISIE COMMUNICATION’ est une filiale de sagem communication. Elle

est installée en Tunisie depuis 2013.cette dernière fabrique un large choix de produits et
systèmes dans les domaines de l’équipement électrique, des télécommunications, du trai-
tement numérique et de la transmission de l’information.[2]

Figure 1.1 – « Logo Sagemcom »

Sagemcom dispose des certifications suivantes :

• ISO 9001 : obtenue en 2015, assure un management de la qualité. [3]

• ISO 14001 : obtenue en 2015, s’occupe de la gestion environnementale des sites RD de

Rueil Malmaison (France) et Mégrine/Kram (Tunisie), ainsi que pour 86

• ISO 45001 : applique un management en faveur de la Santé et de la Sécurité des

employés en fabrication. [3]

• ISO 27001 : obtenue en juin 2014, elle garantit que son système de management concer-
nant la sécurité de l’information est fiable. [3]

• ISO 50001 : obtenue en 2011, pour le management de l’énergie dans les centres de
production tunisiens.[3]

1.1.1 Services de Sagemcom

Sagemcom, est en pleine croissance continue, elle développe et fabrique des solutions
innovantes répondant à trois besoins fondamentaux :

• Energytelecom : l’accès à l’énergie.

• Solutions Broadband : l’accès à internet.

• Solutions audio vidéo : l’accès aux contenus vidéo.

4
 CHAPITRE 1. ÉTUDE PRÉLIMINAIRE

1.1.2 Valeurs de Sagemcom

Préserver une position de leader sur un marché très dynamique est essentielle pour
Sagemcom. Pour y parvenir, elle reste fidèle à sa marque. En d’autres termes, elle est
parmi les premiers à fournir à ses clients des produits sur mesure intégrant les dernières
innovations.
— -Créativité : se différencier pour créer de la valeur.
— -Priorité client : Ses clients au cœur de ses actions.
— - Agilité : mobilisés pour le meilleur.
— - Performance : la performance comme quotidien.
— - Puissance de l’équipe : des talents engagés pour les projets les plus ambitieux.

1.2 Présentation du projet

Dans le cadre de l’obtention du diplôme « Licence en Ingénierie des systèmes Infor-
matique » de la Faculté des sciences de Tunis, nous avons effectué notre projet, intitulé
« Mise en place d’une solution de gestion des picklists » au sein de la société « Sagem-
com » durant une période de 4 mois. Dans lequel nous allons mettre en œuvre toutes les
connaissances acquises durant notre formation.

1.2.1 Etude de l’existant

La gestion des picklists avec un WMS

Sur le progiciel Easy WMS, les picklists sont disponibles dans le menu « Entrepôt », «
Tâches ». Ces fonctionnalités gèrent les tâches de réapprovisionnement ou d’approvision-
nement, de picking, de packing, ou de préparation de commandes avant l’expédition.
Ce logiciel est amplement personnalisable et qui permet d’ajuster les tâches liées au pi-
cking et la création des picklists.
Easy WMS enregistre tous les mouvements de stocks se produisant dans l’entrepôt et
l’emplacement des produits. Si besoin, vous pouvez opter pour un travail sans papier
grâce à des dispositifs de picking intégrés au WMS (exemples : le voice picking ou des
lecteurs RFID avec écrans)[4].

5
 CHAPITRE 1. ÉTUDE PRÉLIMINAIRE

1.2.2 Critique de l’existant

La critique est une étape nécessaire pour porter des jugements objectifs afin de décou-
vrir les lacunes rencontrées dans la recherche de solutions existantes. Au vu de la situation
que nous avons vue, les solutions ci-dessus se sont avérées efficaces, mais il existe égale-
ment certaines lacunes, qui se manifestent par leur complexité et leur rigidité liées à la
lourdeur de mise en œuvre et d’exploitation et liée à l’entreprise. Les sociétés se trouvent
confrontées à des problèmes liés aux coûts, aux ajustements nécessaires et à l’intégration
entre différentes applications informatiques.

1.2.3 Problématique

Dans l’objectif de maîtriser la chaîne d’approvisionnement du début à la fin, Sagem-

com cherche à implémenter un système qui permet aux différents utilisateurs logistique
de gérer les picklists au niveau du magasin.
La mise en œuvre d’une application de gestion des picklistes en interne offre plusieurs
avantages à savoir :
• Réaliser un gain du productivité grâce à une base de données unique (pas de duplication
de données ou d’écart de valeurs, des données fraîches et actualisées, etc.).
• Profiter d’une visibilité complète sur l’état de stock au niveau du magasin.
• Réduire les coûts en améliorant le contrôle sur les produits.
• Une circulation fluide de l’information.
Tous ces avantages permettent clairement à sagemcom de progresser leur productivité,
leurs performances et, par extension, leur rentabilité. Toutes ces mesures ne sont pas
disponibles dans la société dont la gestion se base sur l’utilisation des méthodes tradition-
nelles. En effet, il n’existe actuellement aucun système utilisé par l’équipe logistique pour
gérer les picklists. Par conséquent, nous ressentons les limites suivantes :
• Manque de la gestion des picklistes.
• Manque de suivi des produits.

6
 CHAPITRE 1. ÉTUDE PRÉLIMINAIRE

1.3 Solution proposée

Pour améliorer la gestion des picklists au sein de Sagemcom, nous proposons une
application mobile qui permet à l’employée le suivi et la préparation des listes des produits
demandés et une application web permettant à l’administrateur la gestion des employées et
des picklists ainsi que la visualisation et le suivi de l’évolution du picking avec l’élaboration
d’un Dashboard. Cette solution assurera :
• La gestion optimal des produits.
• Génération d’un tableau de bord.
• Abaissement des pertes de données.
Le projet doit répondre aux besoins de l’entreprise et atteindre les objectifs suivants :
L’application android permet :
-L’affichage de l’ensemble des picklists (list des US demandés) dans l’écran d’ac-
cueil.
-En cliquant sur la picklist, une list des US s’affiche et attente le scan.
-Chaque us scanné sera coloré en vert et aura un statut « servi ».
L’application web permet :
-La gestion des employées.
-La gestion des picklistes.
-Elaboration d’un dashboard pour afficher tous les informations sur les produits.

1.4 Méthodologie de développement

Choisir la bonne approche pour exécuter un projet est une étape importante dans
la détermination du succès du projet. En effet, il n’y a pas d’approche standard pour
assurer la bonne exécution de chaque tâche, mais celle-ci doit être adoptée en fonction de
la fonction de chaque projet, notamment des objectifs à atteindre. Par conséquent, une
enquête minutieuse et détaillée doit être effectuée en premier.

7
 CHAPITRE 1. ÉTUDE PRÉLIMINAIRE

1.4.1 Différence entre la méthodologie classique et la méthodo-

logie agile

Pour gérer un projet, il existe deux approches très différentes : méthodologie classique
et méthodologie agile. Concernant la méthodologie classique, le projet se conçoit de ma-
nière non-itérative. Le client commence par livrer son cahier des charges en détaillant
chacun de ses besoins. Une fois que les contours de la mission sont correctement définis,
la mission peut être lancée. À l’autre extrémité, nous retrouvons la méthode agile. Ici,
le processus est radicalement différent puisqu’entièrement itératif. Le projet se construit
par palier, en constante concertation avec le client. On évite ainsi d’innombrables allers-
retours. Mais si les méthodes agiles sont idéales pour optimiser la gestion de projet, elles
impliquent la présence et la réactivité du client.

1.4.2 Méthodes agiles

La méthodologie agile est bien différente des méthodes traditionnelles telle que le cycle
en V ou Waterfall qui prévoit les planifications totales du projet avant même le développe-
ment. Elle se veut plus souple et adaptée, et préconise plutôt la fixation d’objectif à court
terme. C’est un mode de gestion qui place le client au cœur de l’action, cela permettra
à l’équipe de développement d’avoir des feedbacks réguliers afin d’appliquer directement
les changements nécessaires[5].

1.4.3 Scrum

La méthode scrum ou plus exactement le cadre méthodologique scrum est de loin la

méthode Agile la plus utilisée dans le monde. Elle bénéficie aujourd’hui de nombreux
retours d’expérience. Les formations, blogs, conférences, communautés, outils et ouvrage
à son sujet ne manques pas [6].
La figure 1.2 présente le processus de scrum.

8
 CHAPITRE 1. ÉTUDE PRÉLIMINAIRE

Figure 1.2 – « Processus de Scrum»

La méthodologie scrum est donc un cadre de travail permettant la gestion du développe-

ment d’application complexe. Le principe de cette méthode est de développer un logiciel
de manière incrémentale en maintenant une liste totalement transparente des demandes
dévolution ou de corrections à implémenter « backlog ». Avec des livraisons très fréquentes,
toutes les quatre semaines en général. Pour cela, la méthode s’appuie sur des développe-
ments itératifs « sprints » à un rythme comptant d’une durée de 2 à 4 semaine. Le sprint
englobe les activités d’analyse, de conception, de test et de développement. Au cours de
ce dernier l’équipe de développement soulève des question métiers.

Figure 1.3 – « Scrum»

Cette méthode nécessite quatre types de réunions :

— - Les réunions quotidiennes : chaque jour toute l’équipe se réunit, pendant 15 minutes
environ pour répondre aux trois questions suivantes : qu’est-ce que je fais hier ?

9
 CHAPITRE 1. ÉTUDE PRÉLIMINAIRE

- Qu’est-ce que je vais faire aujourd’hui ? Est ce qu’il y a un obstacle aujourd’hui ?

- Les réunions de planification : toutes l’équipe se réunie pour décider des fonctionnalités
qui vont composer le sprint suivant et mettre à jour la liste générale.

- Les réunions de revue de travail : lors de cette réunion chacun présente ce qu’il a fait
pendant la durée de sprint. Il s’agit d’une réunion informelle de deux heures environ à
laquelle participe toute l’équipe.

- Les réunions rétrospectives : à chaque fin de sprint, l’équipe fait le point sur ce qui a
bien fonctionné et sur ce qui a moins bien fonctionné. Lors de cette réunion d’une durée
de 15 minutes a une demie heure où chacun est invité et parle en son nom, un vote de
confiance est organisé pour décider des améliorations à apporter.

1.5 Formalisme utilisé

Langage de modélisation (UML) La phase de modélisation nécessite des méthodes
permettant de mettre en place un modèle d’analyse. Dans ce contexte-là, nous adoptons
le langage UML ”Unified Modeling Language”, qui est un langage de modélisation des
données et des traitements [7].
En effet, ce langage fournit un moyen astucieux permettant de représenter diverses pro-
jections d’une même représentation grâce à ces différents diagrammes en utilisant des
éléments et en formant des associations entre ceux-ci, ces projections représentent le sys-
tème d’un point de vue statique qui capture les composants de sa structure ou dynamique
qui capture son comportement. Et dans ce contexte, nous présentons quelques diagrammes
que nous avons jugés utiles et suffisants pour comprendre le projet à savoir les diagrammes
des cas d’utilisation, les diagrammes de classes et les diagrammes de séquences :

- Le diagramme de cas d’utilisation permet l’énumération des fonctions de l’application

du point de vue de l’utilisateur.

- Le diagramme de classes permet une représentation statique du système étudié, en

représentant les classes et les relations entre eux.

- Le diagramme de séquences permet une représentation temporelle et comportementale

des objets et de leurs interactions.

10
 CHAPITRE 1. ÉTUDE PRÉLIMINAIRE

Conclusion
Ce chapitre nous a permis d’évoquer le cadre général du projet. Tout d’abord, nous
avons présenté l’organisme d’accueil avec une présentation détaillée de ses différents ser-
vices et de ses valeurs. Puis, nous avons présenté la problématique ainsi que la solution
proposée. Ensuite nous avons fait une étude comparative sur les méthodologies du travail,
ce qui nous a mené scrum.
Dans le chapitre suivant intitulé « Analyse et spécification des besoins », nous pré-
senterons la phase initial de la conception de notre configurateur.

11
 CHAPITRE 2

ANALYSE ET SPÉCIFICATIONS DES

BESOINS

Introduction
Après avoir initialement présenté dans le premier chapitre le cadre du notre projet.
Dans ce chapitre nous allons identifier les acteurs ainsi que les besoins fonctionnels et non
fonctionnels .Puis nous allons présenter les diagrammes nécessaires pour la spécification
et l’analyse des besoins.

2.1 Spécification des besoins

Cette partie va servir à poser les bases du recueil des besoins du système à réaliser, nous
nous intéressons à identifier les besoins des utilisateurs dans notre application à travers
les spécifications fonctionnelles et non fonctionnelles pour aboutir à une application de
bonne qualité qui répond aux besoins des utilisateurs logistiques.

2.1.1 Identification des acteurs

Un acteur est l’abstraction d’un rôle joué par une entité externe, un processus (per-
sonne physique) ou tout un composant qui interagit avec un système. Dans notre outil

12
 CHAPITRE 2. ANALYSE ET SPÉCIFICATIONS DES BESOINS

informatique, il existe 2 acteurs :

Administrateur :
Gestion des picklits.
Gestion des employés.
Il a l’access aux informations sur les produits.
Employé :
Il est responsable de la consultation des picklists ainsi que le scan des us afin de changer
leur statut.

2.1.2 Besoins fonctionnels

Les besoins fonctionnels ou besoins métiers représentent les actions que le système doit
exécuter. Le système ne devient opérationnel que s’il satisfait les besoins fonctionnels.
Sagemcom a besoin de développer un portail pour la bonne gestion des picklists au sein
du magasin. Pour répondre aux besoins des utilisateurs, notre solution devrait permettre
de :

• S’authentifier : En faisant la saisie de son identifiant et son mot de passe correctement.

• Consulter les picklists : affichage des informations relatives à l’article (emplacement/

article /us /quantité).

• Consulter les US : affichage l’emplacement dans le magasin, date du mouvement de

l’article relative à cette us.

• Consulter les détails des picklists : Affichage du détail de la picklist.

• Gestion des picklists.

• Gestion des employés.

• Vérification des picklists.

• Scanner des produits.

• Déconnexion de l’application.

13
 CHAPITRE 2. ANALYSE ET SPÉCIFICATIONS DES BESOINS

2.1.3 Besoins non fonctionnels

Les besoins non fonctionnels sont les besoins qui caractérisent le système. Ce sont des
besoins qui ont un aspect visible pour l’utilisateur, mais qui ne sont pas reliées directement
au comportement du système. Les besoins non fonctionnels de notre système se décrivent
comme suit :
• Ergonomie de l’interface : l’interface de notre application doit être ergonomique et
conviviale. Aussi, elle doit être cohérente, homogènes et facile à manipuler par tous les
acteurs de système pour la simplicité d’utilisation tout en garantissant le confort visuel.
• La gestion des erreurs : La plateforme doit gérer au mieux ses exceptions par l’apparition
d’une erreur qui permettra de filtrer les données et de ne prendre en considération que les
données qui correspondent aux types adéquats et qui permettra de contrôler les champs
de saisie. Les erreurs possibles sont :

-L’identifiant ou mot de passe incorrect.

-Vérification si un utilisateur possède déjà un compte.

• Les contraintes fonctionnelles
• Contraintes techniques
La détermination des contraintes techniques aboutit à la liste suivante :
-Originalité de l’interface : La plateforme doit être ergonomique, facile à manipuler et
comprendre.
-Portabilité du site : La plateforme doit être fiable et performante.
- Traitement optimise des demandes : Le traitement des demandes doit se faire au meilleur
moment. Il faut savoir gérer l’accès à la base de données en fonction de contraintes «
temporelles ».
-Confidentialité : L’accès à toutes les données stockées dans les comptes individuels doit
être limité au seul utilisateur identifié par un nom d’utilisateur et un mot de passe.
- Maintenabilité et mise à jour : le code source doit être lisible et compréhensible en
séparent la partie Front-End el la partie Back-End. L’application doit être facilement
extensible et permet d’intégrer d’autres fonctionnalités sans trop d’effort pour localiser et
corriger les anomalies pour s’adapter aux nouveaux besoins.

14
 CHAPITRE 2. ANALYSE ET SPÉCIFICATIONS DES BESOINS

2.2 Pilotage du projet avec Scrum

Lors de l’utilisation de la méthodologie agile Scrum, les réunions sont très importantes
pour l’avancement du projet. Le choix de la méthodologie agile de Scrum offre la possibilité
d’un développement rapide, ce qui permettra la réutilisation des fonctions séparément de
la plateforme. Cette démarche a évoqué la participation de plusieurs acteurs dans le cadre
de notre projet. Avant d’entrer dans le vif du sujet, il faut discuter de la planification et
de la structure du projet, qui est l’épine dorsale des méthodes agiles.[6]

2.2.1 Identifications de l’equipe de SCRUM

L’équipe scrum joue un rôle très important dans le choix de la meilleure manière
d’achever leur travail.
Dans cette section, nous présentons les différents acteurs impliqués dans l’avancement du
projet à différentes étapes et leurs rôles associés. Cette équipe comprend : Product Owner,
Scrum Master et équipe de développement. Dans notre projet, la distribution des rôles
aux différents participants est établie comme suit dans le tableau 2.1 :

Le Product Owner Le Scrum Master L’équipe de développement

Mr.Jassem Labiadh Mr.Morched Choura Ibtihel Ayari

Table 2.1 – Equipe Scrum

2.2.2 Backlog du produit

Cette partie sert à jeter les bases pour recueillir les besoins du système à mettre en
place. Nous sommes intéressés à identifier les besoins des utilisateurs d’applications à tra-
vers des spécifications fonctionnelles et non fonctionnelles afin de réaliser des applications
de haute qualité qui répondent aux besoins des utilisateurs logistiques. Nous expliquons
en détail la signification des différents termes utilisés dans le Product Backlog :
- Id : représente l’identifiant des user stories.
- Thème : Une première répartition du backlog pour faciliter le travail de priorisation des
Product Owners.
- La priorité : spécifie une valeur de priorité attribuée selon la valeur métier et l’ordre de
la réalisation. (Avec 1 : c’est la priorité la plus forte et 4 : la priorité la plus faible).

15
 CHAPITRE 2. ANALYSE ET SPÉCIFICATIONS DES BESOINS

- User Story (récit utilisateur en français) : représente le besoin fonctionnel du client ex-
primé selon ce format « En tant que. . .Je veux. . .Afin que . . . »
- Estimation : c’est une estimation de la complexité. Elle est une valeur entière.

ID THEME User Story PRIORITE ESTIMATION

1 Authentification En tant que administrateur, je 1 5

veux m’authentifier afin d’accéder
à l’application web.
En tant que employé, je veux
m’authentifier afin d’accéder à
l’application mobile.
2 Gestion des employés En tant qu’administrateur, je 2 4
peux ajouter ou supprimer des
employés.
3 Consultation des US En tant que employé, je veux 1 5
consulter des articles et des
US afin d’avoir des informations
concernant les codes des produits
et le statut .
En tant qu’employé, je veux cher-
cher un produit dans la barre de
recherche par son nom.
4 Consultation des Pi- En tant que employé, je veux 1 5
cklists consulter des Picklists afin d’avoir
des informations concernant les
codes des produits et le statut.
En tant qu’employé, je veux cher-
cher une picklist dans la barre de
recherche par son nom
5 Détails des Picklists En tant qu’administrateur, je 1 3
veux accéder aux détails des Pi-
cklists afin de consulter les article
et les US.
6 Détails des US En tant qu’administrateur, je 1 3
veux accéder aux détails des US.
7 Gestion des Picklists En tant qu’administrateur, En 1 4
tant qu’administrateur, je peux
ajouter ou supprimer des pick-
listes
8 Scanner les produits En tant qu’employé, je veux scan- 1 6
ner un produit demandé et chan-
ger son statut.

Table 2.2 – Backlog produit

16
 CHAPITRE 2. ANALYSE ET SPÉCIFICATIONS DES BESOINS

2.2.3 Diagramme de Gantt du projet

Il est évident d’utiliser le célèbre diagramme de Gantt, reconnu comme un outil efficace
de modélisation à long terme des tâches d’un projet, pour mesurer et suivre l’avancement
d’un projet pendant un stage de quatre mois. Par conséquent, ce tableau représente un
calendrier qui répertorie toutes les activités nécessaires pour mener à bien la mission à
des intervalles de temps. La figure 2.1 montre les différentes étapes de réalisation de notre
projet.

Figure 2.1 – « Diagramme de Gantt»

17
 CHAPITRE 2. ANALYSE ET SPÉCIFICATIONS DES BESOINS

2.2.4 Planification des sprints

La planification des sprints a été faite en se basant sur la priorité et la complexité

des taches. Dans la figure 2.2, nous illustrons le planning des différentes sprints de notre
système.
Le premier sprint présente la mise en place d’une application mobile.
Le deuxième sprint présente la mise en place d’une application web.

Figure 2.2 – « Planification des sprints»

18
 CHAPITRE 2. ANALYSE ET SPÉCIFICATIONS DES BESOINS

2.3 Diagrammes de cas d’utilisation global

Les diagrammes de cas d’utilisation illustrent et définissent le contexte et les exigences
d’un système entier, ou des parties essentielles d’un système. Ces diagrammes identifient
également les interactions entre le système et ses acteurs. Nous présentons dans la figure ci-
dessous notre diagramme de cas d’utilisation globale décrivant les grandes fonctionnalités
du déroulement de notre projet, mais ce diagramme général ne montre pas de façon
détaillée le dialogue entre les acteurs et les différents profils de chaque utilisateur. Dans
les chapitres qui suivent, nous détaillerons, avec raffinement itératif, les différents cas
d’utilisation et nous mettrons les différents acteurs par profile.
Nous allons dans la figure 2.3 présenter le diagramme des cas d’utilisation générale

Figure 2.3 – «Diagramme de cas d’utilisation global»

19
 CHAPITRE 2. ANALYSE ET SPÉCIFICATIONS DES BESOINS

2.4 Diagramme de classes global

Notre diagramme de classes se compose principalement de cinq classes. Parmi ces
classes nous trouvons :
- La classe “Administrateur” : Cette classe présente les utilisateurs qui accèdent à l’appli-
cation web.
- La classe “Employé” : Cette classe présente les utilisateurs qui accèdent à l’application
mobile.
- La classe “Picklist” : Cette classe montre la liste des produits demandés.
- La classe “US” : Cette classe montre l’ensemble des produits de chaque picklist.
La figure 2.4 illustre le diagramme de classes global.

Figure 2.4 – « Diagramme de classes global»

20
 CHAPITRE 2. ANALYSE ET SPÉCIFICATIONS DES BESOINS

2.5 Environnement de travail

Nous allons présenter dans cette section l’environnement de la réalisation de l’appli-
cation. Ainsi nous avons eu recours à des outils de développements, et les caractéristiques
de la machine sur laquelle nous avons travaillé.

2.5.1 Environnement Matériels

Notre application été développée sur un ordinateur LENOVO THINKPAD dont leurs
configurations sont présentées comme suit dans le tableau 2.3 :

Processeur Intel Core i7-10510U @ 4,9GHz

Mémoire Ram 8Go
Type de système Système d’exploitation 64 bits
Disque Dur 1 To
Systéme d’exploitation Windows 10

Table 2.3 – Environnement matériel

2.5.2 Environnement logiciel et développements

Dans cette partie, nous présentons l’environnement logiciel du projet, aussi les langages
de développement et de balisage utilisés pour développer l’application mobile et le site
web.

L’éditeur de code

Figure 2.5 – « Visual Studio Code»

Visual Studio Code est un éditeur de code extensible développé par Microsoft pour
Windows, Linux et macOS [8].

21
 CHAPITRE 2. ANALYSE ET SPÉCIFICATIONS DES BESOINS

Microsoft Visual Studio

Figure 2.6 – « Microsoft Visual Studio»

Microsoft Visual Studio est un ensemble complet d’outils de développement permettant

de générer des applications web ASP.NET, des services web XML, des applications bu-
reautiques et des applications mobiles [9].

Base de données

Figure 2.7 – «SQL Server»

SQL Server est un système de gestion de base de données (SGBD) développé et commer-
cialisé par Microsoft. Microsoft SQL Server fait désormais partie de la stratégie technique
de Microsoft en matière de base de données [10].

Emulateur : Android Studio

Figure 2.8 – « Android Studio»

Android Studio est un émulateur Android qui simule les appareils Android sur un
ordinateur afin de tester l’application sur une variété d’appareils et de niveaux d’API
Android sans avoir besoin de chaque appareil physique [11].

22
 CHAPITRE 2. ANALYSE ET SPÉCIFICATIONS DES BESOINS

Angular

Figure 2.9 – « Angular»

Angular est l’un des Framework JavaScript les plus avancés pour le web, crée par Google. Il
est résultat d’amélioration des versions d’Angular précédente, développé avec TypeScript.
Il offre des performances améliorées, une modularité amplifie, un respect des nouveaux
standards du web et un code plus expressif [12].

Bootstrap

Figure 2.10 – « Bootstrap»

C’est une collection d’outils de création de sites et d’applications web. Il contient

HTML et modèles de conception à base de Angular, des formes, des boutons, la navigation
et d’autres composants de l’interface, ainsi que des extensions optionnelles JavaScript [13].

Java

Figure 2.11 – « Java»

23
 CHAPITRE 2. ANALYSE ET SPÉCIFICATIONS DES BESOINS

Java est un langage de programmation orienté objet qui possède une gestion automatique
de la mémoire et peut-être utilisé pour faire du web. La version utilisée pour notre projet
est Java 17 [14].

C Sharp Le C Sharp est un langage de programmation orienté objet à typage fort,

créé par la société Microsoft. Il est utilisé pour développer des applications web, ainsi
que des applications de bureau, des services web, des commandes, des widgets ou des
bibliothèques de classes3. Il est destiné à développer sur la plateforme .NET [15].

ASP.NET Core MVC

ASP.NET Core MVC est un framework qui nous permet de générer des applications web
et des API à l’aide du modèle de conception Model-View-Controller[16].

Swagger UI
Swagger UI est un logiciel basé sur les technologies du web (HTML, JavaScript, CSS)
permettant de générer une documentation en utilisant les spécifications d’Open API. Il
fournit aussi un bac à sable permettant de tester les appels API directement depuis la
documentation générée [17].

Postman
Le logiciel Postman représente un outil permettant le test des services web. [18]

2.6 Architecture de l’application

2.6.1 Architecture physique de l’application

Notre application suit une architecture 3-tiers, dont les couches sont les suivantes :
La couche de présentation : liée à l’interface utilisateur. Elle permet d’afficher les
données et de laisser l’utilisateur final d’interagir avec ces derniers.
La couche métier : est en charge d’appliquer et respecter les algorithme métiers. Elle
correspond à la partie fonctionnelle de l’application, celle qui implémente la logique ap-
plicative et la sécurité.
La couche de données : correspond au serveur qui comprend les bases de données de
configuration, les bases de données de contenu et les bases de données liées au applications
de serveur[19].

24
 CHAPITRE 2. ANALYSE ET SPÉCIFICATIONS DES BESOINS

La figure 2.12 présente l’architecture physique de l’application.

Figure 2.12 – « Architecture physique de l’application»

2.6.2 Architecture logique de l’application

• Pattern MVC Le MVC (Modèle - Vue - Contrôleur) est un pattern architectural

qui sépare les données (le modèle), l’interface homme-machine (la vue) et la logique de
contrôle (le contrôleur). Ce modèle de conception force la séparation de ces trois parties
fondamentales. C’est un bon moyen de structurer votre code.[19]
• Modèle : c’est la section de gestion des données utilisées par le programme. Elle
permet la récupération des données à partir de la base de données et les organiser puis,
elles vont être traités par le contrôleur.
• Vue : La vue est un composant graphique de l’interface qui permet d’afficher les
données du modèle à l’utilisateur.
• Contrôleur : Il est le médiateur entre le modèle et la vue. Il est le responsable de
l’interprétation des événements générés par l’utilisateur.

25
 CHAPITRE 2. ANALYSE ET SPÉCIFICATIONS DES BESOINS

La figure 2.13 présente l’architecture logique MVC.

Figure 2.13 – « Architecture logique MVC »

Conclusion
Dans ce chapitre, nous avons présenté les besoins de notre projet, aussi bien fonction-
nels, le backlog du produit et la planification des sprints. Nous avons également élaboré le
diagramme de cas d’utilisation général ainsi que le diagramme de classe. À ce niveau, nous
pouvons passer au chapitre suivant qui comporteront la planification et l’architecture du
projet. Enfin, nous avons présenté l’architecture de notre application.
Dans le chapitre suivant, nous commencerons par le premier sprint qui couvrira la première
étape du développement d’application.

26
 CHAPITRE 3

SPRINT 1 « MISE EN PLACE D’UNE

APPLICATION MOBILE »

Introduction
Dans ce chapitre, nous allons traiter le premier sprint de notre projet, qui s’agit de
développer une application mobile. Nous allons suivre les « User stories » du sprint pour
réaliser un produit livrable pour cette première partie.
Chaque sprint passe par quatre étapes :
- Analyse des besoins
- La conception
- L’implémentation des interfaces
- Les tests

3.1 Objectif du sprint

L’objectif de cette partie est de construire une application mobile qui permet aux
employés de :
-Afficher l’ensemble des picklists (List des US demandés) dans l’écran d’accueil.
-En cliquant sur la picklist, une List des US s’affiche et attente le scan.
-Chaque us scanné sera coloré en vert et aura un statut « servi ».

27
 CHAPITRE 3. SPRINT 1 « MISE EN PLACE D’UNE APPLICATION MOBILE »

3.2 Backlog du sprint

Le sprint Backlog est un outil qui facilite la répartition des tâches et qui fait la mise
au point du travail tout en précisant les tâches que contient chaque user-story du Product
Backlog. Notre Backlog sprint se présente dans le tableau 3.1 :

Id User Story
1 En tant qu’employé, je veux
m’authentifier sur l’application
mobile.
2 En tant qu’employé, je veux
consulter la liste des produits de-
mandé et ses détails.
3 En tant qu’employé, je veux
consulter les us et ses détails.
4 En tant qu’employé, je veux cher-
cher la liste des produits de-
mandé afin d’avoir des informa-
tions concernant le code et le sta-
tut.
5 En tant qu’employé, je veux cher-
cher les produits afin d’avoir des
informations concernant le code
et le statut.
6 En tant qu’employé, je veux scan-
ner les produits afin de changer
leur statut.

Table 3.1 – Backlog du sprint 1

3.3 Analyse des besoins

Dans cette partie, nous commençons par un diagramme de cas d’utilisation du sprint
1 suivi d’une description textuelle de ses histoires utilisateur.

3.3.1 Diagramme de cas d’utilisation« Mise en place d’une ap-

plication mobile»

La figure 3.1 présente le diagramme de cas d’utilisation de ce sprint :

28
 CHAPITRE 3. SPRINT 1 « MISE EN PLACE D’UNE APPLICATION MOBILE »

Figure 3.1 – « Diagramme de cas d’utilisation «Sprint 1»

3.3.2 Description de cas d’utilisation« Mise en place d’une ap-

plication mobile»

En vue d’analyser le diagramme de cas d’utilisation de sprint 1, nous allons établir la

description qui l’enrichir dans le tableau 3.2.

Titre Sprint1
Acteur Employé
Prés condition Employé créer dans la base de données.
Description du scéna- L’employé remplit le formulaire de
rio connexion pour accéder à la page d’ac-
ceuil.
L’employé consulte la liste des produits
demandé et ses détails.
L’employé consulte les us et ses détails.
L’employé scanne les produits et
change leur statut.

Table 3.2 – Description de cas d’utilisation du sprint 1

3.4 Conception du Sprint 1

La deuxième étape dans un sprint est la conception qui a comme but de donner une
vision approfondie et claire sur les fonctionnalités de notre système. Dans cette section
alors nous présentons le diagramme de classe et les diagrammes de séquences du sprint1.

29
 CHAPITRE 3. SPRINT 1 « MISE EN PLACE D’UNE APPLICATION MOBILE »

3.4.1 Diagramme de classe détaillé

La figure 3.2 représente le diagramme de classes relatif au sprint 1 :

Figure 3.2 – « Diagramme de classes du sprint 1»

30
 CHAPITRE 3. SPRINT 1 « MISE EN PLACE D’UNE APPLICATION MOBILE »

3.4.2 Diagrammes de séquences détaillées

Montrons ci-dessous les diagrammes de séquences importants de notre application :

Diagramme de séquences « Authentification »

Pour profiter de l’utilisation de notre application, chaque employé doit s’authentifier.

L’authentification se fait à travers page d’authentification ou l’utilisateur doit obligatoire-
ment entrer son login et son mot de passe. Aprés la saisie des données un contrôle de saisie
se fait au niveau du classe « employé » pour vérifier la validité des données transmises. Si
toutes les données sont valides, ils seront transfères ensuite vers le même contrôleur qui
vérifie l’existence de l’employé dans l’entité « employé » s’il existe il sera redirigé vers la
page d’accueil sinon il doit retaper un autre login et mot de passe. Dans la figure 3.3, on
trouve le diagramme de séquence d’authentification.

Figure 3.3 – «Diagramme de séquences « Authentification d’employé»

31
 CHAPITRE 3. SPRINT 1 « MISE EN PLACE D’UNE APPLICATION MOBILE »

Diagramme de séquences « Scanner un produit »

La figure 3.4 ci-contre présente le diagramme de séquence correspondant au scannage

d’un produit.

Figure 3.4 – « Diagramme de séquences « Scanner un produit »

3.5 Implementation du sprint

Dans cette partie, nous allons présenter les différentes interfaces implémentées.

Interface d’authentification

Pour commencer, chaque employé doit s’identifier sur l’application mobile pour accé-
der aux interfaces comme son profil et pour pouvoir consulter, chercher et scanner des

32
 CHAPITRE 3. SPRINT 1 « MISE EN PLACE D’UNE APPLICATION MOBILE »

produits. Les champs de saisie sont vérifiés lorsqu’il clique sur « Se connecter ». Si les
informations sont fausses, des messages d’erreur vont être affichés. La figure 3.5 montre
l’interface d’authentification.

Figure 3.5 – « Interface authentification « Employé »

33
 CHAPITRE 3. SPRINT 1 « MISE EN PLACE D’UNE APPLICATION MOBILE »

Interface de barre latérale de navigation

Cette interface permet de guider l’utilisateur vers toutes les autres interfaces. L’em-
ployé peut scanner des produits et consulter les picklists. Et il peut aussi se déconnecter
en cliquant sur « Déconnexion » comme illustré dans la figure 3.8.

Figure 3.6 – « Interface de barre latérale de navigation»

34
 CHAPITRE 3. SPRINT 1 « MISE EN PLACE D’UNE APPLICATION MOBILE »

Interface des picklists

L’application contient une interface d’accueil qui affiche l’ensemble des picklists, comme
illustré dans les figures 3.6 et 3.7 :

Figure 3.7 – « Interface des picklists »

35
CHAPITRE 3. SPRINT 1 « MISE EN PLACE D’UNE APPLICATION MOBILE »

Figure 3.8 – « Interface de recherche des picklists »

36
 CHAPITRE 3. SPRINT 1 « MISE EN PLACE D’UNE APPLICATION MOBILE »

Interface des US

En cliquant sur une picklist, l’employé recevra les listes des us de cette picklist. Une
fois l’employé scanne un produit ce dernier change leur statut. La figure 3.11 illustre
l’interface des US.

Figure 3.9 – « Interface des us»

37
 CHAPITRE 3. SPRINT 1 « MISE EN PLACE D’UNE APPLICATION MOBILE »

Interface de scan de code

cette interface permet l’employé de scanner les produits afin de changer leur statut,
comme illustré dans les figures 3.9 et 3.10 :

Figure 3.10 – « Interface de scan de code»

38
CHAPITRE 3. SPRINT 1 « MISE EN PLACE D’UNE APPLICATION MOBILE »

Figure 3.11 – « Interface de scan des us»

39
 CHAPITRE 3. SPRINT 1 « MISE EN PLACE D’UNE APPLICATION MOBILE »

3.6 Test relatif au sprint 1

Dans la méthodologie SCRUM, pour assurer le bon fonctionnement du système, un
test est effectué à chaque fin d’une itération. Nous allons donc présenter les tests effectués
sur les étapes importantes du sprint.

3.6.1 Test des services web

Nous effectuerons quelques jeux d’essai pour tester les services web grâce à l’extension
Postman.
La méthode invoque l’authentification comme montre la figure 3.12.

Figure 3.12 – « Test des services web : Authentification d’employé »

40
 CHAPITRE 3. SPRINT 1 « MISE EN PLACE D’UNE APPLICATION MOBILE »

La méthode invoque la consultation des picklists comme illustre la figure 3.13.

Figure 3.13 – « Test des services web : Consultation des picklists »

41
 CHAPITRE 3. SPRINT 1 « MISE EN PLACE D’UNE APPLICATION MOBILE »

La méthode invoque la consultation de la liste des us comme montre la

figure 3.14.

Figure 3.14 – « Test des services web : la consultation des us»

42
 CHAPITRE 3. SPRINT 1 « MISE EN PLACE D’UNE APPLICATION MOBILE »

La méthode invoque le changement du statut des produits scannés comme

indique la figure 3.15.

Figure 3.15 – « Test des services web : Changement du statut»

3.6.2 Test de l’application

Nous avons effectué quelques jeux d’essai pour tester l’application.

Ce qui s’est bien passé :
- L’interface de connexion marche parfaitement.
- Les interfaces sont bien organisées.
- L’employé peut facilement consulter les picklists.
- L’employé peut consulter les us, les scanner et changer leur statut.
Ce qui peut être amélioré :
-Ajouter une page statistique de scan des produits par jour.

43
 CHAPITRE 3. SPRINT 1 « MISE EN PLACE D’UNE APPLICATION MOBILE »

Conclusion
Ce chapitre a été dédié à la présentation du premier sprint. Tout d’abord, nous avons
traité le backlog du sprint, puis, nous avons défini la conception en présentant des dia-
grammes des cas d’utilisation et de séquences. Ensuite, nous avons montré les interfaces
importantes de notre application mobile en décrivant leur objectif. Finissons avec une
section de test, pour montrer les résultats de notre application.

44
 CHAPITRE 4

SPRINT 2 « MISE EN PLACE D’UNE

APPLICATION WEB »

Introduction
Après avoir développé l’application mobile, nous nous intéressons au deuxième sprint
pour développer l’application web. Nous commençons donc par le backlog du sprint à faire,
puis nous montrons la conception de cette partie. Nous terminons avec l’implémentation
et les tests pour s’assurer que l’application répond à nos besoins.

4.1 Objectif du sprint

L’objectif de cette partie est de construire une application web qui permet de gérer les
employés et les picklists. Cette application est invisible aux employés, elle est seulement
accessible par les administrateurs de l’application. Elle est considéré comme un tableau
de bord qui nous permet de consulter toutes les informations à propos les picklists et les
us.
Pour les fonctionnalités de cette partie, nous avons utilisé les opérations suivantes :
Gérer les picklists :
- Consulter les listes des produits
- Ajouter une picklist

45
 Mise en place d’une application web

- Supprimer une picklist

Gérer les employés :
- Consulter un employé
- Ajouter un employé
- Supprimer un employé

4.2 Backlog du sprint

Comme indiqué précédemment, nous nous concentrons sur la liste des fonctionnalités
identifiées pour ce sprint. Voici les User Story réalisées par l’équipe SCRUM dans le
tableau 4.1 :

Id User Story
1 En tant qu’administrateur, je veux
m’authentifier sur l’application web.
2 En tant qu’administrateur, je veux
consulter la liste des produits demandé
et ses détails.
3 En tant qu’administrateur, je veux
consulter les us et ses détails.
4 En tant que administrateur, je veux
voir la liste des employés.
5 En tant qu’administrateur, je veux
ajouter des employés.
6 En tant qu’administrateur, je veux sup-
primer des employés.
7 En tant qu’administrateur, je veux
ajouter des picklists.
8 En tant qu’administrateur, je veux sup-
primer des picklists.

Table 4.1 – Backlog du sprint 2

4.3 Analyse des besoins

Afin de mieux expliquer les besoins à réaliser dans ce sprint, nous allons présenter le
diagramme de cas d’utilisation avec une description textuelle.

46
 Mise en place d’une application web

4.3.1 Diagramme de cas d’utilisation« Mise en place d’une ap-

plication web »

Le schéma 4.1 illustre le diagramme de cas d’utilisation de ce sprint :

Figure 4.1 – Diagramme de cas d’utilisation« Sprint 2»

47
 Mise en place d’une application web

4.3.2 Description de cas d’utilisation« Mise en place d’une ap-

plication web »

En vue d’analyser le diagramme de cas d’utilisation de sprint 1, nous allons établir la

description qui l’enrichir dans le tableau 4.2.

Titre Sprint 2
Acteur Administrateur
Prés condition Administrateur crée dans la base
de données.
Description du scéna- L’administrateur remplit le for-
rio mulaire de connexion pour accé-
der à la page d’acceuil.
L’administrateur consulte la liste
des employés.
L’administrateur consulte les pi-
cklistes et les us.
L’administrateur ajouter et sup-
primer un employé.
L’administrateur peut ajouter et
supprimer une picklist.

Table 4.2 – Description de cas d’utilisation du sprint 2

4.4 Conception du Sprint 2

Après avoir spécifié les fonctionnalités du backlog de ce sprint, nous allons passer à la
phase de conception pour mieux expliquer ces fonctionnalités à l’aide d’un diagramme de
classe et d’un diagramme de séquence.

48
 Mise en place d’une application web

4.4.1 Diagramme de classe détaillé

La figure 4.2 représente le diagramme de classe relatif au sprint 2 :

Figure 4.2 – « Diagramme de classes du Sprint 2»

4.4.2 Diagrammes de séquences détaillés

Nous montrons danc cette partie les diagrammes de séquences importants de notre
application.

49
 Mise en place d’une application web

Diagramme de séquences « Authentification de l’administrateur »

La figure 4.3 montre le diagramme de séquences d’authentification de l’administrateur.

Figure 4.3 – « Diagramme de séquences « Authentification d’administrateur »

50
 Mise en place d’une application web

Diagramme de séquences « Ajouter un employé »

La figure 4.4 montre le diagramme de séquences d’ajout d’un employé.

Figure 4.4 – « Diagramme de séquences « Ajouter un employé »

51
 Mise en place d’une application web

Diagramme de séquences « Supprimer un employé »

La figure 4.5 montre le diagramme de séquences de suppression d’un employé.

Figure 4.5 – « Diagramme de séquences « Supprimer un employé »

52
 Mise en place d’une application web

Diagramme de séquences « Ajouter une picklist »

La figure 4.6 montre le diagramme de séquences d’ajout d’une picklist.

Figure 4.6 – « Diagramme de séquences « Ajouter une picklist »

53
 Mise en place d’une application web

Diagramme de séquences « Supprimer une picklist »

La figure 4.7 montre le diagramme de séquences de suppression d’une picklist.

Figure 4.7 – « Diagramme de séquences «Supprimer une picklist»

54
 Mise en place d’une application web

4.5 Implémentation du sprint

Dans cette partie, nous vous montrons les différentes interfaces de l’application web.

Interface d’authentification

La figure 4.8 présente l’interface d’authentification de l’administrateur.

Figure 4.8 – « Interface d’authentification d’administrateur »

55
 Mise en place d’une application web

Interface de dashboard

Nous trouvons dans la figure 4.9, la page d’accueil de l’interface administratrice. Dans
la première vue, nous avons un dashboard qui présente les listes des produits demandés.

Figure 4.9 – « Interface de dashboard »

56
 Mise en place d’une application web

Interface de Gestion des employés

Une fois authentifié, l’administrateur peut consulter la liste de tous les employés. Il
peut ajouter ou supprimer un employé.
La figure 4.10 illustre ces opérations.

Figure 4.10 – « Interface de gestion des employés »

57
 Mise en place d’une application web

La figure 4.11 montre l’interface d’ajout d’employé.

Figure 4.11 – « Interface d’ajout d’employé »

58
 Mise en place d’une application web

La figure 4.12 illustre la suppression de l’employé.

Figure 4.12 – « Interface de suppression d’un employé »

59
 Mise en place d’une application web

Interface de Gestion des Picklists

La figure 4.13 permet de montrer l’interface de la gestion des picklists. Chaque picklist
possède ses propres informations. L’administrateur a le droit d’ajouter ou supprimer une
picklist.

Figure 4.13 – « Interface des Picklists »

60
 Mise en place d’une application web

La figure 4.14 montre l’interface d’ajout d’une picklist.

Figure 4.14 – « Interface d’ajout d’une Picklist »

61
 Mise en place d’une application web

La figure 4.15 montre l’interface de suppression d’une picklist.

Figure 4.15 – « Interface de suppression d’une Picklist »

62
 Mise en place d’une application web

4.6 Test relatif au sprint 2

Pour l’application web, les tests sont effectués sur les étapes importantes du sprint.

4.6.1 Test des services web

La méthode invoque l’authentification de l’administrateur comme indique

la figure 4.16.

Figure 4.16 – « Test des services web : Authentification d’administrateur»

63
 Mise en place d’une application web

La méthode invoque l’ajout d’un employé comme indique la figure 4.17.

Figure 4.17 – « Test des services web : Ajout d’un employé »

64
 Mise en place d’une application web

La méthode invoque la suppression d’un employé comme indique la figure

4.18.

Figure 4.18 – « Test des services web : Suppression d’un employé »

65
 Mise en place d’une application web

La méthode invoque l’ajout d’une picklist comme indique la figure 4.19.

Figure 4.19 – « Test des services web : Ajout d’une picklist »

66
 Mise en place d’une application web

La méthode invoque la suppression d’une picklist comme indique la figure

4.20.

Figure 4.20 – « Test des services web : Suppression d’une picklist »

4.6.2 Test de l’application

Les étapes suivies pour les tests sont :

• L’ajout d’un nouveau produit à partir de l’interface administrateur de vérifier sa créa-
tion sur le dashboard.
• Suppression d’un produit et de le vérifier sur le dashboard.
• L’ajout ou la suppression des employés à partir de l’interface administrateur.
Après avoir effectué tous les tests nécessaires, voici le résultat trouvé :
Les fonctions sont toutes fonctionnelles et permettent d’échanger les informations de ma-
nière efficace et fluide. Les tableaux illustrant les informations des listes des produits sont
dépendants des données saisies.
Ce qui peut être amélioré :
- La mise à jour des picklists et des employés.

67
 Mise en place d’une application web

Conclusion
Dans ce chapitre, nous avons présenté le deuxième sprint. D’abord, nous avons com-
mencé par l’objectif de ce sprint, pour ensuite introduire le backlog du sprint. Nous avons
ensuite élaboré la conception et la réalisation du sprint, pour en finir avec les tests effec-
tués. Finissons avec une section de test, pour montrer les résultats de notre application
et ce qui peut être amélioré.

68
 CONCLUSION GÉNÉRALE

Ce rapport représente le fruit des travaux réalisés au sein de SAGEMCOM dans le

cadre de notre projet de fin d’études pour l’obtention du diplôme national licence en Ingé-
nierie des systèmes Informatique. Il s’agit en effet de concevoir et réaliser une application
mobile et une application web pour la gestion des picklists.
Nous avons étudié les méthodes agiles pour assurer le suivi et la gestion du projet et nous
avons opté pour la méthodologie SCRUM.
Pour aboutir à ce résultat, nous avons commencé tout d’abord par comprendre le contexte
général qui nous a permis d’établir une critique consistante pour poser la problématique.
Puis nous avons déterminé les différents besoins et exigences relevés. Ensuite, nous avons
découpé les parties en sprint pour montrer les phases de conceptions et de réalisation de
nos applications tout en utilisant notre méthode de départ.
Durant cette période de stage, au sein de l’équipe de développeurs SAGEMCOM et lors
de l’élaboration de ce projet, nous avons pu appliquer et améliorer nos connaissances ac-
quises lors de notre cursus académique au sein de Faculté des Sciences de Tunis. Nous
avons aussi eu l’occasion de procurer de nouvelles compétences techniques et relation-
nelles.
Comme perspectives de travaux futurs, nous allons nous concentrer à enrichir ce projet en
ajoutant d’autres fonctionnalités. En effet, nous proposons d’ajouter une page statistique
du scan des produits et de gérer les us afin que l’application soit officiellement lancée dans
la société.

69
 NETOGRAPHIE

[1] http://www.hrcareers.fr/societe/sagemcom-303.html Date de dernière consul-

tation : 03/04/2022

[2] https://sagemcom.com/sites/default/files/2020-11/
Rapport20RSE20201920FR.pdf Date de dernière consultation : 03/04/2022

[3] https://www.sagemcom.com/V02/fileadmin/user_upload/RADD_Sagemcom_2018_
EN.pdf Date de dernière consultation : le 03/04/2022

[4] https://www.mecalux.fr/blog/picklist-logistique. Date de dernière consulta-

tion : 25/04/2022.

[5] https://everlaab.com/methode-agile/. Date de dernière consultation :

28/04/2022.

[6] https://fr.mailjet.com/blog/news/methode-agile-scrum/. Date de dernière

consultation : 28/04/2022.

[7] https://www.lucidchart.com/pages/fr/langage-uml. Date de dernière consulta-

tion : 28/04/2022.

[8] https://fr.wikipedia.org/wiki/Visual_Studio_Code. Date de dernière consulta-

tion : 28/04/2022.

[9] https://www.techno-science.net/glossaire-definition/Visual-Studio.
html. Date de dernière consultation : 28/04/2022.

[10] https://docs.microsoft.com/fr-fr/sql/relational-databases/databases/
databases?view=sql-server-ver16. Date de dernière consultation : 30/04/2022.

70
[11] https://www.android.com/intl/fr_fr/what-is-android/. Date de dernière
consultation : 2/05/2022.

[12] https://monpetitdev.fr/cest-quoi-angular-definition/. Date de dernière

consultation : 26/05/2022.

[13] https://www.hostinger.fr/tutoriels/cest-quoi-bootstrap/. Date de dernière

consultation : 22/05/2022.

[14] https://www.journaldunet.fr/web-tech/dictionnaire-du-webmastering/
1203555-java-definition/. Date de dernière consultation : 20/05/2022.

[15] https://www.techtarget.com/whatis/definition/C-Sharp. Date de dernière

consultation : 18/04/2022.

[16] https://techlib.fr/definition/aspnet.html. Date de dernière consultation :

28/04/2022.

[17] https://swagger.io/tools/swagger-ui/. Date de dernière consultation :

26/03/2022.

[18] https://practicalprogramming.fr/postman/. Date de dernière consultation :

26/03/2022.

[19] https://www.aurone.com/blog/architecture-mvc/. Date de dernière consulta-

tion : 02/03/2022.

[20] https://iot.goffinet.org/iot_protocole_mqtt.html. Date de dernière consul-

tation : 26/05/2022.
RESUMÉ
Ce travail fait l’objectif d’un projet de fin d’études au sein de la Faculté des sciences de Tunis.
Il a été effectué durant une période de stage de 4 mois à la société Sagemcom. L’objectif de
notre projet de fin d’études consiste à implémenter une application mobile qui permettra à
l’employé de consulter et de scanner les produits demandés, et une application web permettant
aux administrateurs de gérer les employés et les picklists.
Mot clés : Application web, Application mobile, Picklist, Agile scrum

ABSTRACT
This work is the objective of a graduation project in the Faculty of Science of Tunis. It was
completed during a 4-month internship period at Sagemcom. Our end-of-study project aims to
implement a mobile application that will allow the employee to consult and scan the requested
products, and a web application allowing administrators to manage employees and picklists.
Keywords : Web Application, Mobile Application, Picklist, Agile scrum

‫ملخص‬
‫ وقد أنجز خالل فترة تدريب لمدة أربعة أشهر في‬،‫هذا العمل هو هدف مشروع التخرج في كلية العلوم بتونس‬
‫ « والهدف من مشروع تخرجنا هو تنفيذ تطبيق على الهاتف المحمول يسمح للموظفين‬Sagemcom »
‫باستشارة ومسح المنتجات المطلوبة ضوئيا وتطبيق على الشبكة العالمية يسمح للمسؤولين بإدارة الموظفين‬
.‫وقوائم االنتقاء‬
‫ أجيل سكروم‬،‫ قائمة االنتقاء‬،‫ تطبيق الهاتف المحمول‬،‫ تطبيق ويب‬:‫الكلمات الرئيسية‬