MINISTERE DE L’ENSEIGNEMENT SUPERIEUR

ET DE LA RECHERCHE SCIENTIFIQUE
UNIVERSITE DE SOUSSE

‫المعهد العالي لإلعالمية و تقنيات االتصال بحمام سوسة‬

INSTITUT SUPERIEUR D’INFORMATIQUE

ET DES TECHNIQUES DE COMMUNICATION – HAMMAM SOUSSE

MEMOIRE DE STAGE FIN D’ETUDES

Présenté en vue de l’Obtention du Diplôme National d’Ingénieur

Spécialité : Téléinformatique

Développement d’une Application Mobile E-

Commerce « Home Shop » Basée sur la
Réalité Augmentée

Réalisé par :
Bouthaina GHACHEM

Encadré par :
Encadrant pédagogique : Mr. Ali El Kamil
Encadrante Technique : Mme. Dhekra Rouatbi

Société d’accueil

Année Universitaire 2018 – 2019

 MINISTERE DE L’ENSEIGNEMENT SUPERIEUR
ET DE LA RECHERCHE SCIENTIFIQUE
UNIVERSITE DE SOUSSE

‫المعهد العالي لإلعالمية و تقنيات االتصال بحمام سوسة‬

INSTITUT SUPERIEUR D’INFORMATIQUE

ET DES TECHNIQUES DE COMMUNICATION – HAMMAM SOUSSE

MEMOIRE DE STAGE FIN D’ETUDES

Présenté en vue de l’Obtention du Diplôme National d’Ingénieur

Spécialité : Téléinformatique

Développement d’une Application Mobile E-

Commerce « Home Shop » Basée sur la
Réalité Augmentée

Réalisé par :
Bouthaina GHACHEM

Encadrant pédagogique : Ali El Kamil Date :…………………….Signature :…………

Encadrante Technique : Dhekra Rouatbi Date :…………………..Signature :……….....

Année Universitaire 2018 – 2019

 Dédicaces
Je dédie ce modeste travail en signe de reconnaissance et d’amour à …

À mon cher père Abderrazek, pour tous ses sacrifices consentis en veillant à me
procurer toutes les conditions de réussite.

À ma très chère mère Awatef, affable, honorable, aimable : Tu représentes pour moi
le symbole de la bonté par excellence, la source de tendresse et l'exemple du dévouement
qui n'a pas cessé́ de m'encourager et de prier pour moi. Ta prière et ta bénédiction m'ont été
d'un grand secours à bien mener mes études.

À mes très chères sœurs Zahra, Rania, et à mon cher frère Rami, pour leur amour,
encouragement et leur soutien moral tout en long de mes études.

À ma chère tante Wahida, que la force et le courage soient avec toi et que la
patience t’aide à affronter cette maladie maligne.

À tous les membres de ma famille, petits et grands, pour leurs soutiens et leurs
bonheurs de me voir réussir mes études.

À mes chers amis : Salma, Rania, Cheima, Aymen, Houssem, Hassine et Bassem.
Je ne peux pas trouver les mots justes et sincères pour vous exprimer mon affection et mes
pensées, vous êtes pour moi des frères, sœurs et des amis sur qui je peux compter. En
témoignage de l’amitié qui nous unit et des souvenirs de tous les moments que nous avons
passé ensemble, je vous dédie ce travail et je vous souhaite une vie pleine de santé et de
bonheur.

À tous mes amis, qui m’aiment et avec qui je trouve le bonheur d’une bonne
compagnie.

À toutes personnes qui m’ont appris un mot que ce travail soit un témoignage de ma
gratitude et mon profond respect.

Puisse ce travail s'élever au rang d'une référence qui attire tout l'intérêt dans
les domaines de projets guidés par Scrum et réunissant mobile iOS, réalité
augmentée et e-commerce.

 … Bouthaïna
 Remerciements
Je remercie Dieu tout-puissant de m’avoir donné la santé, la force physique et mentale pour
pouvoir terminer mes études dans les meilleures conditions.

Je remercie vivement toutes les personnes qui ont participé de différentes façons à la
réussite de mon stage et plus particulièrement :

Monsieur Wassel Berrayana, le directeur général de la société PROXYM-GROUP, pour

m’avoir donné l’opportunité de développer mes travaux de mémoire au sein de sa société.

Monsieur Zied Abdelwahed, responsable du département mobile, de m’avoir accueilli et de

m’avoir permis de travailler dans des conditions matérielles et humaines idéales. Ces quatre
mois de travail ont été, pour moi, une aventure particulièrement enrichissante, sur le plan
scientifique et humain.

Monsieur Ali El Kemil, mon encadrant à l'Institut supérieur de l'informatique et des

technologies de la communication, qui m’a supervisé durant la réalisation de ce travail. Je
tiens par la même occasion à lui exprimer mes profondes gratitudes.

Madame Hedia Jegham, pour ses instructions et ses conseils qui ont été pour moi d’un
apport précieux et enrichissant.

Madame Dhekra Rouatbi, mon encadrante professionnelle pour m'avoir intègré rapidement
au sein de l'entreprise et m'avoir accordé toute sa confiance, pour le temps qu'elle m'a
consacré tout au long de cette période, en répondant à toutes mes interrogations.

Monsieur Salmene Nouire, pour sa créativité qui s’est reflétée dans l’idée de ce projet et
pour ses inestimables directives.

Tous mes enseignants pour les efforts qu’ils ont fourni tout au long de ma formation.

Enfin, mes sincères reconnaissances sont destinées aux respectueux membres du

jury en espérant qu'ils trouvent dans ce rapport les qualités de clarté et de motivation qu'ils
attendent.

 … Bouthaïna
 Table Des Matières
Introduction Générale ............................................................................................................................. 1
Chapitre 1 : Cadre Général du Projet .................................................................................................... 3
Introduction......................................................................................................................................... 4
1.1 Présentation de l’organisme d’accueil .................................................................................. 4
1.1.1 Proxym-IT .......................................................................................................................... 4
1.1.2 Activités de base et savoir-faire ......................................................................................... 5
1.1.3 Départements et équipes .................................................................................................... 5
1.2 Présentation du contexte du projet ........................................................................................ 6
1.2.1 M-Commerce en chiffre .................................................................................................... 6
1.2.2 Réalité augmentée ............................................................................................................. 7
1.3 Présentation du projet ............................................................................................................ 8
1.3.1 Problématique et étude de l’existant ................................................................................. 8
1.3.2 Solution proposée .............................................................................................................. 9
1.4 Méthodologie de travail ....................................................................................................... 10
1.4.1 Framework Scrum ........................................................................................................... 10
1.4.2 Scrum Rôle, événement et artefacts ................................................................................ 10
Conclusion......................................................................................................................................... 12
Chapitre 2 : Lancement Du Projet « HomeShop » .............................................................................. 13
Introduction....................................................................................................................................... 14
2.1 Architecture de la solution .................................................................................................. 14
2.1.1 Architecture physique ...................................................................................................... 14
2.1.2 Architecture logique ........................................................................................................ 15
2.2 Analyse et Spécification des besoins de « HomeShop » ..................................................... 16
2.2.1 Identification des acteurs ................................................................................................ 16
2.2.2 Diagramme de contexte ................................................................................................... 16
2.2.3 Identification des besoins ................................................................................................ 17
2.3 Product Backlog ................................................................................................................... 18
2.3.1 Technique de priorisation du PB .................................................................................... 19
2.3.2 Product Backlog priorisé ................................................................................................. 19
2.3.3 Transposition du PB en diagramme de cas d’utilisation général.................................. 21
2.4 Pratique de principes Scrum ............................................................................................... 23
2.4.1 Établissement de la « Definition of Done » .................................................................... 23
2.4.2 Planification des sprints du projet « HomeShop » ......................................................... 23
2.5 Environnements de travail................................................................................................... 24
2.5.1 Environnement matériel.................................................................................................. 24
2.5.2 Environnement technique ............................................................................................... 25
Conclusion......................................................................................................................................... 25
Chapitre 3 : Sprint 1 : Préparation de la Base de Données et de l’API REST ................................... 26
Introduction....................................................................................................................................... 27
 3.1 HomeShop Sprint 1 planning .............................................................................................. 27
3.1.1 Objectif du sprint 1 .......................................................................................................... 27
3.1.2 Sprint Backlog du Sprint 1 .............................................................................................. 27
3.2 Analyse ................................................................................................................................. 28
3.2.1 Étude comparative des plateformes de E-Commerce ..................................................... 28
3.2.2 Étude comparative des APIs graphique 3D .................................................................... 29
3.3 Conception ........................................................................................................................... 30
3.3.1 Conception des objets 3D ................................................................................................ 30
3.3.2 Intégration des objets 3D................................................................................................. 31
3.4 Réalisation ............................................................................................................................ 31
3.4.1 Outils ................................................................................................................................ 31
3.4.2 Captures d’écran de l’incrément 1 potentiellement livrable .......................................... 32
Conclusion......................................................................................................................................... 34
Chapitre 4 : Sprint 2 : Écran d’Accueil « HomeShop » ...................................................................... 35
Introduction....................................................................................................................................... 36
4.1 HomeShop Sprint 2 planning .............................................................................................. 36
4.1.1 Objectif du sprint 2 .......................................................................................................... 36
4.1.2 Sprint Backlog du Sprint 2 .............................................................................................. 36
4.2 Analyse ................................................................................................................................. 37
4.2.1 Raffinement et description des cas d’utilisations ........................................................... 37
4.2.2 Proposition des maquettes ............................................................................................... 37
4.3 Conception ........................................................................................................................... 38
4.3.1 Diagramme d’activité ...................................................................................................... 38
4.3.2 Diagramme de classes ..................................................................................................... 39
4.4 Réalisation ............................................................................................................................ 39
4.4.1 Outils ................................................................................................................................ 39
4.4.2 Captures d’écran de l’incrément 2 potentiellement livrable .......................................... 40
Conclusion......................................................................................................................................... 42
Chapitre 5 : Sprint 3 : Écran Scène de Test Avec La Réalité Augmentée .......................................... 43
Introduction....................................................................................................................................... 44
5.1 HomeShop Sprint 3 planning .............................................................................................. 44
5.1.1 Objectif du sprint 3 .......................................................................................................... 44
5.1.2 Sprint Backlog du Sprint 3 .............................................................................................. 44
5.2 Analyse ................................................................................................................................. 45
5.2.1 Raffinement et description des cas d’utilisations ........................................................... 45
5.2.2 Proposition des maquettes ............................................................................................... 48
5.3 Conception ........................................................................................................................... 48
5.3.1 Diagramme de séquences ................................................................................................ 48
5.3.2 Diagramme de classes ..................................................................................................... 51
5.4 Réalisation ............................................................................................................................ 51
5.4.1 Outils ................................................................................................................................ 51
5.4.2 Captures d’écran de l’incrément 3 potentiellement livrable .......................................... 51
Conclusion......................................................................................................................................... 59
Chapitre 6 : Sprint 4 : Écran de Gestion du Panier « HomeShop » ................................................... 60
Introduction....................................................................................................................................... 61
 6.1 HomeShop Sprint 4 planning .............................................................................................. 61
6.1.1 Objectif du sprint 4 .......................................................................................................... 61
6.1.2 Sprint Backlog du Sprint 4 .............................................................................................. 61
6.2 Analyse ................................................................................................................................. 62
6.2.1 Raffinement et description des cas d’utilisations ........................................................... 62
6.2.2 Proposition des maquettes ............................................................................................... 62
6.3 Conception ........................................................................................................................... 63
6.3.1 Diagramme de séquence.................................................................................................. 63
6.3.2 Diagramme de classes ..................................................................................................... 64
6.4 Réalisation ............................................................................................................................ 66
6.4.1 Outils ................................................................................................................................ 66
6.4.2 Captures d’écran de l’incrément 4 potentiellement livrable .......................................... 66
Conclusion......................................................................................................................................... 68
Chapitre 7 : Sprint 5 : Écran d’Inscription, Connexion et Profil « HomeShop ».............................. 69
Introduction....................................................................................................................................... 70
7.1 HomeShop Sprint 5 planning .............................................................................................. 70
7.1.1 Objectif du sprint 5 .......................................................................................................... 70
7.1.2 Sprint Backlog du Sprint 5 .............................................................................................. 70
7.2 Analyse ................................................................................................................................. 71
7.2.1 Raffinement et description des cas d’utilisations ........................................................... 71
7.2.2 Proposition des maquettes ............................................................................................... 72
7.3 Conception ........................................................................................................................... 73
7.3.1 Diagramme d’Activité...................................................................................................... 73
7.3.2 Diagramme de classes ..................................................................................................... 74
7.4 Réalisation ............................................................................................................................ 76
7.4.1 Outils ................................................................................................................................ 76
7.4.2 Captures d’écran de l’incrément 5 potentiellement livrable .......................................... 76
Conclusion......................................................................................................................................... 80
Chapitre 8 : Sprint 6 : Processus de Passage de Commande et Écran d’Historique ......................... 81
Introduction....................................................................................................................................... 82
8.1 HomeShop Sprint 6 planning .............................................................................................. 82
8.1.1 Objectif du Sprint 6 ......................................................................................................... 82
8.1.2 Sprint Backlog du Sprint 6 .............................................................................................. 82
8.2 Analyse ................................................................................................................................. 83
8.2.1 Raffinement et description des cas d’utilisations ........................................................... 83
8.2.2 Proposition des maquette ................................................................................................ 84
8.3 Conception ........................................................................................................................... 85
8.3.1 Diagramme de temps ....................................................................................................... 85
8.3.2 Diagramme de classes ..................................................................................................... 85
8.4 Réalisation ............................................................................................................................ 87
8.4.1 Outils ................................................................................................................................ 87
8.4.2 Captures d’écran de l’incrément 6 potentiellement livrable .......................................... 87
Conclusion......................................................................................................................................... 91
Chapitre 9 : Synthèse de la Release : Préparation au Déploiement de « HomeShop » ..................... 92
Introduction....................................................................................................................................... 93
 9.1 Lunch Screen de l’application ............................................................................................ 93
9.2 Icône de l’application .......................................................................................................... 93
9.3 Diagramme de classes final ................................................................................................. 94
9.4 Diagramme de paquetages................................................................................................... 97
9.5 Diagramme de déploiement ................................................................................................. 98
9.6 Analyse SWOT ..................................................................................................................... 98
9.7 Product Backlog de la deuxième release ............................................................................ 99
Conclusion......................................................................................................................................... 99
Conclusion Générale ........................................................................................................................... 100
Webographie ........................................................................................................................................ 101
 1 Liste Des Figures
Figure 1-1 : Logo du Proxym-IT ............................................................................................................................ 5
Figure 1-2 : Organigramme de Proxym Group...................................................................................................... 5
Figure 1-3 : Images descriptives du Problématique ............................................................................................... 8
Figure 1-4 : Logo Meublatex Figure 1-5 : Logo Graït ................................................................. 9
Figure 1-6 : Logo Ikea Places Figure 1-7 : Logo Wayfair .............................................................................. 9
Figure 1-8 : Processus Scrum ............................................................................................................................... 11
Figure 2-1: Architecture physique de « HomeShop ».......................................................................................... 14
Figure 2-2 : Architecture MVC traditionnelle ..................................................................................................... 15
Figure 2-3 : Apple MVC « Cocoa MVC » ............................................................................................................ 15
Figure 2-4 : Diagramme de Contexte ................................................................................................................... 16
Figure 2-5: Diagramme de cas d'utilisation global.............................................................................................. 22
Figure 3-1 : Logo SceneKit Figure 3-2 : Logo SpriteKit ............................................................................ 29
Figure 3-3 : Logo Unity Figure 3-4 : Logo Metal ........................................................................................... 29
Figure 3-5 : Arborescence de répertoires fournit par Apple................................................................................ 31
Figure 3-6 : Architecture physique complète de « HomeShop » ......................................................................... 33
Figure 3-7 : Dashboard Moltin ............................................................................................................................. 33
Figure 3-8 : Capture démonstrative de l'intégration des objets 3D ..................................................................... 34
Figure 4-1 : Raffinement de cas d'utilisation « Consultation des catégories » .................................................. 37
Figure 4-2 : Maquette « Écran d'accueil »........................................................................................................... 38
Figure 4-3 : Diagramme d'activité de cas d'utilisation « Consulter les catégorie » ........................................... 38
Figure 4-4 : Incrément du Diagramme de classes du Sprint 1 ............................................................................ 39
Figure 4-5 : Barre de navigation « HomeShop » ................................................................................................. 40
Figure 4-6 : Chargement de l’interface de l’écran d'accueil « HomeShop » ..................................................... 41
Figure 4-7 : Écran d'accueil « HomeShop »........................................................................................................ 41
Figure 5-1 : Raffinement de cas d'utilisation « Test des articles dans le monde réel via caméra » .................. 46
Figure 5-2 : Maquettes « Écran de test RA » ....................................................................................................... 48
Figure 5-3 : Diagramme de séquence « Détection d'un plan » ........................................................................... 49
Figure 5-4 : Diagramme de séquence « Chargement des modèles 3D » ............................................................. 50
Figure 5-5 : Incrément du diagramme de classe de Sprint 2 ............................................................................... 51
Figure 5-6 : Écrans d’initialisation de la scène AR ............................................................................................. 52
Figure 5-7 : Écrans de détection du plan ............................................................................................................. 53
Figure 5-8 : Écran de détection des points caractéristiques ................................................................................ 54
Figure 5-9 : Écrans d’affichage de Catalogue en 3D .......................................................................................... 54
Figure 5-10 : Écrans de chargement des modèles 3D.......................................................................................... 55
Figure 5-11 : Écran d'erreur de chargement de modèle...................................................................................... 55
Figure 5-12 : Écrans « Menu help »..................................................................................................................... 56
Figure 5-13 : Écran de suppression d’un modèle de la scène AR ....................................................................... 57
Figure 5-14 : Écrans de Changement de couleur d’un modèle........................................................................... 57
Figure 5-15 : Écrans de prise d’une instance de photo ....................................................................................... 58
Figure 5-16 : Écran d’ajout des modèle dans le panier ....................................................................................... 59
Figure 6-1 : Raffinement du cas d’utilisation « Gestion du panier » ................................................................. 62
Figure 6-2 : Maquettes « Écran de panier » ........................................................................................................ 63
Figure 6-3 : Diagramme de séquence du cas d'utilisation « Ajouter au panier » .............................................. 64
Figure 6-4 : Incrément du diagramme de classes du Sprint 4 ............................................................................. 65
Figure 6-5 : Écran de panier « HomeShop » ....................................................................................................... 66
Figure 6-6 : Processus de gestion de panier « Modification des quantités » ...................................................... 67
Figure 6-7 : Processus de gestion de panier « Suppression d’un article » ......................................................... 68
Figure 7-1 : Raffinement de cas d’utilisation « Inscription » ............................................................................. 71
Figure 7-2 : Raffinement du cas d’utilisation « Gestion du compte » ................................................................ 72
Figure 7-3 : Maquettes « Écran d’inscription, de connexion et de profil utilisateur » ...................................... 73
Figure 7-4 : Diagramme d’activité du cas d’utilisation « Authentification » ..................................................... 74
Figure 7-5 : Incrément du diagramme de classe du Sprint 5 .............................................................................. 75
Figure 7-6 : Incrément de l’écran de Profil du Sprint 5 ...................................................................................... 76
Figure 7-7 : Écrans d’inscription et de connexion « HomeShop » ..................................................................... 77
Figure 7-8 : Processus de création d’un Compte sur « HomeShop » ................................................................. 78
Figure 7-9 : Processus d’accès au Compte sur « HomeShop » ........................................................................... 79
Figure 7-10 : Écrans de gestion du compte sur « HomeShop » .......................................................................... 80
Figure 8-1 : Raffinement de cas d’utilisation « Passage d’une commande »..................................................... 83
Figure 8-2 : Raffinement du cas d’utilisation « Consultation de l’historique des commandes » ...................... 84
Figure 8-3 : Maquette « Écran du profil » modifiée Figure 8-4 : Maquette « Écran d’ajout d’adresse » ... 85
Figure 8-5 : Diagramme de temps de l’objet « Panier » ...................................................................................... 85
Figure 8-6 : Incrément du diagramme de classe du Sprint 6 .............................................................................. 86
Figure 8-7 : Écran d’ajout d’une adresse de livraison ........................................................................................ 87
Figure 8-8 : Processus de passage du commande pour un client qui a une adresse de livraison ...................... 88
Figure 8-9 : Processus de passage du commande pour un client qui n’a pas encore une adresse de livraison 89
Figure 8-10 : Écran de profil utilisateur final de « HomeShop » ....................................................................... 90
Figure 8-11 : Écran de l’historique des commandes de « HomeShop » ............................................................. 91
Figure 9-1 : Écran de lancement « HomeShop »................................................................................................. 93
Figure 9-2 : Logo « HomeShop » ......................................................................................................................... 94
Figure 9-3 : Diagramme de classe de la Release.................................................................................................. 95
Figure 9-4 : Diagramme de paquetage de la release............................................................................................ 97
Figure 9-5 : Diagramme de déploiement .............................................................................................................. 98

2 Liste Des Tableaux

Tableau 1-1 : Identité Proxym-IT ........................................................................................................................... 4

Tableau 2-1 : Product Backlog priorisé................................................................................................................ 19
Tableau 2-2 : Planification des Sprints ................................................................................................................ 24
Tableau 2-3 : Caractéristiques de l'ordinateur..................................................................................................... 24
Tableau 2-4 : Caractéristiques du smartphone .................................................................................................... 25
Tableau 3-1 : Sprint Backlog du Sprint 1 ............................................................................................................. 28
Tableau 3-2 : Tableau comparatif des plateformes E-Commerce ....................................................................... 28
Tableau 3-3 : Tableau comparatif des APIs graphique 3D ................................................................................. 29
Tableau 4-1 : Sprint Backlog du Sprint 2 ............................................................................................................. 36
Tableau 4-2 : Description textuelle du cas d'utilisation « Consultation des catégories » .................................. 37
Tableau 5-1 : Product Backlog du Sprint 5 .......................................................................................................... 44
Tableau 5-2 : Description textuelle détaillée du cas d'utilisation « Test des articles dans le monde réel »....... 46
Tableau 6-1 : Sprint Backlog du Sprint 4 ............................................................................................................. 61
Tableau 6-2 : Description textuelle du cas d’utilisation « Gestion du panier » .................................................. 62
Tableau 7-1 : Sprint Backlog du Sprint 5 ............................................................................................................. 70
Tableau 7-2 : Description textuelle du cas d’utilisation « Inscription » ............................................................. 71
Tableau 7-3 : Description textuelle de cas d’utilisation « Authentification » ..................................................... 72
Tableau 7-4 : Description textuelle de cas d’utilisation « Gestion du compte » ................................................. 72
Tableau 8-1 : Sprint Backlog du Sprint 6 ............................................................................................................. 82
Tableau 8-2 : Description textuelle détaillée du cas d’utilisation « Passage d’une commande » ...................... 83
Tableau 8-3 : Description textuelle du cas d’utilisation « Consultation de l’historique des commandes » ...... 84
Tableau 9-1 : Dictionnaire de diagramme de classe final ................................................................................... 96
Tableau 9-2 : Analyse SWOT de « HomeShop ».................................................................................................. 98
Tableau 9-3 : Product Backlog du deuxième release ........................................................................................... 99
Introduction Générale

Introduction Générale

Depuis ces deux dernières décades, l’humanité a fait des pas énormes dans tout ce qui a
attrait à l’innovation, progrès technologique et évolution de l’image. Cette grande évolution a
grandement servi l’homme dans son environnement et aussi a amélioré de façon considérable
son niveau de vie. L’informatisation a facilité la tâche de l’homme, il devient donc possible de
partager les informations et d’accéder à distance à tout ce dont on a besoin.

C’est dans cette optique, plusieurs entreprises n'ont pas hésité à exploiter les technologies
avancées pour offrir des services innovants et rapides à leurs consommateurs. « PROXYM
GROUP » est une des sociétés qui vise à exploiter les nouvelles technologies dans ses services.

Dans ce cadre s'inscrit notre stage de fin d'études pour l’obtention du Diplôme National
d’Ingénieur en Téléinformatique. Ce projet a eu lieu dans la société « Proxym-IT », une des
entités les plus connues de « PROXYM GROUP », ayant pour but le développement d’une
application mobile e-commerce sous la plateforme iOS basée sur la réalité augmenté, qui est
un des marchés les plus prometteurs. Elle représente un store virtuel de meubles de maison.

La réalisation de ce projet sera dirigée par le cadre de processus de la méthodologie Agile

« Scrum », à cet effet, la structure de ce présent rapport imprégnée par ce cadre de processus
s'étalera sur neuf chapitres :

Le premier chapitre porte sur la présentation de l’organisme d’accueil, le cadre du projet

et la méthodologie de travail utilisée.

Le deuxième chapitre tente d’aborder la phase d’analyse du projet en présentant

l’architecture du produit, les besoins fonctionnels et non fonctionnels afin d’aboutir à la
description du Product Backlog et la planification des sprints nécessaires pour la mise en œuvre
de l’application.

Le troisième chapitre forme l’objet d’un premier Sprint et a pour objectif la préparation de
la base de données et API REST.

Le quatrième chapitre présente le deuxième Sprint qui vise à développer l’écran d’accueil
de notre application mobile.

Le cinquième chapitre présente le troisième Sprint qui est le maitre d’ouvrage de notre
travail et a pour but de développer le processus de test des meubles de maison avec la réalité
augmentée.

Le sixième chapitre expose le quatrième Sprint qui a pour objectif l’implémentation des
écrans des comptes et profils de notre application.

Le septième chapitre amène à la réalisation du cinquième Sprint qui vise à développer

l’écran de gestion du panier.

Page 1 sur 116

Introduction Générale

Le huitième chapitre montre l’implémentation du processus de passage des commandes et

l’écran de l’historique qui est l’objectif du sixième Sprint.

Ce rapport est clôturé par un dernier chapitre qui forme l’objet d’une synthèse du travail
réalisé et une conclusion générale.

Enfin, il est porté à l’attention de tous lecteurs de ce modeste rapport que nous avons eu
recours aux termes anglais originaux de Scrum, afin d’assurer un maximum de juxtaposition
avec le travail sur le terrain et éviter la perte de sens des termes par la diversité des traductions.

Page 2 sur 116

 Chapitre 1

1 Cadre Général du Projet

Plan

Introduction........................................................................................................................................ 4
1.1 Présentation de l’organisme d’accueil ................................................................................ 4
1.2 Présentation du contexte ...................................................................................................... 6
1.3 Présentation du projet .......................................................................................................... 8
1.4 Méthodologie de travail ...................................................................................................... 10
Conclusion ........................................................................................................................................ 12
Chapitre 1. Cadre Général Du Projet

Introduction

Ce chapitre présente dans un premier lieu la société d’accueil « PROXYM-GROUP », et

dans un second lieu met l’accent sur le contexte du projet en décrivant la technologie de la
réalité augmenté. Puis, nous présentons le projet en soulevant la problématique puis en
envisageant une solution. Finalement, nous justifions le choix de la méthodologie adoptée pour
la réalisation du projet.

1.1 Présentation de l’organisme d’accueil

1.1.1 Proxym-IT

« PROXYM Group » [1] , a été lancée en 2006, c’est une société informatique
internationale présente en Europe, au Moyen-Orient et en Afrique, avec des bureaux à Dubaï,
Paris et Sousse. Avec ses différentes entités Proxym-IT, Proxym France, Proxym ME et Apptiv-
IT situées en France, au Royaume-Uni, au Moyen-Orient et en Tunisie, le groupe est considéré
comme leader dans le secteur IT notamment les solutions convergentes autour du Web, Mobile
et Systèmes d’information. « PROXYM Group » fut sélectionnée parmi les 100 business
partenaires les plus innovants d’IBM.

Ses valeurs qui sont construites autour de l'indépendance, le goût du challenge, l'exigence,
l’esprit d'équipe, la transparence et le sens de l'éthique ont permis de construire des équipes
expérimentées, innovantes et multilingues, dotées d'expertises techniques diversifiées. Jusqu’à
maintenant, elle compte plus de 170 ingénieurs passionnés qui ont numérisé avec succès plus
de 400 projets et fourni plus de 200 applications mobiles à des clients de divers secteurs et
tailles.

Notre stage s’est déroulé au sein de « Proxym-IT » :

Tableau 1-1 : Identité Proxym-IT

Raison social : Proxym-IT

Secteur d’activité : Développement des nouvelles technologies de l’information et de la
communication
Propriétaire : Mr Berrayana Wassel
Date de création : 04 / 01 / 2006
Catégorie : Société privée étrangère
Implantation : Sousse (Tunisie) / Paris (France)
Adresse : Technopole de Sousse BP 184 Sousse Khezama TN 4051, Avenue Khezama,
Sousse
Téléphone : +216 73 82 12 22 / +334 34 08 02 48
Email : [email protected]
Site web : www.proxym-it.com

Page 4 sur 116

Chapitre 1. Cadre Général Du Projet

Figure 1-1 : Logo du Proxym-IT

1.1.2 Activités de base et savoir-faire

• Mobilité et Iot
• Applications commerciales web
• Conseil et support en m & e-commerce
• Soutien technologique aux acteurs de la santé
• Intégration des solutions IBM
• Edition d’applications mobiles pour les entreprises

1.1.3 Départements et équipes

Figure 1-2 : Organigramme de Proxym Group

• Direction générale : La société Proxym-IT est gérée par M. Wassel Berrayana, un ancien
responsable qualité de Sun Microsystems, qui cumule les fonctions du chef de projet et
de directeur exécutif.

• Le service administratif et financier : S’occupe de l'administration des opérations

financières de Proxym-IT et de la gestion des affaires administratives et financières des
employés.

• Le département ESS : Spécialisé dans la réalisation des applications d'entreprise telles

que les sites d’entreprise, personnels, portails, intranets, extranets via les technologies :
.NET, SpringBoot, ERP et Java JEE ... Ainsi que les applications mobiles hybride.

Page 5 sur 116

Chapitre 1. Cadre Général Du Projet

• Le département Mobile : S’engage à la réalisation des applications logicielles pour les

appareils mobiles servant dans différents domaines, tels que la gestion des réseaux, la
gestion des paiements mobiles, la gestion bancaire et la géolocalisation via les
technologies : iPhone, Android.

• Le département E-business : Intervient dans la réalisation d'applications Web 2.0, et des

boutiques E-Commerce et des sites web via des technologies et des plateformes
avancées telles que Magento, Drupal, Word-Press, Symphony et Angular...

• Le département TGO (Technical Governance Office) : Se charge de l’expertise

technique dans toutes sortes de projets grâce à une équipe d’experts qui est composé
principalement par des architectes de domaine.

Notre projet est réalisé au département Mobile.

1.2 Présentation du contexte du projet

Il n’est plus à démontrer que la révolution du numérique a touché l’économie avec tous ses
secteurs primaire, secondaire et tertiaire. Dans le secteur commercial, les consommateurs
utilisent de plus en plus le commerce en ligne, connu sous le nom de e-commerce. Les
consommateurs maîtrisent l’usage du système de catalogue en ligne, de panier et de module de
gestion des commandes, l’achat en ligne est beaucoup plus simple, facile et rapide pour eux que
l’achat naturel. Ce secteur est en plein essor et tire bénéfice de la forte croissance d’utilisation
des appareils mobiles. Dans ce sens, de multiples innovations technologiques telle que la réalité
augmentée, permettant l’essayage et la simulation, se basent sur des processus qui se veulent
de plus en plus fluides sur téléphone et profitent d’une expérience client répondant de mieux en
mieux aux attentes du consommateur connecté et la devançant même. Les deux paragraphes
qui suivent vont appuyer l’opportunité et l’intérêt de notre projet d’un point de vue économique
et d’un point de vue accès à la dernière innovation technologique.

1.2.1 M-Commerce en chiffre

Partant d’une enquête réalisée par la FEVAD 1 [2] et le CSA2 [3] le 5 février 2019 sur
les perspectives d’achats sur Internet et qui a comme titre « Le M-commerce prend de plus en
plus d’ampleur » [4]. Nous constatons que : 39% des e-acheteurs et 56% des jeunes de moins
de 35 ans achètent en ligne depuis leur smartphone, un score en hausse de 7 points depuis 2018
et de 15 points depuis 2017.

FEVAD affirme que le M-Commerce a progressé de 38% en 2017, contre 14,3% pour
le E-Commerce. La fédération estime que, sur l'ensemble du marché, plus de 20% des ventes
ont été réalisées sur smartphones et tablettes. Pendant ce temps, les ventes sur ordinateur
poursuivent une baisse amorcée depuis 2014.

Dans le même contexte Médiamétrie3 [5] affirme que les usages sur Internet favorisent
la bascule vers le mobile et les produits les plus achetés sur mobile en 2018 sont [6] :

1
FEVAD : Fédération du e-commerce et de la vente à distance.
2
CSA : Conseil Supérieur de l’Audiovisuel.
3
Médiamétrie : Société anonyme spécialisée dans la mesure d'audience et l'étude des usages des médias
audiovisuels et numériques.

Page 6 sur 116

Chapitre 1. Cadre Général Du Projet

• Habillement : 14%
• Beauté – Santé : 10%
• Voyage – tourisme : 9%
• Produits techniques : 9%
• Jeux – Jouets : 9%
• Alimentation : 9%
• Univers maison 8%

C’est dans ce contexte que s’intègre notre projet, nous visons améliorer l’expérience
utilisateur dans le domaine du M-Commerce (Mobile Commerce) plus précisément dédié à
l’univers maison en intégrant la technologie de la réalité augmentée pour l’offre d’essai de
meubles sur des surfaces réelles.

1.2.2 Réalité augmentée

Tous les experts s’entendent sur un point, la personnalisation de l’offre et du service est
l’avenir du commerce et le mobile a un rôle très important à jouer dans cette personnalisation
[7]. Outre, l’offre qui doit répondre aux besoins des clients, les services doivent également
s’adapter pour proposer une expérience client la plus riche possible. L’exemple le plus
marquant de personnalisation de l’expérience client offert par le mobile c’est la technologie de
réalité augmentée. Nous nous se demandons alors qu’est-ce que la réalité augmentée ?

1.2.2.1 Définition

Sachant que la « Réalité augmentée » est considérée comme le maitre d’ouvrage de notre
application, nous proposons de la définir en relevant la confusion qui gravite autour d’elle. Il
ne faut pas la confondre avec les termes de « Réalité virtuelle » et de « Réalité mixte ». Ces
trois termes sont définis comme suit [8] :

• Réalité virtuelle (VR) : Exclut le monde physique et plonge les utilisateurs dans
un environnement numérique totalement artificiel ou imaginaire à l'aide
d'appareils dédiées tels que « HTC Vive », « Oculus Rift » ou « Google
Cardboard ».

• Réalité augmentée (AR) : Permet d’insérer, au moyen d’un appareil photo sur un
smartphone, et de façon très réaliste, un objet virtuel dans un environnement réel
en utilisant des coordonnées spatiales bien précises qui permettent la persistance
géométrique en ce qui concerne le placement et l'orientation dans le monde réel.

• Réalité mixte (MR) : Combine des éléments de réalité virtuelle et de réalité

augmentée et permet à l'utilisateur d'interagir avec des objets combinés virtuels /
réels. La technologie de réalité mixte commence tout juste à prendre son envol
avec l’appareil « HoloLens » de Microsoft.

1.2.2.2 Historique et domaines d’application

Le premier système de réalité augmentée fut conçu en 1968 dans le cadre des recherches
qui ont posé les bases de la réalité augmentée, mais il faudra attendre les années 90 pour que le

Page 7 sur 116

Chapitre 1. Cadre Général Du Projet

terme « réalité augmentée » soit évoqué [9]. L’arrivée des Smartphones et Tablettes à la fin des
années 90 : appareil photo, écran et informatique embarquée ont permis le développement des
projets réellement mobiles et pertinents basés sur la réalité augmentée, mais il s’agissait plus
de projets expérimentaux que des outils réels destinés au grand public.

La technologie de réalité augmentée a connu un bouleversement majeur et devenue

facilement comprise par le grand public en 2016. Cette avancée technologique est issue de deux
géants américains : Apple et Google, qui ont développé de nouveaux systèmes de réalité
augmentée embarqués directement dans le système d’exploitation des smartphones et tablettes
nommés respectivement « ARKit » pour Apple et « ARCore » pour Google. Par conséquent,
la réalité augmenté est devenue un champ d’application dans des différents domaines tels que :

• Les jeux vidéos

• L’industrie
• Le commerce électronique
• L’immobilier
• Les musées

1.3 Présentation du projet

Ce projet rentre dans le cadre du projet de fin d'études qui vient de conclure notre formation
d'ingénieur. L'application demandée s'intitule « HomeShop ». Elle a pour objectif le
développement d’une application mobile sous la plateforme iOS basée sur ARKit, elle
représente un store virtuel de meuble de maison.

1.3.1 Problématique et étude de l’existant

1.3.1.1 Problématique

Figure 1-3 : Images descriptives du Problématique

Qui parmi nous n’as pas passé du temps à prendre des mesures à chaque fois qu’il a
besoin d’acheter un nouveau meuble ? Qui n’a pas rencontré des difficultés de choix des
meubles et même parfois regretté ses choix après l’achat ?…

Il serait fantastique de tester les différents meubles pour décider qui est le plus
convenable à leurs locaux sans prendre de mesures, sans se déplacer, sans porter des poids
lourds, en étant allongé sur sa chaise longue et de manière ludique.

Page 8 sur 116

Chapitre 1. Cadre Général Du Projet

1.3.1.2 Étude de l’existant

En Tunisie, Les fournisseurs de meubles les plus connus n’offrent pas à leurs
consommateurs l’opportunité de tester les différents meubles, ni physiquement, ni
virtuellement, avant la procédure d’achat. D’ailleurs la nature du produit, contrairement à
l’habillement, ne s’apprête à aucune forme de test ou d’essai ! On cite par exemple
« Meublatex » et « Graït » :

Figure 1-4 : Logo Meublatex Figure 1-5 : Logo Graït

Alors qu’ailleurs, quelques applications tels que « IKEA Place » et « Wayfair » ont été
réalisées dans le but de remédier à ce manque de confort et booster le processus d’achat des
meubles en ligne en offrant aux consommateurs la possibilité de visualisation et de test des
meubles en réalité augmentée.

Figure 1-6 : Logo Ikea Places Figure 1-7 : Logo Wayfair

Mais, malheureusement ces applications ne sont pas accessible en Tunisie!

Le terrain est donc totalement vierge et l’occasion est fortement propice pour développer
une première application tunisienne de e-commerce basée sur la réalité augmentée permettant
de simuler l’ameublement.

1.3.2 Solution proposée

« HomeShop » sera donc une solution M-Commerce basée sur la réalité augmentée
tournant sur la plateforme iOS. Elle représente un store virtuel de meuble maison où l’utilisateur
peut parcourir le catalogue sous forme d’objets modélisés en 3D. Après le choix d’un article,
l’utilisateur peut le placer et le tester directement dans l’endroit où il veut le mettre via la caméra
de son iPhone. Une fois le choix est validé, l’utilisateur peut l’ajouter à son panier pour le passer
en commande, le workflow d’achat en ligne se déclenche alors.

Page 9 sur 116

Chapitre 1. Cadre Général Du Projet

1.4 Méthodologie de travail

Globalement, le projet se compose de deux volets principaux, le premier est le volet de la

réalité augmentée, le deuxième est celui le volet de l’e-Commerce. Dans le détail, ce projet
appelle à la maîtrise et l’intégration de plusieurs technologies considérées présentement de
pointe : le développement mobile, la réalité augmentée, les différentes scénarios de workflow
e-commerce et m-commerce. Ce constat de fait classe d’ores et déjà, notre projet dans le rang
des projets complexes et innovants.

La finalisation du travail en respectant un standard de qualité dans les délais est notre
souci majeur. L’un des problèmes les plus fréquemment affrontés lors du développement de
ce genre de projet, c’est la mauvaise gestion du temps face à l’utilisation d’une technologie
émergeante. Cela peut influencer non seulement le rendement et la vélocité en créant un
environnement de stress, mais aussi la bonne gestion du projet et donc les délais de livraison.

le cadre de processus Scrum de la méthodologie agile répond convenablement à nos

besoins en termes de gestion du temps puisqu’il est entièrement organisé autour de courtes
itérations durées appelées Sprints ce qui simplifie le processus et augmente la productivité.

1.4.1 Framework Scrum

Scrum [10] a été utilisé pour gérer le travail sur des produits complexes depuis le début
des années 1990. Il n'est pas en soi un processus, une technique ou une méthode définitive.
C'est plutôt un framework (cadre de processus) dans lequel nous pouvons utiliser différents
processus et techniques. Scrum met en évidence l'efficacité relative à la gestion de notre produit
et aux techniques de travail afin que nous puissions continuellement améliorer le produit,
l’équipe et l’environnement de travail. Scrum est :

• Léger
• Simple à comprendre
• Difficile à maîtriser

Donc c’est un cadre de travail dans lequel les personnes peuvent aborder des problèmes
complexes et adaptatifs tout en livrant de manière régulière, incrémentale, efficace et créative
des produits de la plus grande valeur possible.

1.4.2 Scrum Rôle, événement et artefacts

Scrum est constitué d’équipes Scrum et leurs rôles, événements, artefacts et règles
associés. Chaque composante de ce cadre a un but précis et est essentielle au succès et à
l’utilisation de Scrum. La figure 1-8 [11] illustre à la fois les différents rôles de Scrum et le
déroulement du processus :

Page 10 sur 116

Chapitre 1. Cadre Général Du Projet

Figure 1-8 : Processus Scrum

1.4.2.1 Rôles

• Product Owner (PO) : « Propriétaire du produit », c’est le représentant des clients et

des utilisateurs. Son rôle est d'assurer la présentation des caractéristiques et des
fonctionnalités du produit à développer et l’approbation du produit à livrer. Nous
jouerons ce rôle à plusieurs occasions notamment à l’occasion de la préparation et
priorisation du Backlog Product. D’ailleurs le présent chapitre et le chapitre suivant
exposent une grande partie du travail de cet intervenant important dans Scrum.

• Scrum Master (SM) : « Leader-serviteur de l'équipe Scrum », il assure globalement la

supervision de l'avancement du projet et des activités de l'équipe. Il veille à écarter et
résoudre tout type de problème que rencontre la Dev Team. Il assure également
l'organisation, la tenue et le timing des réunions. Il est le garant de la rigueur de
l’application du processus Scrum dans l’entreprise pour la maximisation de la valeur.

• Dev Team : « Équipe de développement », Les développeurs chargés de la construction

du logiciel et d'en faire une démonstration. Selon le Scrum Guide [12], une équipe
comporte au minimum trois personnes et au maximum neuf personnes de compétences
variées complémentaires qui se chargent de la réalisation des « User Stories » et de
l’élaboration des sprints. C’est en majeure partie le rôle que je jouerai.

En guise de récapitulatif des rôles Scrum et comment ils seront répartis au cours du
guidage de mon projet « HomeShop », Salmene NOUIRE jouera le rôle du PO, Dhekra
ROUATBI jouera le rôle du SM et la DevTeam sera limitée à une seule personne qui est
moi-même Bouthaina GHACHEM. En tant qu’étudiante stagiaire encore en phase
d’apprentissage je profiterai pour jouer le rôle tantôt d’un SM, tantôt d’un PO et tantôt d’une
Dev Team composée de diverses compétences.

Page 11 sur 116

Chapitre 1. Cadre Général Du Projet

1.4.2.2 Artefacts

• Product Backlog (PB) : tout le travail est décrit par le Backlog. En effet, tout le projet
est découpé en un ensemble de « User Stories » classés par priorité́ et listés dans le
Backlog. Le backlog de « HomeShop » sera présenté dans les page 19 et 20.

• Sprint Backlog (SB) : une sélection de tâches retenues du « Product Backlog » pour
construire l'objectif du sprint.

1.4.2.3 Évènements

Sur le terrain pratique du cadre de processus Scrum nous faisons recours à ces termes que
nous devons savoir d’avance :

• Sprint : C’est le cœur de Scrum, une durée d'un mois ou moins au cours de laquelle un
incrément Produit fonctionnel est créé. Un nouveau Sprint commence immédiatement
après la conclusion du Sprint précédent.

• Sprint Planning meeting : « Réunion de Planification du Sprint », réalisée par tous les
membres de l'équipe Scrum pour définir le travail à effectuer durant chaque Sprint. Elle
dure au maximum huit heures pour un Sprint d'un mois.

• Daily Meeting : c'est un point quotidien qui permet de mettre le point sur ce qui a été
réalisé ,les problèmes rencontrés et les objectifs de la journée.

• Sprint Review : « Revue de Sprint », est tenue à la fin du Sprint pour inspecter
l’incrément réalisé et adapter le Backlog Produit si nécessaire. Pendant la revue de
Sprint, l'équipe Scrum et les parties prenantes contrôlent la qualité du produit en
échangeant sur ce qui a été fait durant le Sprint.

• Sprint Retrospective : « Rétrospective de Sprint », une réunion produite après la revue

de sprint et avant la prochaine réunion de planification du Sprint. Elle représente une
opportunité pour l'équipe Scrum de contrôler la qualité du processus Scrum afin de
s’auto-inspecter et de créer un plan d'améliorations à adopter au cours du prochain
Sprint.

Conclusion
A travers ce chapitre, nous avons présenté la société PROXYM-GROUP à travers ses
activités et son organisation interne. Dans un second lieu, nous avons décrit le contexte du
projet en avançant des chiffres et statistiques afin de sensibiliser à son importance et souligner
sa grande Business Value pour PROXYM-GROUP ou toute entreprise œuvrant dans le
domaine de l’IT. Puis nous avons détaillé la problématique et estimé les degrés de difficulté en
vue de cerner la méthode, les technologies et les compétences nécessaires au développement et
de là envisager une solution.

Le deuxième chapitre nous permettra d’entamer la phase d'initialisation du projet.

Page 12 sur 116

 Chapitre 2

2 Lancement Du Projet « HomeShop »

Plan

Introduction...................................................................................................................................... 14
2.1 Architecture de la solution ................................................................................................. 14
2.2 Analyse et Spécification des besoins .................................................................................. 16
2.3 Product Backlog .................................................................................................................. 18
2.4 Pratique de principes de Scrum ........................................................................................ 23
2.5 Environnements de travail ................................................................................................. 24
Conclusion ........................................................................................................................................ 25
Chapitre 2 . Lancement Du Projet « HomeShop »

Introduction

Ce chapitre tente d’aborder la phase d’analyse du projet. Il est le résultat du travail du

Product Owner (PO) avant de venir rencontrer sa Dev Team et lui présenter le produit. Nous y
allons tout d'abord, présenter l’architecture la plus adaptée à la nature du produit. Nous allons
ensuite identifier ses besoins fonctionnels et non fonctionnels pour ensuite présenter le Product
Backlog et la planification des sprints nécessaires. Enfin, nous allons clôturer ce chapitre par la
spécification des différents environnements matériels, logiciels les mieux adaptés pour le
produit visé et souhaités par le client.

2.1 Architecture de la solution

2.1.1 Architecture physique

« HomeShop » est une application mobile iPhone iOS de e-commerce qui offre une
simulation 3D d’ameublement d’une surface et permet de remplir un caddy puis le transformer
en commande. Avant de se plonger dans sa conception et développement une architecture trois-
tiers s’apprête parfaitement pour bâtir sa structure. Ce modèle d’architecture se compose de
trois composantes fondamentales qui facilitent la récupération des données situées au niveau de
la base de données.

Figure 2-1: Architecture physique de « HomeShop »

Chacune de ces composantes a un rôle spécifique:

• Un client : Appareil mobile (IPhone) permet à son utilisateur d'accéder à l'application,

lui affiche les données, collecte les informations qu'il saisit et valide ses actions.
• Un middle tiers : Serveur d'application qui héberge toutes les couches de l'application
à développer.
• Un tiers de données : Serveur de base de données. Il permet de fournir au serveur
d'application les données dont il a besoin et d’enregistrer ses données sur un support
physique.

Page 14 sur 116

Chapitre 2 . Lancement Du Projet « HomeShop »

Cette architecture n’apparait pas totalement détaillée pour le moment car elle sera
construite au fur et à mesure durant l’avancement dans les Sprints par l’intégration des
différents incréments potentiellement livrables.

2.1.2 Architecture logique

Notre projet « HomeShop » est une application mobile sous la plateforme iOS, toutefois,
et selon Apple, l’architecture MVC traditionnel ne semble pas être applicable au développement
iOS moderne. Pour cette raison, Apple a inventé une autre vision sur MVC [13] qui est
conforme à ses besoins.

Avant de discuter de la vision MVC d’Apple, jetons un coup d’œil sur la vision
traditionnelle. Le concept de base est la séparation des données (modèle), de l'affichage (vue)
et des actions (contrôleur) comme le montre la figure 2-2 [13]:

Figure 2-2 : Architecture MVC traditionnelle

Du point de vue Apple, « View » et « Controller » sont tellement juxtaposés qu’il est
difficile de dire qu’ils sont séparés. On parle d’un fort couplage « View & Controller » et une
séparation complète de la partie « Model » comme le montre la figure 2-3 [13]:

Figure 2-3 : Apple MVC « Cocoa MVC »

Dans ce cas, la responsabilité de la vue est d’envoyer des actions. au contrôleur. Le

contrôleur de vue finit par être un intermédiaire pour récupérer les informations du modèle, les
traiter en fonction des paramètres demandés par la vue, puis de mettre à jour la vue avec les
données reçues.

Les avantages apportés par l'architecture MVC sont :

✓ Une indépendance des données, de l'affichage et des actions, ce qui donne plus de
souplesse pour la maintenabilité et l'évolutivité du système.

Page 15 sur 116

Chapitre 2 . Lancement Du Projet « HomeShop »

✓ La moindre quantité de code parmi d'autres modèles. De plus, tout le monde le connaît
bien, il est donc facile à entretenir.
✓ Un gain de temps de maintenance et d'évolution de l'application.

C'est à cet effet que nous optons pour le modèle MVC qui sera également très pratique
pour gérer l'interaction entre les différents composants de notre application iOS « HomeShop ».

2.2 Analyse et Spécification des besoins de « HomeShop »

2.2.1 Identification des acteurs

Un acteur est une personne ou un autre système informatique qui attend un ou plusieurs
services offerts par l'application « HomeShop ». Il interagit avec le système par envoi ou
réception des messages. Pour « HomeShop » nous distinguons principalement les deux acteurs
suivants :

Visiteur : Un utilisateur qui peut exécuter toute les fonctionnalités de l’application sauf
le processus du passage d’une commande, le workflow de paiement et l’accès au profil
utilisateur puisqu’il ne dispose pas d’un compte.

Client (Visiteur dispose d’un compte) : Un utilisateur qui dispose d’un accès complet à
toutes les fonctionnalités de l’application puisqu’il dispose d’un compte utilisateur.

Un visiteur une fois inscrit dans l’application, il aura accès un son compte et devient un
client. Un client est à l’origine un visiteur.

2.2.2 Diagramme de contexte

Le diagramme de contexte montre le système comme étant une « boîte noire ». Il délimite le
domaine d’étude en précisant ce qui est à la charge du système et en identifiant l’environnement
extérieur au système étudié avec lequel ce dernier communique. Cette « boîte noire » sera donc
utile à un ou plusieurs utilisateurs comme il est présenté dans la figure 2-4 :

Figure 2-4 : Diagramme de Contexte

Page 16 sur 116

Chapitre 2 . Lancement Du Projet « HomeShop »

2.2.3 Identification des besoins

L'identification des besoins consiste à traduire les objectifs du projet en un ensemble de

fonctionnalités ciblées par l'outil à réaliser. Ceci procurera une compréhension plus approfondie
des tâches à mettre en œuvre.

2.2.3.1 Besoins fonctionnels

Il est commode pour une application iOS de décrire les fonctionnalités souhaitées en les
ventilant sur les écrans qui constitueront l’application entière. Chaque écran de notre
application mobile remplit une ou plusieurs fonctions particulières, nous les présentons donc
écran par écran comme suit :

Écran d’Accueil :

- Accès aux articles par catégorie

- Accès à la technologie (AR) pour tester les articles en monde réel
- Recherche par mot clé ou par filtre
- Accès aux promotions et offres spéciales.
Scène de test avec la réalité augmentée (AR) :

- Accès et test des articles 3D dans le monde réel

- Prise de photos de la scène et enregistrement dans la galerie du téléphone.
Écran de gestion de panier :

- Accès au contenu du panier.

- Modification de la quantité des articles sélectionnés.
- Suppression d’un un article.
- Passage d’une commande et payement une fois connecté à un compte.
Écran de gestion des favoris :

- Accès aux articles souhaités choisis précédemment.

Écran Comptes et profils :

- Accès aux paramètres du compte.

- Consultation de l’historique des commandes passées auparavant ainsi que leur état
actuel.
2.2.3.2 Besoins non fonctionnels

Ce sont les besoins qui permettent d’assurer la qualité des services de l’application comme
:
• L’utilisabilité

L’utilisateur aura accès à l’application à travers des Smartphone de type iPhone au format
portrait. L’application est dédiée à tous usager d’un smart phone et qui maîtrise la manipulation
de son écran.

Page 17 sur 116

Chapitre 2 . Lancement Du Projet « HomeShop »

• La compatibilité

Les systèmes d’exploitation et les Smartphone évoluent très vite. Selon Apple, pour assurer
le fonctionnement de la technologie de la réalité augmenté, les appareils iOS doivent avoir une
puce A9, A10, A11 ou A12 Bionic.
Les dispositifs utilisant les puces A9, A10 et A11 sont:
▪ iPhone 6s et 6s Plus
▪ iPhone 7 et 7 Plus
▪ iPhone SE
▪ iPad Pro (9,7, 10,5 ou 12,9) - première et deuxième génération
▪ iPad (2017)
▪ iPhone 8 et 8 Plus
▪ iPhone X, iPhone XR , iPhone Xs, iPhone Xs Max.
Alors, à peu près tous les modèles d'iPhone à partir d'iPhone 6s et supérieurs seront pris en
charge, de même que l'iPhone SE. Tous les iPad Pro et le modèle iPad standard 2017 actuel
seront également pris en charge, ce qui signifie que la dernière série d'iPad, à l'exception de
l'iPad mini, compatible également avec la technologie AR.

• La sécurité

La solution doit respecter la confidentialité des données personnelles des clients. De plus,
elle doit assurer la sécurité des transactions en ligne. Afin de garantir ceci, notre application
utilisera :
- Un processus d’authentification pour chaque utilisateur afin d’accéder à ses données
personnelles
- API de paiement en ligne : lors du processus du paiement aucun détail de la carte ne
doit touchera l’application. Au lieu de cela, les données doivent être transmises de
manière sécurisée via HTTPS de l’appareil du client à l'API utilisé, qui doit être
conforme au deuxième niveau de PCI DSS 4. À partir de là, et en fonction de la
passerelle de paiement spécifique, l'application envoie ces données de manière
transparente à la passerelle de paiement choisie.

• Le temps de réponse

L’application doit être fiable et exacte en termes de résultats fournis. L’exactitude et la

rapidité de temps de réponse doivent être prises en compte de manière que la navigation soit
fluide entre les écrans et les catalogues en 3D afin de ne pas frustrer l’utilisateur et le faire fuir.

2.3 Product Backlog

Une fois l’analyse des besoins est entamée, nous les transformons en ce qu’on appelle
des « User Stories » qui seront détaillé dans le « Product Backlog ». Chaque « User Stroy »
permet de décrire avec suffisamment de précision le contenu d'une fonctionnalité à développer.

4
Payment Card Industry Data Security Standard : Un standard de sécurité des données pour les principaux
groupes de cartes de paiement.

Page 18 sur 116

Chapitre 2 . Lancement Du Projet « HomeShop »

À ce niveau, en tant que PO nous devons alors nous demander par quoi commencer ?
et pourquoi une user story est plus prioritaire qu’une autre ?

2.3.1 Technique de priorisation du PB

En fait, la priorisation du Product Backlog est une tâche très importante et afin de la
faire convenablement, il faut spécifier des critères et une méthode de priorisation.

Généralement, la notion la plus adoptée c’est le « Bénéfice attendu » d’une « User

Story », néanmoins cette notion est souvent très vague ou tellement évidente qu’elle ne permet
pas une priorisation efficace. A ce niveau apparait en clair la nécessité pour un framework tel
que Scrum, de recourir à d’autres méthodes et/ou techniques externes déjà confirmées dans le
domaine des TIC et de l’industrie du logiciel pour le compléter. Les normes sur lesquelles nous
nous baserons pour prioriser notre Product backlog sont les suivantes :

• Le « Business Value » : La valeur ajoutée au client en lui ramenant un maximum de

confort et convivialité. La priorisation des fonctionnalités qui permettent d’augmenter
la valeur de notre produit.

• Le « Risk Minimizing » : Prioriser les fonctionnalités les plus compliquées et qui

nécessitent le maximum de travail ou d’auto formation, afin de ne pas tomber dans le
cas où le client remet en question les capacités de l’équipe.

« MoSCoW » [14] est l’une des techniques souvent empruntée sur le terrain par les entreprises
pour prioriser le Product Backlog. Elle consiste à juger de l’importance d’un Product Backlog
Item (PBI : un constituant du BP) pour le profit du client et l’entreprise de développement.
Nous la retenons pour prioriser notre PB :

▪ Mo - Must have : doit être réalisée.

▪ S - Should have : devrait être réalisée si possible.
▪ Co - Could have : pourrait être réalisée s’il n’y a pas d’impact sur les autres
tâches en cours.
▪ W - Would have : ne sera pas réalisée tout de suite mais serait souhaitable pour
une version ultérieure.

2.3.2 Product Backlog priorisé

L’étude de priorisation détaillé dans le paragraphe qui précède a donné comme résultat
le tableau 2.1, qui illustre la liste des « User Story » » ainsi que leurs priorités estimées par
ordre de fonctionnalité pour chaque écran de l’application :

Tableau 2-1 : Product Backlog priorisé

ID Feature/Epic User Story Priority

En tant que visiteur, je veux interagir

avec des modèles 3D réalistes, afin de
Préparation de base de
1 pouvoir vivre une véritable Must
données et API REST
expérience de RA et meubler une
pièce dans ma maison.

Page 19 sur 116

Chapitre 2 . Lancement Du Projet « HomeShop »

En tant que visiteur, je veux accéder

au catalogue en ligne, afin de voir les Must
détails des produits.
En tant que visiteur, je veux consulter
les différentes catégories disponibles,
Must
afin d’accéder aux articles par
catégorie.
En tant que visiteur, je veux chercher
2 Écran d’accueil
et filtrer les articles, afin de trouver ce Should
que je veux plus rapidement.
En tant que visiteur, je veux voir les
articles en promotion, afin de profiter Could
de l'occasion.
En tant que visiteur, je veux accéder à
une scène RA, afin d’essayer les
articles dans le monde réel en utilisant Must
la technologie de la réalité
augmentée.
En tant que visiteur, je veux ajouter à
mon panier tous les articles que j'ai Must
testés
En tant que visiteur, je veux prendre
Scène de test avec la des photos pour ma scène de test, afin
3 Must
réalité augmentée de les consulter ultérieurement de ma
galerie et me décider pour l’achat.
En tant que client, je souhaite ajouter
des produits à ma liste de favoris, afin Should
de pouvoir les commander plus tard.
En tant que visiteur, je veux accéder à
la scène de RA avec l'option
d'adaptation de plan afin de pouvoir Could
tester l'adaptabilité des modèles dans
le plan détecté.
En tant que visiteur, je veux
m’inscrire dans l'application, afin Must
d’effectuer des achats en ligne.
4 Écran Comptes et profils
En tant que client, je veux accéder à
mon profil, afin de pouvoir modifier Must
mes coordonnées.
En tant que visiteur, je veux accéder à
Écran de gestion de
5 mon panier, afin de modifier des Must
panier
quantités et/ou supprimer un article.
En tant que client, je veux passer des
Processus de passage du
6 commandes, afin que mes Must
Commande
commandes puissent être expédiées.
En tant que client, je veux voir toutes
Écran d’historique des
7 mes commandes, afin de suivre leurs Should
commandes
états.
En tant que client, je veux accéder à
Écran de gestion des mes favoris, afin de les consulter,
8 Could
favoris supprimer un article ou ajouter des
articles au panier.
En tant que visiteur, je veux accéder à
l’ensemble des articles, afin de
9 Écran des articles variés Could
sélectionner les produits que je
souhaite tester en RA.
En tant que client, je veux avoir accès
aux des différentes méthodes de
10 Processus de paiement Would
payement, afin de payer ma
commande.

Page 20 sur 116

Chapitre 2 . Lancement Du Projet « HomeShop »

En proposant ce Product Backlog, nous voulions être véridiques en calquant ce qui se

passe réellement sur le terrain dans les entreprises Agiles. Qu’il fasse ou non la totalité de notre
tâche à accomplir en cours de stage n’est qu’un fait dérisoire ! L’important est de livrer le client
à très courtes durées successives et répétitives (les sprints) jusqu’à aboutir à une première
release (version) du produit en garantissant sa satisfaction. Pour notre cas, la release de
« HomeShop » devra être livrée après les quatre mois de notre stage. Nous nous permettons
alors dans ce qui vient, de planifier notre Release « HomeShop ».

2.3.3 Transposition du PB en diagramme de cas d’utilisation général

Scrum est un cadre de processus, ceci veut dire qu’au besoin et pour son enrichissement
il peut accueillir des formalismes, des conseils de bonnes pratiques et des techniques de toutes
autres méthodes. Nous sommes au besoin actuellement de transposer notre « Product Backlog
» su-présenté en diagramme de cas d’utilisation global en ayant recours au le langage unifié et
universel de modélisation UML afin de faciliter sa compréhension :

Page 21 sur 116

Chapitre 2 . Lancement Du Projet « HomeShop »

Figure 2-5: Diagramme de cas d'utilisation global

Page 22 sur 116

Chapitre 2 . Lancement Du Projet « HomeShop »

2.4 Pratique de principes Scrum

2.4.1 Établissement de la « Definition of Done »

La « Definition of Done » (DoD) est un des artefacts importants de Scrum, c’est un

ensemble de critères de qualité connus dans le domaine du Génie Logiciel. Elle sert à maximiser
la transparence et la compréhension de ce qu’est un travail bien achevé par chacun des membres
de l’équipe Scrum. La DoD diffère d’une entreprise à une autre selon le standard de qualité
qu’elle se pose. Il est donc important que tout le monde participe dans sa définition : Scrum
master, Product Owner, développeurs et testeurs... Dans notre cas, puisqu’il s’agit d’un projet
de fin d’étude où nous devons acquérir un maximum de bonnes pratiques, nous avons établi à
l’aide de notre Scrum Master et Product Owner la « Definition of Done » ci-dessous:

DoD
Analysé
Conçu
Codé
Testé
Réfactoré
Intégré
Documenté

Selon Scrum Guide [15] : « au fur et à mesure que l’équipe Scrum prendra de la maturité,
on s’attend à ce que leur DoD s’étende progressivement pour inclure des critères plus rigoureux,
permettant un niveau de qualité plus élevé ».

2.4.2 Planification des sprints du projet « HomeShop »

Généralement, cette étape ne s’effectue pas à ce stade, elle s’effectue pendant le

lancement de chaque « Sprint » dans une réunion spécifique que nous avons déjà mentionnée
dans le premier chapitre « Sprint Planning Meeting ». Mais vu que nous sommes limité par des
contraintes du temps et une période de stage bien précise, nous nous sommes permis de planifier
les sprints d’avance. Nous avons identifié six Sprints qui serviront à atteindre une première
release comme le montre le tableau ci-dessous :

Page 23 sur 116

Chapitre 2 . Lancement Du Projet « HomeShop »

Tableau 2-2 : Planification des Sprints

Release Sprint Objectif du Sprint Période

Préparer la base de données

Sprint 1 05/02 – 01/03
et API REST

Sprint 2 Développer l’écran d’accueil 04/03 – 15/03

Développer la Scène de test

Sprint 3 18/03 – 19/04
avec la réalité augmentée
Release 1
Développer l’écran de
Sprint 4 06/05 – 17/05
gestion du panier

Développer les écrans des

Sprint 5 22/04 – 03/05
Comptes et profils

Développer le Processus de
Sprint 6 20/05 – 31/05
passage de Commande et
l’écran de l’historique

Les « Users Stories » que nous n’avons pas incluses forment l’objet d’une deuxième
release que Proxym-IT prendra la relève de poursuivre.

2.5 Environnements de travail

Dans cette partie, nous présenterons l'environnement matériel et technique relatif à la

réalisation de l'application.

2.5.1 Environnement matériel

Durant la réalisation du présent travail, nous avons utilisé d'un ordinateur « MacBook
Pro » qui a les caractéristiques suivantes :

Tableau 2-3 : Caractéristiques de l'ordinateur

Nom MacBook Pro (Retina, 13-inch, Late 2013)

Processeur Intel Core i7
Mémoire vive (RAM) 16 Go
Carte graphique AMD Radeon R9
Disque dur 1 To
Système d’exploitation MacOs Mojave

Page 24 sur 116

Chapitre 2 . Lancement Du Projet « HomeShop »

Nous avons aussi utilisé un téléphone mobile iPhone pour simuler et tester le
comportement de l’application et s’assurer de son bon fonctionnement. L’iPhone dispose des
caractéristiques suivantes :

Tableau 2-4 : Caractéristiques du smartphone

Modèle iPhone SE
Processeur Apple A9, 1.86 GHz
Mémoire vive (RAM) 1 Go
Écran 4 pouces
OS iOS 11.4

2.5.2 Environnement technique

Dans cette partie, nous allons présenter les différents outils de développement et le
langage de programmation que nous avons utilisé pour la réalisation de notre application :

• XCode

Un environnement de développement intégré (IDE) de

Apple qui fournit aux développeurs les outils nécessaires
pour créer des applications pour les plateformes iOS,
macOS, tvOS et watchOS.

• Swift

Un langage de programmation compilé multi-

paradigmes développé par la société Apple. Il est destiné
à la programmation d'applications sur les systèmes
d'exploitation iOS, macOS, watchOS et tvOS.

Conclusion

Ce chapitre nous a permis de bien délimiter le périmètre du projet et d'avoir une vision
plus claire du sujet. Nous avons décrit l'architecture physique, logicielle de l’application visée,
les besoins fonctionnels, non fonctionnels, les acteurs et le Product Backlog. Par la suite, nous
avons planifié et organisé le temps consacré à la réalisation du projet en identifiant les sprints.
Enfin nous avons présenté l'environnement de développement.

Dans les chapitres suivants, nous allons illustrer la réalisation du première release et nous
allons entamer le volet de conception de ces différents sprints. Il est bien clair que les cas
d’utilisation qui constituent le cœur de notre application sont : « Test des objets dans le monde
réel via la caméra » et « Processus de passage du commande » d’ailleurs c’est pour cela qu’en
jouant le rôle du PO je les ai valorisés et hautement priorisés dans le Product Backlog. Il y a
lieu de préciser aussi que nous procèderont à leurs descriptions textuelles détaillées en dehors
des autres.

Page 25 sur 116

 Chapitre 3

3 Sprint 1 : Préparation de la Base de

Données et de l’API REST

Plan

Introduction...................................................................................................................................... 27
3.1 HomeShop Sprint 1 planning ............................................................................................ 27
3.2 Analyse ................................................................................................................................. 28
3.3 Conception ........................................................................................................................... 30
3.4 Réalisation ........................................................................................................................... 31
Conclusion ........................................................................................................................................ 34
Chapitre 3 . Sprint 1 : Préparation de la Bases de Données et API REST

Introduction

Ce Chapitre fait l’objet d’une présentation du premier Sprint du projet qui est la création
d’une base de données et le développement d’une API REST. L'étude de chaque Sprint couvre
l'analyse, la conception et la réalisation. Ce Sprint est spécifique comparant aux autres puisqu’il
inclut une partie de travail basée sur des « technical stories » nécessaire pour commencer le
développement, de ce fait la structure de ce Sprint va être différente des autres Sprints. En outre,
ce Sprint ne comportera pas un incrément qui touche la partie frontale de l’application mais
plutôt la partie du back-end.

3.1 HomeShop Sprint 1 planning

Cette partie est primordiale pour chaque Sprint. Selon le Scrum Guide, le travail à
effectuer durant le sprint 1 est défini durant la réunion du « Sprint Planning ». Il s’effectue
d’une manière collaborative par tous les membres de l'équipe Scrum et dure au maximum huit
heures pour un Sprint d'un mois. Cette réunion a pour objectif de définir le périmètre
fonctionnel du Sprint, faire sa planification et aussi un peu de conception le tout dans une totale
concertation.

3.1.1 Objectif du sprint 1

Ce sprint a pour objectif de choisir dans un premier lieu une plateforme E-Commerce
en réalisant une étude comparative entre les différentes plateformes disponibles. Dans un
deuxième lieu, afin d’assurer une expérience d’e-commerce et de test des modèles la plus
réaliste possible, il est nécessaire de préparer un back-end qui comporte les différents produits
qui vont être mis en vente dans l’application et leurs équivalent en 3D.

3.1.2 Sprint Backlog du Sprint 1

A ce stade et pour ce premier sprint, nous, en tant que « Dev Team », nous avons
sélectionné à partir du Product Backlog les « User Stories » que nous avons jugé que nous
sommes aptes et capables de développer. Après, nous avons détaillé le plan de travail en « Tasks
» à faire avant la fin du Sprint afin d’arriver à un incrément fini et potentiellement livrable du
produit. Chaque « Task » est caractérisé par son niveau de complexité.

L’estimation de la complexité d’un « Task » peut être faites selon différents méthodes
telles que : « T-Shirts Sizes », « Bucket System » ou « Planning Pocker » [16] ...

Nous avons choisi la méthode de « T-Shirts Sizes », il s’agit d’une technique informelle,
particulièrement adaptée pour traiter rapidement un grand nombre de fonctionnalités. Les
catégories utilisées sont les tailles de t-shirt : XS, S, M, L XL, la catégorie XS va contenir des
activités simples à réaliser, XL contiendra les plus complexes et les plus difficiles. En fin de
« Sprint Planning Meeting » un résultat important est obtenu c’est l’artefact « Sprint Backlog »
dressé dans le tableau 3.1 :

Page 27 sur 116

Chapitre 3 . Sprint 1 : Préparation de la Bases de Données et API REST

Tableau 3-1 : Sprint Backlog du Sprint 1

ID User Story ID Task Task Complexity

Choix de la plateforme E-
En tant que visiteur, je veux accéder
1.1
Commerce M
1 au catalogue en ligne, afin de voir
les détails des produits.. Familiarisation avec la plateforme
1.2
choisie S
Familiarisation avec un outils de
2.1 création graphique et manipulation XL
des objets 3D.
En tant que visiteur, je veux
interagir avec des modèles 3D
2.2 Préparation des objets 3D L
2 réalistes, afin de pouvoir vivre une
véritable expérience de RA et
meubler une pièce dans ma maison.
2.3 Stockage des objets 3D M

Intégration des objets 3D dans

2.4
l’application L

3.2 Analyse

3.2.1 Étude comparative des plateformes de E-Commerce

Les plateformes E-Commerce sont multiples et diverses. Le choix d’une plateforme

n’est pas facile puisque toutes les plateformes sont proches en termes de performances et de
fonctionnalités [17]. Après la réalisation d’une étude détaillée et la consultation de la
documentation offerte par chaque plateforme nous avons pu réaliser le tableau comparatif ci-
dessous :

Tableau 3-2 : Tableau comparatif des plateformes E-Commerce

Support
Support
Plateforme Installation SDK REST API PaaS Client
API
/10
Magento Compliqué JavaScript Oui (en V2) Non Non 7/10

Woo-
Compliqué JavaScript Oui Non Non 7/10
Commerce
JavaScript-
Shopify Moyenne Oui (en V2) Non Oui 10/10
iOS-Android
JavaScript-
Moltin Facile iOS-Android- Oui Oui Oui 10/10
Php-Ruby

À travers ce tableau, nous pouvons conclure que la plateforme « Moltin » est vraiment
conçu pour créer plus facilement des systèmes de commerce électronique sur mesure
puisqu’elle supporte diverses SDK. Nous pouvons certainement avoir recours à « Magento »
ou « Woo-Commerce » et créer un système sur mesure, mais l'inconvénient est que nous ne
disposons pas d'un moyen clair d'ajouter des fonctionnalités, des extensions ou une mise à

Page 28 sur 116

Chapitre 3 . Sprint 1 : Préparation de la Bases de Données et API REST

niveau puisqu’elles ne disposent pas ni d’un SDK iOS, ni d’un support API, ni d’un support
cloud pour le moment, par conséquent, l’équipe de développement va être obligée de se
préoccuper de la configuration d’une infrastructure de base de données et des serveurs
intermédiaires, ce qui est couteux en termes de temps et de développement.

Selon des experts [18], si nous avons besoin d'un moyen de créer un système de
commerce électronique unique et personnalisé et que de plus nous voulons qu'un développeur
construise tout, qui est exactement notre cas, un système d'API comme Moltin nous serait le
meilleur recours au lieu de tout recommencer à zéro.

3.2.2 Étude comparative des APIs graphique 3D

Notre application est basée sur l’ARkit, la plus grande plateforme de réalité augmentée
du monde développée par Apple. Il s’agit d’une boite à outils qui permet aux développeurs
d’iOS de développer plus facilement des applications basées sur la RA et ce d’une façon bien
plus réaliste et optimisée grâce à des outils dédiés tels que : SceneKit, SpriteKit, Unity, Metal :

Figure 3-1 : Logo SceneKit Figure 3-2 : Logo SpriteKit

Figure 3-3 : Logo Unity Figure 3-4 : Logo Metal

À ce stade la DevTeam (c'est-à-dire moi-même) devait scruter, installer, étudier,

comparer divers APIs graphiques 3D pour ensuite choisir et convaincre le PO [19][20]. Le fruit
de ce travail est conjugué dans le tableau ci-dessous :

Tableau 3-3 : Tableau comparatif des APIs graphique 3D

Effet audiovisuel Intégration avec

Outil Type d’API Animation 3D
compliqué Apple UI elements
SceneKit Haut niveau Supporté Non supporté Facile
SpriteKit Haut niveau Non supporté Non supporté Facile
Unity Haut niveau Supporté Supporté Compliqué
Metal Bas niveau Supporté Supporté Facile

À travers ce tableau nous avons conclure que :

« Metal » est une API graphique 3D de bas niveau, c’est-à-dire proche du matériel d’où
elle comporte des fonctions qui permettent un accès direct au matériel mais en contrepartie,
elles a une logique complexe. Nous avons dû l’éliminer puisque nous avons besoin d’un outil
simple à manipuler sans la nécessité de savoir beaucoup de détails technique ou d’écrire
beaucoup de lignes de code.

Page 29 sur 116

Chapitre 3 . Sprint 1 : Préparation de la Bases de Données et API REST

Contrairement à « Metal », Les APIs : « SceneKit », « SpriteKit » et « Unity » sont des

API de haut niveau, c’est-à-dire proches de l'utilisateur puisqu’elles fournissent une couche
facile à utiliser qui inclut une grande partie du code standard que nous devons écrire.

Mais, « SpriteKit » est un outil adapté pour le cas des animations 2D et ne supporte pas
les animations 3D jusqu’à présent. Donc, cet API aussi ne satisfait pas nos besoins en tant
membre développeur 3D de la DevTeam.

Finalement le choix s’est limité entre « Unity » et « Scenekit » puisqu’elles sont

équivalentes en termes de performance. Mais « Unity » est un moteur de jeu multiplateforme
dédié principalement pour le développement des jeux vidéo avec des animations compliqués et
des effets audiovisuels, qui n’est pas du tout notre souhait. En fait, notre application bien que
ludique ne fait pas partie de la famille des jeux vidéo puisqu’elle comporte le volet de l’e-
commerce et le volet de la réalité augmenté. Il résulte de cette démonstration notre orientation
vers « SceneKit » pour une meilleur intégration avec Apple’s UI elements (Buttons, Gesture
Recognizers, ...).

3.3 Conception

3.3.1 Conception des objets 3D

Afin d’assurer une expérience utilisateur la plus réaliste possible, nous avons veillé à
mettre à la disposition des utilisateurs de l’application, des modèles 3D de taille réelle.
Néanmoins, la création des objets 3D à partir de zéro est une tâche bien compliquée qui
nécessite beaucoup de temps pour quelqu’un qui n’a pas d’expérience dans le métier d’un
modeleur 3D ou designer graphique, ce qui est notre cas. Cependant, en tant que Dev-Team
notre mission était de chercher sur Internet des modèles 3D qui répondent à nos besoins en
regard des délais de notre sprint (1 mois). Ceci nous a amené à soulever un autre défi qui est le
choix du meilleur format de modèle 3D pour notre application RA. L'un des critères pertinents
de choix, était que la plateforme iOS notamment l’outil SceneKit soient capable de l'intégrer.

En fait, chaque format de fichier présente des fonctionnalités et des limitations

différentes, certains ne peuvent être exportés que depuis des outils logiciels spécifiques et
coûteux. Parmi les formats que nous avons rencontré : FBX, DAE (Collada), 3DS, DXF, OBJ
... Nous avons ensuite réduit cette liste. Par exemple, OBJ n'était pas une option, car il
représente uniquement la géométrie du maillage 5 et 3DS ne fonctionne qu'avec 3ds Max, ce qui
est trop limité. Finalement, nous avons appris que seulement les fichiers DAE (Collada) sont
pris en charge sous la plateforme iOS, c’est pour cette raison que nous avons utilisé « Blender »
un logiciel libre et gratuit de modélisation pour transformer tout modèle trouvé en ce format.
Mais afin de pouvoir appliquer tous les paramètres et méthodes spécifiques de « SceneKit » il
est important de transformer encore une fois le modèle DAE, à l’aide de notre éditeur
« XCode » en SCN qui est le format de fichier de scène SceneKit.

5
Un maillage est la discrétisation spatiale d'un milieu continu, ou aussi, une modélisation géométrique d’un
domaine par des éléments proportionnés finis et bien définis.

Page 30 sur 116

Chapitre 3 . Sprint 1 : Préparation de la Bases de Données et API REST

3.3.2 Intégration des objets 3D

La manipulation des objets 3D est loin d’être évidente. Le fait de les stocker dans un
serveur n’est pas suffisant pour les manipuler et les afficher sur un dispositif mobile (Téléphone
ou Tablette) au moment de l'exécution. De plus, le chargement de tous les objets en même
temps pourrait affecter le bon fonctionnement de la mémoire et affecter le temps de réponse de
l’application. Comme solution à cet obstacle nous avons eu recours au système de fichiers
fournit par Apple pour chaque application installé qui se compose d’une arborescence de
répertoires standard comme il est représenté dans la figure ci-dessous :

Figure 3-5 : Arborescence de répertoires fournit par Apple

Plus précisément, nous exploité le dossier « tmp » pour stocker les URLs de
téléchargement des modèles 3D et les chargés en cas de besoins dans la scène de réalité
augmenté au moment de l'exécution. Selon Apple, ce répertoire est utilisé pour écrire des
fichiers temporaires qui n'ont pas besoin de persister une fois l’application n'est plus en cours
d'exécution le système peut purger ce répertoire.

3.4 Réalisation

Il devient de plus en plus clair que ce défilé de technologies est le rendu des « technical
stories » qui caractérisent ce premier sprint. Ce sprint s’avère une occasion d’appropriation de
nouvelles compétences pour la Dev Team. Toutefois, il n’est pas accepté de ne rien présenter
au clients et stakeholders au cours de la sprint review. Ce paragraphe et ses sous sections
expliqueront ce que verront les partis prenants précédemment cités.

3.4.1 Outils

Ci-dessous une description détaillé des différents outils utilisés au cours de ce Sprint :
• Blender

Blender est un logiciel libre et gratuit de modélisation,

d’animation et de rendu en 3D, créé en 1995. Il propose
des fonctions avancées de modélisation (dont la
sculpture 3D, le texturage et dépliage UV, etc), et
d’animation 3D (rigging, blend shapes).

Page 31 sur 116

Chapitre 3 . Sprint 1 : Préparation de la Bases de Données et API REST

• Moltin

Une solution de commerce électronique basée sur cloud.

Elle permet de créer une expérience de commerce
électronique complète et sur mesure, allant de la gestion
des stocks à la vérification des commandes vu qu’elle
associe une API assez facile à connecter à toute
infrastructure ou périphérique informatique existant.

Notre choix de Moltin est justifié par son infrastructure unique qui est basé sur cloud,
plus précisément « Amazon web Service cloud », ce qui lui a permis un support large pour
l’architecture de base de données tel que :

Amazon Relational Database Service (RDS) : permet

d'installer, de gérer et de mettre à l'échelle facilement une
base de données relationnelle dans le cloud.infrastructure
ou périphérique informatique existant.

Amazon S3 Storage : Amazon Simple Storage Service,

un service de stockage d'objet offrant une disponibilité
des données, une sécurité et des performances de pointe.

Mais vu que le stockage des fichiers en Moltin est limités pour les fichiers de types images,
nous avons fait recours au « Firebase Storage » afin de stocker nos modèles 3D :

• Firebase Storage

Firebase Storage est une solution autonome permettant

de télécharger du contenu généré par l'utilisateur, tel que
des images et des vidéos à partir d'un périphérique iOS
ou Android, ainsi que sur le Web.

3.4.2 Captures d’écran de l’incrément 1 potentiellement livrable

Durant cette partie, nous démontrons les résultats de ce sprint à travers la présentation
de quelques captures d'écran de l’incrément back-end réalisé :

Tout d’abord, nous rappellons que nous avons déjà présenté dans le deuxième chapitre
« Initiation du projet » l’architecture physique de notre application et nous avons mentionné
qu’elle sera construite au fur et à mesure durant l’avancement dans les Sprints par l’intégration
des incréments potentiellement livrable. La figure 3.6 représente l’architecture complète et

Page 32 sur 116

Chapitre 3 . Sprint 1 : Préparation de la Bases de Données et API REST

détaillé de notre application. C’est suite au choix de la plateforme « Moltin » que nous avons
pu identifier les différents composants intervenants.

Figure 3-6 : Architecture physique complète de « HomeShop »

Ensuite, nous avons préparé le catalogue contenant les articles à mettre en vente à la
disposition des utilisateurs en utilisant le dashboard « Moltin » comme le montre la figure 3.7
ci-dessous :

Figure 3-7 : Dashboard Moltin

Finalement, La figure 3-8 montre le résultat de l’exécution du bout de code permettant

l’intégration des modèles 3D en stockant leurs URLs de téléchargement dans le dossier « tmp »

Page 33 sur 116

Chapitre 3 . Sprint 1 : Préparation de la Bases de Données et API REST

afin de pouvoir les afficher dans la scène de la RA au moment de l'exécution. La simulation de

l’ameublement sur une scène fera l’objet du sprint 3

Figure 3-8 : Capture démonstrative de l'intégration des objets 3D

Conclusion
Durant ce Sprint, nous avons tout d’abord fait l’analyse en comparant les différentes
plateformes d’E-Commerce et APIs graphique 3D en tant qu’application du premier critère de
notre DoD. Puis, nous avons fait la conception des modèles 3D en tant qu’application du
deuxième critère de notre DoD. Et finalement, nous avons pu intégrer nos modèles 3D dans
l’application en stockant les URLs de téléchargement du modèle sous l’arborescence de
répertoires standard d’Apple, plus précisément le dossiers « tmp ».

Ce Sprint a été présenté dans le cadre d'une réunion de fin de sprint appelé « Sprint
Review » qui permet un contrôle qualité par rapport à la DoD. Cette réunion était à la présence
de l'équipe du projet, le PO ainsi que le chef de département mobile comme représentant des
stakeholder. Après avoir été enrichie par leurs remarques et propositions d’améliorations, nous
entamons dans le prochain Sprint « Écran d’accueil HomeShop ».

Page 34 sur 116

 Chapitre 4

4 Sprint 2 : Écran d’Accueil « HomeShop »

Plan

Introduction...................................................................................................................................... 36
4.1 HomeShop Sprint 2 planning ............................................................................................ 36
4.2 Analyse ................................................................................................................................. 37
4.3 Conception ........................................................................................................................... 38
4.4 Réalisation ........................................................................................................................... 39
Conclusion ........................................................................................................................................ 42
Chapitre 4 . Sprint 2 : Écran d’Accueil « HomeShop »

Introduction

Ce Chapitre fait l’objet d’une présentation du deuxième Sprint du projet qui est la création
de l’écran d’accueil de l’application et la réalisation des « User Stories » prioritaires pour cet
écran. L'étude de premier Sprint couvre l'analyse, la conception, la réalisation et les test
fonctionnels.

4.1 HomeShop Sprint 2 planning

4.1.1 Objectif du sprint 2

Ce Sprint a pour objectif, dans un premier lieu, la préparation de l’écran d’accueil de

notre application d’une maniéré statistique en choisissant un design et une méthode de
navigation dans l’application facile et compréhensible par l’utilisateur. Ensuite, la mise en place
du comportement dynamique de la consultation des catégories par l’utilisateur.

4.1.2 Sprint Backlog du Sprint 2

Ci-dessous le tableau 4-1 montre une représentation du raffinement de la « User Stroy »

prioritaire pour cet écran mentionné à la page 20 durant le chapitre 2 « Initiation du projet » en
ensemble de « Tasks » :

Tableau 4-1 : Sprint Backlog du Sprint 2

ID User Story ID Task Task Complexity

Choisir et développer une méthode

1.1 de navigation dans l’application
S

1.2 Création de l’interface graphique. S

Ajout de l’auto-layout pour

1.3 adaptation sur tout type d’IPhone M

En tant que visiteur, je veux Implémentation du modèle

consulter les différentes catégories 1.4 « catégorie » XS
1 disponibles, afin d’accéder aux
articles par catégorie. Implémentation du code nécessaire
1.5 pour la récupération d’ un S
« Implicit Token »
Test des requêtes permettant la
1.6 récupération des données des S
catégories.
Implémentation des managers de
1.7 type REST pour la communication L
avec la partie frontale.
Implémentation des contrôleurs
1.8 pour la consommation des L
managers crées.

Page 36 sur 116

Chapitre 4 . Sprint 2 : Écran d’Accueil « HomeShop »

4.2 Analyse

4.2.1 Raffinement et description des cas d’utilisations

• Consultation des catégorie

Figure 4-1 : Raffinement de cas d'utilisation « Consultation des catégories »

En ouvrant l’application, le premier écran affiché c’est l’écran d’accueil où l’utilisateur

peut consulter les différents catégorie proposées.

Durant la conclusion du deuxième chapitre page 25, nous avons mis le point sur les cas
d’utilisation les plus importants de notre application. Le cas du « Consultation des catégories
» ne fait pas partie de ces cas, donc nous avons procédé à une description textuelle minimiser
de ce cas d’utilisation comme il est présenté dans le tableau 4-2 :

Tableau 4-2 : Description textuelle du cas d'utilisation « Consultation des catégories »

Titre : Consulter les catégories

Acteur : Visiteur, Client.
Résumé : Ce CU permet à l'acteur de consulter les différents catégorie proposé par l’application .
Pré-condition :
- L'utilisateur possède une connexion internet.
Scénario nominal 1 :
01. Le système propose des catégories à consulter dans l’écran d’accueil.
02. L’utilisateur consulte les différents catégorie.
Scénario d'erreur :
E1. Connexion internet interrompue
- E1 peut se déclencher à tous point du scenario nominal 1 ou 2.
01. Le système informe l’utilisateur et lui demander de ressayer ultérieurement.
Post-condition :
- Catégories consultées.

4.2.2 Proposition des maquettes

Afin d’assurer une idée plus précise de l'ergonomie du module, une bonne
compréhension et concrétiser rapidement les attentes et les exigences attendus nous avons
réalisé des maquettes. La figure 4-2 représente une vue préliminaire de l’écran d’accueil de
notre application :

Page 37 sur 116

Chapitre 4 . Sprint 2 : Écran d’Accueil « HomeShop »

Figure 4-2 : Maquette « Écran d'accueil »

4.3 Conception

Cette partie comporte la conception du sprint, nous avons fait recours au diagramme
d’activité et au diagramme de classes.

4.3.1 Diagramme d’activité

Afin de mieux comprendre le déroulement du cas d’utilisation « Consulter les

catégories », nous faisons recours dans la figure 4-3 au diagramme d’activité :

Figure 4-3 : Diagramme d'activité de cas d'utilisation « Consulter les catégorie »

Page 38 sur 116

Chapitre 4 . Sprint 2 : Écran d’Accueil « HomeShop »

Le diagramme d’activité montre la génération d’un « Access Token » ou « jeton

d’accès », il est équivalent à une clé publique utilisée dans les cas où nous demandons des
données côté client qui ne nécessite pas une authentification explicite. C’est une sorte de
sécurisation de l’accès à « HomeShop ».

4.3.2 Diagramme de classes

Pour assurer une vue global de notre système, nous présentons les classes intervenantes
et les différentes relations entre elles. En adoptant Scrum le diagramme de classe n’apparait pas
totalement détaillé car il sera construit au fur et à mesure durant l’avancement dans les Sprints
par l’intégration des classes intervenant dans la réalisation de chaque Sprint.

Figure 4-4 : Incrément du Diagramme de classes du Sprint 1

4.4 Réalisation

4.4.1 Outils

Au cours de la réalisation de chaque Sprint qui comporte des « Tasks » nécessitant le test
et l’exécution des requêtes http, ainsi que la création et design des interfaces graphique nous
utilisons les outils mentionnées ci-dessous :

• Postman

Une extension sur Google chrome qui permet de tester et

consommer des web services afin de mieux comprendre
la structure des données reçues.

• Alamofire
Une bibliothèque développé par la société Apple. Elle est
destiné à l’exécution des requêtes d'API REST sur les
systèmes d'exploitation iOS, macOS, watchOS et tvOS.

Page 39 sur 116

Chapitre 4 . Sprint 2 : Écran d’Accueil « HomeShop »

• Sketch
Un éditeur graphique vectoriel propriétaire pour macOS
d’Apple, développé par la société néerlandaise
Bohemian Coding.

• Prepo

Un logiciel d’imagerie disponible seulement sous Mac

OS X, il vous permet de découper toutes vos images et
icones et recadrer pour qu’ils soient compatibles avec
toutes les résolutions d’écran des iPhones.

4.4.2 Captures d’écran de l’incrément 2 potentiellement livrable

Afin de montrer les résultats de ce sprint, nous allons présenter quelques captures
d'écran. La figure 4-4 représente la barre de navigation que nous avons choisie :

Figure 4-5 : Barre de navigation « HomeShop »

Ces écrans vont être construites au fur et à mesure durant l’avancement dans les Sprints
par l’intégration des incréments potentiellement livrables. Durant ce Sprint, nous avons
construit l’écran de l’accueil. Ci-dessous, la figure 4-6 et 4-5 représentent le résultat :

Page 40 sur 116

Chapitre 4 . Sprint 2 : Écran d’Accueil « HomeShop »

La mise en place d’un comportement

dynamique dans l’application nécessite
l’ajout des signes visuels afin d’informer
l’utilisateur qu’il doit attendre la réponse
du serveur.

En revenant vers le PB dans la

page 20, La recherche d’un
Figure 4-6 : Chargement de l’interface de l’écran d'accueil « HomeShop »
produit ne dispose pas d’une
priorité élevée donc elle fait
l’objet d’un des Sprints d’une
deuxième release.

Une fois le temps d’attente de réponse de

serveur est terminée les catégories seront
affichées.

La gestion des promotions

fait l’objet d’un des Sprints
d’une deuxième release
aussi.

Figure 4-7 : Écran d'accueil « HomeShop »

Page 41 sur 116

Chapitre 4 . Sprint 2 : Écran d’Accueil « HomeShop »

Conclusion

Durant ce Sprint, tout d’abord, nous avons appliqué le premier critère de notre DoD en
effectuant l’analyse des cas d’utilisations prioritaire pour ce Sprint. Puis, nous avons réalisé la
conception, qui est le deuxième critère de notre DoD , en faisant recours au diagramme de
classes et au diagrammes d’activité du formalisme UML. Finalement, nous avons présenté le
travail réalisé au cours de ce Sprint durant le « Sprint Review » afin de contrôler la qualité de
l’incrément livré.

Cette réunion était à la présence de l'équipe du projet, le PO ainsi que le chef de

département mobile comme représentant des stakeholder.

Après avoir été enrichi par leurs remarques et propositions de perspectives, nous
entamons le prochain Sprint « Écran de scène de test avec la réalité augmentée ».

Page 42 sur 116

 Chapitre 5

5 Sprint 3 : Écran Scène de Test Avec La

Réalité Augmentée

Plan

Introduction...................................................................................................................................... 44
5.1 HomeShop Sprint 3 planning ............................................................................................ 44
5.2 Analyse ................................................................................................................................. 45
5.3 Conception ........................................................................................................................... 48
5.4 Réalisation ........................................................................................................................... 51
Conclusion ........................................................................................................................................ 59
Chapitre 5 . Sprint 3 : Écran Scène de Test Avec La Réalité Augmentée

Introduction

Ce Chapitre fait l’objet d’une présentation du troisième Sprint du projet « HomeShop »

qui est la création et implémentation de l’écran de test des modèles en utilisant la réalité
augmenté. La majorité de la période du temps réservé pour ce sprint est réservé pour la
formation de l’équipe ce qui est transposé pour notre cas en tant qu’étudiante stagiaire en une
auto-formation. L'étude de ce Sprint couvre l'analyse, la conception, la réalisation, l’intégration
du travail réalisé au Sprint précédant, la documentation et les tests fonctionnels.

5.1 HomeShop Sprint 3 planning

5.1.1 Objectif du sprint 3

Ce Sprint a pour objectif, dans un premier lieu, la préparation de l’écran de la scène de

test avec la réalité augmenté de notre application d’une maniéré statistique en choisissant un
design clair et ergonomique comprenant toute les fonctionnalités demandées. Ensuite, mettre
en place le comportement dynamique des « User Stories » prioritaires demandées.

5.1.2 Sprint Backlog du Sprint 3

Durant ce Sprint, le PO a étendu les fonctionnalités attendues pour ce Sprint en ajoutant

d’autres « Users Stories » prioritaires pour cet écran. Ci-dessous le tableau 5-1 représente un
raffinement de toutes les « User Stories » en ensemble de « Tasks », en incluant les nouvelles
« User Stories » proposées par le PO :

Tableau 5-1 : Product Backlog du Sprint 5

ID User Story ID Task Task Complexity

1.1 Création de l’interface graphique. S

Ajout de l’auto-layout pour

1.2 adaptation sur tout type d’IPhone M

Implémentation du modèle
1.3 « Produit » XS
En tant que visiteur, je veux accéder
à une scène RA, afin d’essayer les
1 articles dans le monde réel en Test des requêtes permettant la
utilisant la technologie de la réalité 1.4 récupération des données des S
augmentée. articles de catalogues.
Implémentation des managers de
1.5 type REST pour la communication L
avec la partie frontale.
Implémentation des contrôleurs
1.6 pour la consommation des L
managers crées.
Implémentation des contrôleurs
permettant la détection du plan XL
1.7

Page 44 sur 116

Chapitre 5 . Sprint 3 : Écran Scène de Test Avec La Réalité Augmentée

horizontale via le caméra de

téléphone
Implémentation des messages,
1.8 renseignes et signes visuelles L
indiquant la détection du plan.
Implémentation des contrôleurs
1.9 permettant le chargement de chaque L
article choisit dans la scène RA
Implémentation des « Gestures
2.1 Recognizer » permettant XL
l’interaction avec les modèles
En tant que visiteur, je veux Création de l’interface permettant
interagir avec les modèles chargé 2.2 le choix des couleurs S
2 dans la scène, afin de pouvoir les Implémentation de contrôleur
déplacer, les pivoter, changer leurs 2.3 permettant le changement de L
couleurs ou les supprimer. couleur des modèles chargés
Création et implémentation d’un
2.4 menu help montrant comment M
interagir avec les modèles
Implémentation du code nécessaire
permettant la conversion des
3.1 modèles 3D en leur équivalent des S
produits commercialisés.
Test des requêtes permettant l’ajout
En tant que visiteur, je veux ajouter 3.2 des produits dans le panier. M
3 à mon panier tous les articles que
Implémentation des managers de
j'ai testés
3.3 type REST pour la communication L
avec la partie frontale.
Implémentation des contrôleurs
3.4 pour la consommation des L
contrôleurs crées.

En tant que visiteur, je veux prendre Implémentation du code nécessaire

4.1 pour la prises de photos sur scène. M
des photos pour ma scène de test,
4 afin de les consulter ultérieurement
de ma galerie et me décider pour Implémentation du code nécessaire
l’achat. 4.2 pour l’enregistrement de photo S
prose dans la galerie des photos.

En tant que visiteur, je veux Ajout du Bouton permettant la

5.1 réinitialisation de l’expérience XS
redémarrer l’expérience de test des
5 articles à tout moment, afin de
réinitialiser toute la scène et Implémentation du code nécessaire
commencer à zéro. 5.2 pour la réinitialisation. M

5.2 Analyse

5.2.1 Raffinement et description des cas d’utilisations

• Visualisation d’une scène AR :

Page 45 sur 116

Chapitre 5 . Sprint 3 : Écran Scène de Test Avec La Réalité Augmentée

Figure 5-1 : Raffinement de cas d'utilisation « Test des articles dans le monde réel via caméra »

Un utilisateur quoi qu’il soit un visiteur ou client (visiteur connecté à son compte) a le droit
d’accéder via sa caméra de téléphone à une scène de la réalité augmentée et détecter une surface
horizontale afin d’essayer les différents modèles 3D disponibles. Deux scénarios de
manipulations ont été envisagés qui et longuement débattus par le PO et sa DevTeam :

Le premier, en consultant le catalogue d’articles classés par catégories, disponibles à

l’occasion de l’accès à la scène. Le deuxième, en sélectionnant l’ensemble des articles à tester
avant d’accéder à la scène. Quand bien même le deuxième scénario paraît hédonique pour le
PO qui l’a tout de suite jugé d’un important business value, il a accepté que la DevTeam (Moi-
même) se lance dans la programmation du premier scénario pour des raisons de respect du
timebox du sprint et pour sa moindre complexité de développement.

L’utilisateur pourra par la suite et d’une manière ludique placer, déplacer, supprimer,
changer la couleur voir, ajouter au panier les modèles choisis. De plus, il pourra prendre une
instance de photo pour la scène meublée qu’il pourra consulter ultérieurement dans sa galerie
de photos sur téléphone. Et de là se décider de passer à l’acte d’achat.

Le tableau 5-2 présente une description détaillée du cas d’utilisation « Test des articles dans
le monde réel via caméra » :

Tableau 5-2 : Description textuelle détaillée du cas d'utilisation « Test des articles dans le monde réel »

Titre : Test des articles dans le monde réel via caméra.

Acteur : Visiteur, Client.
Résumé : Ce CU permet à l'acteur de tester des modèles 3D dans le monde réel via son camera de téléphone.
Pré-condition :
- L'utilisateur possède une connexion internet.
- L’accès à la camera du téléphone est autorisé.
Scénario nominal 1 :
01. Le système propose des catégories à consulter dans l’écran d’accueil.
02. L’utilisateur choisit une catégorie.
03. Le système redirige l’utilisateur vers l’écran de la scène de la réalité augmenté et demande
l’autorisation d’accès à l’appareil photo de l’utilisateur.
04. L’utilisateur autorise l’accès et avoir accès à la scène de réalité augmenté.
05. Le système demande le scan du plan.
06. L’utilisateur scan le plan.
07. Le système autorise l’accès au catalogue du catégorie sélectionner.
08. L’utilisateur commence à choisir des modèles et les positionner dans la scène.
09. L'utilisateur quitte la scène de la réalité augmenté.

Page 46 sur 116

Chapitre 5 . Sprint 3 : Écran Scène de Test Avec La Réalité Augmentée

10. Le système renvoie l’utilisateur vers l’écran d’accueil.

Scénario nominal 2 :
01. Le système propose des articles à consulter dans l’écran de catégorie et sous-catégorie.
02. L’utilisateur sélectionne les différents articles à tester et confirme son choix.
03. Le système redirige l’utilisateur vers l’écran de la scène de la réalité augmenté et demande
l’autorisation d’accès à l’appareil photo de l’utilisateur.
04. L’utilisateur autorise l’accès et avoir accès à la scène de réalité augmenté.
05. Le système demande le scan du plan.
06. L’utilisateur scan le plan.
07. Le système autorise l’accès au catalogue du catégorie sélectionner.
08. L’utilisateur commence à choisir des modèles et les positionner dans la scène.
09. L'utilisateur quitte la scène de la réalité augmenté.
10. Le système renvoie l’utilisateur vers l’écran des catégorie et sous-catégorie.
Scénario alternatif :
A1. Le plan scanné est détecté
- A1 se déclenche au point 06 du scénario nominal 1 ou 2
01. Le système affiche une signe à l’utilisateur de détection du plan.
Le scénario nominal reprend du point 07.
A2. Le plan scanné n’a pas pu être détecter.
- A2 se déclenche au point 06 du scénario nominal 1 ou 2
01. Le système continue à demander la détection du plan en affichant des renseignement à
l’utilisateur.
Le scénario nominal reprend du point 06.
A3. L’utilisateur choisit de changer l’emplacement d’un modèle
- A3 se déclenche au point 08 du scénario nominal 1 ou 2
01. Le système détecte la nouvelle position du modèle et actualise sa position.
Le scénario nominal reprend du point 08.
A4. L’utilisateur choisit de changer la couleur d’un modèle.
- A4 se déclenche au point 08 du scénario nominal 1 ou 2
01. Le système fournis une liste de couleur à l’utilisateur pour qu’il sélectionne un couleur de son
choix.
Le scénario nominal reprend du point 08.
A5. L’utilisateur choisit de supprimer un modèle de la scène.
- A5 se déclenche au point 08 du scénario nominal 1 ou 2
01. Le système demande à l’utilisateur de confirmer sa suppression et le supprime en cas de
confirmation ou annule en cas où l’utilisateur a annulé la procédure.
Le scénario nominal reprend du point 08.
A6. L’utilisateur choisit d’ajouter les articles testés dans son panier.
- A6 se déclenche au point 08 du scénario nominal 1 ou 2
01. Le système informe l’utilisateur que ses articles ont été bien ajouté au panier ou non.
Le scénario nominal reprend du point 08.
A7. L’utilisateur choisit de prendre une photo de la scène.
- A7 se déclenche au point 08 du scénario nominal 1 ou 2
01. Le système prend une instance de photo de la scène et l’enregistre dans la galerie de photo de
l’appareil mobile.
Le scénario nominal reprend du point 08.
A8. L’utilisateur choisit de redémarrer l’expérience.
- A8 peut se déclencher à tous point du scenario nominal 1 ou 2.
01. Le système initialise supprime les articles chargés sur scène.
Le scénario nominal reprend du point 05
A9. L’utilisateur choisit d’afficher le menu help.
- A9 peut se déclencher à tous point du scenario nominal 1 ou 2.
01. Le système affiche une petite documentation qui montre à l’utilisateur comment interagir avec
les modèles chargés.
Le scénario nominal reprend du point 05
Scénario d'erreur :
E1. Connexion internet interrompue
- E1 peut se déclencher à tous point du scenario nominal 1 ou 2.
01. Le système informe l’utilisateur et lui demander de ressayer ultérieurement.

Page 47 sur 116

Chapitre 5 . Sprint 3 : Écran Scène de Test Avec La Réalité Augmentée

E2. L’utilisateur refuse l’accès à son appareil photo

- E2 peut se déclencher au point 03 du scenario nominal 1 ou 2.
01. Le système informe l’utilisateur et le CU se termine en échec.

Post-condition :
- Articles choisit visualisé dans la scène de la réalité augmenté.
- Panier rempli par les articles choisit en cas d’exécution du scenario alternatif A6.
- Instance photo disponible dans la galerie de l’appareil mobile en cas d’exécution du scenario
alternatif A7.

Après l’étude détaillé de ce cas, le PO et la DevTeam ont choisi d’implémenter la

première méthode durant ce Sprint et faire de la deuxième méthode l’objet d’autres releases qui
seront réalisées dans le futur.

5.2.2 Proposition des maquettes

La figure 5-2 montre une représentation préliminaire de l’écran de scène de test avec la
RA qui sera affiché une fois l’utilisateur a choisi une catégorie et de l’écran comportant les
articles proposés en fonction de la catégorie choisie :

Figure 5-2 : Maquettes « Écran de test RA »

5.3 Conception

Pour la conception du troisième Sprint, nous avons fait recours au diagrammes de

séquence et au diagramme de classes.

5.3.1 Diagramme de séquences

Afin de mieux éclairer les interactions échangées au cour du cas d'utilisation vu

précédemment et voir comment les tâches sont distribuées entre les différents composants. La
figure 5-3 et 5-4 présentent les diagrammes de séquences relatifs au cas d'utilisation « Test des
articles dans le monde réel via camera » :

Page 48 sur 116

Chapitre 5 . Sprint 3 : Écran Scène de Test Avec La Réalité Augmentée

Figure 5-3 : Diagramme de séquence « Détection d'un plan »

Page 49 sur 116

Chapitre 5 . Sprint 3 : Écran Scène de Test Avec La Réalité Augmentée

Figure 5-4 : Diagramme de séquence « Chargement des modèles 3D »

Page 50 sur 116

Chapitre 5 . Sprint 3 : Écran Scène de Test Avec La Réalité Augmentée

5.3.2 Diagramme de classes

En avançant dans les Sprints, le diagramme de classes se construit au fur et à mesure

en gardant les classes du Sprint précédant et ajoutant les nouvelles classes intervenantes dans
ce Sprint. La figure 5-5 représente les classes intervenantes dans ce Sprint :

Figure 5-5 : Incrément du diagramme de classe de Sprint 2

5.4 Réalisation

5.4.1 Outils

Nous rappelons que chaque écran de notre application nécessite le test et l’exécution
des requêtes http, ainsi que la création et design des interfaces graphique, c’est pour cela nous
faisons recours toujours aux outils mentionnées ci-dessous :

Postman Alamofire Sketch Prepo

5.4.2 Captures d’écran de l’incrément 3 potentiellement livrable

Afin de montrer les résultats de ce sprint, nous allons présenter un défilé de captures
d’écran de l’incrément réalisé en démontrant au fur et à mesure quelques aspects techniques
utilisés:

Tout d’abord, la mise en œuvre derrière le test des articles dans le monde réel en utilisant
« HomeShop » est dû à la correspondance entre les espaces réels et virtuels, ARKit utilise une
technique appelée « visual-inertial odometry » afin de combiner les informations provenant des

Page 51 sur 116

Chapitre 5 . Sprint 3 : Écran Scène de Test Avec La Réalité Augmentée

capteurs de détection de mouvement du périphérique iOS avec l’analyse de la scène visible par
la caméra du périphérique en utilisant la technologie de l’intelligence artificielle (Computer
Vision). Ci-dessous, la figure 5-6 montre les premières phases d’analyse de scène afin d’arriver
à la détection du plan :

Figure 5-6 : Écrans d’initialisation de la scène AR

Page 52 sur 116

Chapitre 5 . Sprint 3 : Écran Scène de Test Avec La Réalité Augmentée

Afin de pouvoir
détecter un plan
horizontal ARKit
utilise des points
caractéristiques ou
« feature points »

Figure 5-7 : Écrans de détection du plan

Ces points représentent des caractéristiques notables détectées dans l’image de la

caméra. Leurs positions dans l’espace de coordonnées 3D du monde sont extrapolées dans le
cadre de l’analyse d’image effectuée par ARKit.

Page 53 sur 116

Chapitre 5 . Sprint 3 : Écran Scène de Test Avec La Réalité Augmentée

Plus la surface à détecter comporte beaucoup

de détails (coins, traits, formes, textures...),
plus le nombre des « Feature Points »
augmente, plus la détection du plan devient
plus facile.

Une fois le plan est détecté,

l’utilisateur pourra afficher le
catalogue en appuyant sur le bouton
approprié.

Figure 5-8 : Écran de détection des points caractéristiques

Figure 5-9 : Écrans d’affichage de Catalogue en 3D

Page 54 sur 116

Chapitre 5 . Sprint 3 : Écran Scène de Test Avec La Réalité Augmentée

« HomeShop » permet à
l’utilisateur de tester un
ou plusieurs modèles en
même temps.

Figure 5-10 : Écrans de chargement des modèles 3D

Il est à noter que le chargement

d’un modèle peut échouer une
fois l’application a perdu le plan
détecté. Ceci peut avoir lieu suite
aux déplacements rapides de
l’appareil mobile au moment de
chargement de l’objet. Parmi nos
jeux de tests fonctionnels, la
capture montre que nous avons
intercepté un type de mauvaise
manipulation et nous l'avons
documenté pour l'utilisateur en
guise de help et ce
conformément au dernier critère
de la DoD.

Figure 5-11 : Écran d'erreur de chargement de modèle

Page 55 sur 116

 Chapitre 5 . Sprint 3 : Écran Scène de Test Avec La Réalité Augmentée

L’utilisateur peut consulter

un menu d’aide, afin de
savoir comment interagir
avec les modèles chargés.
Il peut également
redémarrer l’expérience
en initialisant la scène et
recommencer tout à
zéro.

Figure 5-12 : Écrans « Menu help »

Page 56 sur 116

Chapitre 5 . Sprint 3 : Écran Scène de Test Avec La Réalité Augmentée

La suppression
d’un modèle
s’effectue en
appuyant
longtemps sur le
modèle à
supprimer

Figure 5-13 : Écran de suppression d’un modèle de la scène AR

Le changement de
couleur d’un
modèle s’effectue
en appuyant deux
fois de suite sur un
modèle.

Figure 5-14 : Écrans de Changement de couleur d’un modèle

Page 57 sur 116

Chapitre 5 . Sprint 3 : Écran Scène de Test Avec La Réalité Augmentée

« HomeShop »
offre la
possibilité de
prise des
instances de
photos

Une fois la photo est prise,

elle sera enregistrée dans la
galerie des photos de
l’appareil mobile, Ce qui
permet son partage avec
tous type de réseaux
sociaux. Le partage sur les
réseaux sociaux sera pris en
compte dans un des sprints
de la future Release après
négociation entre le PO et
les Stakeholders.

Figure 5-15 : Écrans de prise d’une instance de photo

Page 58 sur 116

Chapitre 5 . Sprint 3 : Écran Scène de Test Avec La Réalité Augmentée

En appuyant sur le button d’ajout

au panier, tous les articles chargés
dans la scène seront ajoutés dans
le panier.

La consultation du panier et la
gestion de son contenu feront
l’objet du prochain Sprint.

Figure 5-16 : Écran d’ajout des modèle dans le panier

Conclusion

Durant ce Sprint, tout d’abord, nous avons appliqué le premier critère de notre DoD en
effectuant l’analyse des cas d’utilisations prioritaire pour ce Sprint. Puis, nous avons réalisé la
conception, qui est le deuxième critère de notre DoD, en faisant recours au diagramme de
classes et au diagramme de séquence du formalisme UML. Finalement, nous avons présenté le
travail réalisé au cours de ce Sprint durant le « Sprint Review » afin d’assurer un contrôle de
qualité de haut niveau.

Cette réunion était à la présence de l’équipe du projet, le PO ainsi que le chef de

département mobile comme représentant des stakeholder.

Après avoir été enrichi par leurs remarques et propositions de perspectives, nous
entamons le prochain Sprint « Écran de gestion de panier »

Page 59 sur 116

 Chapitre 6

6 Sprint 4 : Écran de Gestion du Panier «

HomeShop »

Plan

Introduction...................................................................................................................................... 61
6.1 HomeShop Sprint 4 planning ............................................................................................ 61
6.2 Analyse ................................................................................................................................. 62
6.3 Conception ........................................................................................................................... 63
6.4 Réalisation ........................................................................................................................... 66
Conclusion ........................................................................................................................................ 68
Chapitre 6 . Sprint 4 : Écran de Gestion du Panier « HomeShop »

Introduction

Ce chapitre fait l’objet d’une présentation du quatrième Sprint du projet « HomeShop »

qui est la création et implémentation de l’écran de gestion de panier. L’étude de ce Sprint couvre
l’analyse, la conception, la réalisation, l’intégration et les tests fonctionnelles.

6.1 HomeShop Sprint 4 planning

6.1.1 Objectif du sprint 4

Ce Sprint a pour objectif, dans un premier lieu, la préparation de l’écran de gestion du

panier d’une maniéré statistique en choisissant un design englobant toute les fonctionnalités
demandées. Ensuite, mettre en place le comportement dynamique des « User Stories »
prioritaires demandées.

6.1.2 Sprint Backlog du Sprint 4

Le tableau 6-1 ci-dessous présente le raffinement en ensemble de « Tasks » la « User

Stroy » choisie pour le développement dans ce Sprint :

Tableau 6-1 : Sprint Backlog du Sprint 4

ID User Story ID Task Task Complexity

1.1 Création de l’interface graphique. S

Ajout de l’auto-layout pour

1.2 adaptation sur tout type d’IPhone M

Implémentation des modèles

1.3 « Panier » et « Item » XS

En tant que visiteur, je veux accéder Test des requêtes permettant la

1 à mon panier, afin de modifier des 1.4 mise à jour des données d’un S
quantités et/ou supprimer un article. panier.
Implémentation des managers de
1.5 type REST pour la communication L
avec la partie frontale.
Implémentation des contrôleurs
1.6 pour la consommation des L
managers crées.
Implémentation des messages et
1.7 signes visuelles indiquant la M
terminaison des actions.

Page 61 sur 116

Chapitre 6 . Sprint 4 : Écran de Gestion du Panier « HomeShop »

6.2 Analyse

6.2.1 Raffinement et description des cas d’utilisations

Figure 6-1 : Raffinement du cas d’utilisation « Gestion du panier »

Une fois l’utilisateur a ajouté des modèles à son panier, il sera redirigé vers l’écran du
panier afin qu’il puisse modifier des quantités et/ou supprimer un article. Une fois le panier est
validé, l’utilisateur peut passer une commande en accédant à son compte client. Si l’utilisateur
ne dispose pas d’un compte, il doit obligatoirement s’inscrire.

Le tableau 6-2 présente une description textuelle minimiser de cas d’utilisation «

Gestion du panier » :

Tableau 6-2 : Description textuelle du cas d’utilisation « Gestion du panier »

Titre : Gérer panier

Acteur : Visiteur, Client.
Résumé : Ce CU permet à l’acteur la gestion de son panier à travers la modification de quantité souhaitée, la
suppression des articles ou la validation du panier pour passage d’une commande.
Pré-condition :
- L’utilisateur possède une connexion internet.
- Le client est connecté à son compte pour le passage du commande.
Post-condition :
• Accès et gestion du panier.

Les processus de l’inscription, la connexion au compte et le passage d’une commande

font respectivement l’objet du cinquième et sixième Sprint.

6.2.2 Proposition des maquettes

La figure 6-2 donne une perception de l’écran « Gestion de panier » qui sera affiché une
fois l’utilisateur a ajouté des articles à son panier ou en cliquant sur le panier dans la barre de
navigation.

Page 62 sur 116

Chapitre 6 . Sprint 4 : Écran de Gestion du Panier « HomeShop »

Figure 6-2 : Maquettes « Écran de panier »

6.3 Conception

Pour la conception du quatrième Sprint, nous avons fait recours au diagrammes de

séquence et au diagramme de classes.

6.3.1 Diagramme de séquence

La figure 6-3 présente le diagramme de séquences relatifs au cas d’utilisation « Ajout

d’un article au panier » Afin de mieux éclairer les interactions échangées au cours du ce cas
d’utilisation :

Page 63 sur 116

Chapitre 6 . Sprint 4 : Écran de Gestion du Panier « HomeShop »

Figure 6-3 : Diagramme de séquence du cas d'utilisation « Ajouter au panier »

6.3.2 Diagramme de classes

La figure 6-4 présente l’incrément du diagramme de classes qui englobe les nouvelles
classes intervenantes dans ce Sprint :

Page 64 sur 116

Chapitre 6 . Sprint 4 : Écran de Gestion du Panier « HomeShop »

Figure 6-4 : Incrément du diagramme de classes du Sprint 4

Page 65 sur 116

Chapitre 6 . Sprint 4 : Écran de Gestion du Panier « HomeShop »

6.4 Réalisation

6.4.1 Outils

De même durant ce Sprint on a fait recours aux outils « Postman » et « Alamofire »

pour le test et l’exécution des requêtes http, « Sketch » et « prepo » pour la création et design
des interfaces graphique.

6.4.2 Captures d’écran de l’incrément 4 potentiellement livrable

Durant cette partie, nous démontrons les résultats de ce sprint à travers la présentation
de quelques captures d’écran de l’incrément réalisé.

La figure 6-5, montre le résultat de l’implémentation de l’écran de panier de

« HomeShop » :

Figure 6-5 : Écran de panier « HomeShop »

Page 66 sur 116

Chapitre 6 . Sprint 4 : Écran de Gestion du Panier « HomeShop »

Les figures 6-6 et 6-7 présentent le résultat de l’implémentation des « Tasks » de

modification des quantités et/ou de suppression d’un article du panier :

Figure 6-6 : Processus de gestion de panier « Modification des quantités »

Page 67 sur 116

Chapitre 6 . Sprint 4 : Écran de Gestion du Panier « HomeShop »

Figure 6-7 : Processus de gestion de panier « Suppression d’un article »

Conclusion

Durant ce Sprint, nous avons effectué la conception et l’implémentation de l’écran de

gestion de panier en tant qu’application du premier, deuxième et troisième critères de notre
DoD. Nous avons intégré le résultat de cet incrément avec le résultat de l’incrément du Sprint
précédant, afin d’assurer une navigation fluide et clair dans notre application.

Ce Sprint a été présenté dans la réunion de « Sprint Review » ce qui nous a permis la
réalisation d’un contrôle de qualité par rapport à la DoD. Comme d’habitude, cette réunion était
à la présence de l’équipe du projet, le PO ainsi que le chef de département mobile comme
représentant des stakeholder.

Le chapitre suivant, présente le cinquème Sprint « Écran d’inscription, connexion et

profil ».

Page 68 sur 116

 Chapitre 7

7 Sprint 5 : Écran d’Inscription, Connexion et

Profil « HomeShop »

Plan

Introduction...................................................................................................................................... 70
7.1 HomeShop Sprint 5 planning ............................................................................................ 70
7.2 Analyse ................................................................................................................................. 71
7.3 Conception ........................................................................................................................... 73
7.4 Réalisation ........................................................................................................................... 76
Conclusion ........................................................................................................................................ 80
Chapitre 7 . Sprint 5 : Écran d’Inscription, Connexion et Profil « HomeShop »

Introduction

Ce Chapitre fait l’objet d’une présentation du cinquième Sprint du projet « HomeShop »

qui est la création et implémentation des écrans d’accès au compte et profil. L’étude de ce Sprint
couvre l’analyse, la conception, la réalisation, l’intégration et les tests fonctionnelles.

7.1 HomeShop Sprint 5 planning

7.1.1 Objectif du sprint 5

Ce Sprint a pour objectif, dans un premier lieu, la préparation des écrans de connexion
au compte, de création d’un nouveau compte, d’accès au compte et du profil utilisateur d’une
maniéré statistique englobant toute les fonctionnalités demandées. Ensuite, le développement
du comportement dynamique des « User Stories » prioritaires demandées.

7.1.2 Sprint Backlog du Sprint 5

Le tableau 7-1 présente un raffinement des « User Stories » prioritaires de l’écran

d’inscription, d’accès au compte et du profil utilisateur en ensemble de « Tasks » :

Tableau 7-1 : Sprint Backlog du Sprint 5

ID User Story ID Task Task Complexity

1.1 Création de l’interface graphique. S

Ajout de l’auto-layout pour

1.2 adaptation sur tout type d’Iphone M

Implémentation du modèle
1.3 « Client » XS
En tant que visiteur, je veux Test des requêtes permettant la
1 m’inscrire dans l'application, afin 1.4 création d’un nouveau utilisateur S
d’effectuer des achats en ligne. Implémentation des managers de
1.5 type REST pour la communication L
avec la partie frontale.
Implémentation des contrôleurs
1.6 pour la consommation des L
managers crées.
Implémentation des messages et
1.7 signes visuelles indiquant la M
terminaison des actions.

1.1 Création de l’interface graphique. S

En tant que client, je veux accéder à Ajout de l’auto-layout pour

2 1.2 adaptation sur tout type d’Iphone M
mon profil, afin de pouvoir
modifier mes coordonnées. Implémentation du code nécessaire
1.3 pour la récupération d’un S
« Customer Token »

Page 70 sur 116

Chapitre 7 . Sprint 5 : Écran d’Inscription, Connexion et Profil « HomeShop »

Test des requêtes permettant la

1.4 mise à jour des données d’un S
utilisateur.
Implémentation des managers de
1.5 type REST pour la communication L
avec la partie frontale.
Implémentation des contrôleurs
1.6 pour la consommation des L
managers crées.
Implémentation des messages et
1.7 signes visuelles indiquant la M
terminaison des actions.

7.2 Analyse

7.2.1 Raffinement et description des cas d’utilisations

• Inscription :

Figure 7-1 : Raffinement de cas d’utilisation « Inscription »

L’utilisation de l’application par un visiteur est un peu limité. Il ne dispose pas d’un
accès complet à toutes ses fonctionnalités c’est pour cela il est invité dans certain cas critique
à la sécurité de ses données de s’inscrire en créant un compte. Le tableau 7-2 présente une
description textuelle minimiser de ce cas d’utilisation :

Tableau 7-2 : Description textuelle du cas d’utilisation « Inscription »

Titre : S’inscrire
Acteur : Visiteur.
Résumé : Ce CU permet à l’acteur de créer un compte afin de pouvoir accéder aux fonctionnalités qui exigent
une authentification.
Pré-condition :
- L’utilisateur possède une connexion internet.
- L’utilisateur possède un mail
Post-condition :
- Compte crée.

Page 71 sur 116

Chapitre 7 . Sprint 5 : Écran d’Inscription, Connexion et Profil « HomeShop »

• Authentification et gestion de profil :

Figure 7-2 : Raffinement du cas d’utilisation « Gestion du compte »

Une fois le visiteur a créé son compte, il peut se connecter à son compte, et par la suite
il pourra accéder à son profil afin de consulter ou modifier ses données personnelles.

Les tableaux 7-3 et 7-4 forment une description textuelles des cas d’utilisation figurant
dans la figure 7-2 :

Tableau 7-3 : Description textuelle de cas d’utilisation « Authentification »

Titre : Authentification
Acteur : Client.
Résumé : Ce CU permet à l’acteur d’accéder à son compte.
Pré-condition :
- L’utilisateur possède une connexion internet.
- L’utilisateur possède un compte sur l’application.
Post-condition :
- Accès au compte.

Tableau 7-4 : Description textuelle de cas d’utilisation « Gestion du compte »

Titre : Gérer compte

Acteur : Client.
Résumé : Ce CU permet à l’acteur la gestion de son compte à travers la modification de son mot de passe.
Pré-condition :
- L’utilisateur possède une connexion internet.
- L’utilisateur possède un compte sur l’application.
- L’utilisateur est connecté à son compte
Post-condition :
- Compte mis à jour.

7.2.2 Proposition des maquettes

La figure 7-3 représente une vue préliminaire des écrans de connexion au compte, de
création d’un nouveau compte, d’accès au profil utilisateur. Ces maquettes forment une idée
générale sur les fonctionnalités et non pas une représentation final des interfaces mobiles.

Page 72 sur 116

Chapitre 7 . Sprint 5 : Écran d’Inscription, Connexion et Profil « HomeShop »

Figure 7-3 : Maquettes « Écran d’inscription, de connexion et de profil utilisateur »

7.3 Conception

Pour la conception du cinquième Sprint, nous avons fait recours au diagramme d’activité
et au diagramme de classes.

7.3.1 Diagramme d’Activité

La figure 7-4 présente le diagramme d’activité du cas d’utilisation « S’authentifier » afin

de mieux comprendre le déroulement de ce cas d’utilisation :

Page 73 sur 116

Chapitre 7 . Sprint 5 : Écran d’Inscription, Connexion et Profil « HomeShop »

Figure 7-4 : Diagramme d’activité du cas d’utilisation « Authentification »

Le diagramme d’activité ci-dessus montre la génération d’un « Customer Token » ou

« jeton d’identification de client », il est équivalent à une clé privé utilisée dans les cas où nous
demandons des données côté client qui nécessite obligatoirement une authentification. C’est
une sorte de renforcement de sécurité en cas d’accès au compte.

7.3.2 Diagramme de classes

La figure 7-5 présente l’incrément du diagramme de classes de ce Sprint :

Page 74 sur 116

Chapitre 7 . Sprint 5 : Écran d’Inscription, Connexion et Profil « HomeShop »

Figure 7-5 : Incrément du diagramme de classe du Sprint 5

Page 75 sur 116

Chapitre 7 . Sprint 5 : Écran d’Inscription, Connexion et Profil « HomeShop »

7.4 Réalisation

7.4.1 Outils

De même durant ce Sprint on a fait recours aux outils « Postman » et « Alamofire »

pour le test et l’exécution des requêtes http, « Sketch » et « prepo » pour la création et design
des interfaces graphique.

7.4.2 Captures d’écran de l’incrément 5 potentiellement livrable

Durant cette partie, nous démontrons les résultats de ce sprint à travers la présentation
de quelques captures d’écran de l’incrément réalisé.

La figure 7-6, présente l’incrément potentiellement livrable de la section profil de

« HomeShop », l’écran n’apparait pas complet car il sera construit au fur et à mesure durant
l’avancement dans les Sprints :

Bouton permet l’accès aux

paramètres du compte une fois
connecté.

Bouton permet l’accès au compte

Partie réservée aux

incréments des Sprints
suivants

Figure 7-6 : Incrément de l’écran de Profil du Sprint 5

Page 76 sur 116

Chapitre 7 . Sprint 5 : Écran d’Inscription, Connexion et Profil « HomeShop »

La figure 7-7 présente les écrans de connexion et de création d’un compte de notre
application « HomeShop » :

En appuyant sur ce bouton

l’écran de la création d’un
nouveau compte s’affichera

Figure 7-7 : Écrans d’inscription et de connexion « HomeShop »

Page 77 sur 116

Chapitre 7 . Sprint 5 : Écran d’Inscription, Connexion et Profil « HomeShop »

La figure 7-8 décrit le déroulement de processus de création d’un compte :

Figure 7-8 : Processus de création d’un Compte sur « HomeShop »

Page 78 sur 116

Chapitre 7 . Sprint 5 : Écran d’Inscription, Connexion et Profil « HomeShop »

La figure 7-9 décrit le déroulement de processus de connexion au compte :

Figure 7-9 : Processus d’accès au Compte sur « HomeShop »

Page 79 sur 116

Chapitre 7 . Sprint 5 : Écran d’Inscription, Connexion et Profil « HomeShop »

La figure 7-10 présente l’écran de gestion d’accès au paramètres du compte pour

modification ou déconnexion du compte :

Figure 7-10 : Écrans de gestion du compte sur « HomeShop »

Conclusion

Durant ce Sprint, nous avons effectué la conception et l’implémentation des écrans

compte et profil en tant qu’application du premier, deuxième et troisième critères de notre DoD.

Ce Sprint a été présenté dans la réunion de « Sprint Review » ce qui nous a permis la
réalisation d’un contrôle de qualité par rapport à la DoD.

Le chapitre suivant fait l’objet du dernier Sprint « Processus de passage des commandes
et écran d’historique ».

Page 80 sur 116

 Chapitre 8

8 Sprint 6 : Processus de Passage de

Commande et Écran d’Historique

Plan

Introduction...................................................................................................................................... 82
8.1 HomeShop Sprint 6 planning ............................................................................................ 82
8.2 Analyse ................................................................................................................................. 83
8.3 Conception ........................................................................................................................... 85
8.4 Réalisation ........................................................................................................................... 87
Conclusion ........................................................................................................................................ 91
Chapitre 8 . Sprint 6 : Processus de Passage de Commande Et Écran d’Historique

Introduction

Ce Chapitre fait l’objet d’une présentation du sixième et dernier Sprint de la première

release du projet « HomeShop » qui est le développement du processus de passage d’une
commande et la création des écrans nécessaire pour l’ajout d’une adresse et la consultation de
l’historique des commandes passées. L’étude de ce Sprint couvre l’analyse, la conception, la
réalisation, l’intégration et les tests fonctionnelles.

8.1 HomeShop Sprint 6 planning

8.1.1 Objectif du Sprint 6

Ce Sprint a pour objectif, de Développer le processus de passage de commande et

l’écran de l’historique toute en assurant le comportement dynamique des « User Stories »
prioritaires demandées.

8.1.2 Sprint Backlog du Sprint 6

Le tableau 8-1 présente un raffinement des « User Stories » à développer au cours de ce

Sprint en ensemble de « Tasks » :

Tableau 8-1 : Sprint Backlog du Sprint 6

ID User Story ID Task Task Complexity

Implémentation du modèle
1.1 « Adresse » XS
Test des requêtes permettant la
1.2 création d’une adresse de livraison S
et le passage d’une commande
En tant que client, je veux passer Implémentation des managers de
1
des commandes, afin que mes 1.3 type REST pour la communication L
commandes puissent être avec la partie frontale.
expédiées. Implémentation des contrôleurs
1.4 pour la consommation des L
managers crées.
Implémentation des messages et
1.5 signes visuelles indiquant la M
terminaison des actions.

2.1 Création de l’interface graphique. S

Ajout de l’auto-layout pour
2.2 adaptation sur tout type d’Iphone M
En tant que client, je veux voir Implémentation du modèle
2.3 « commande » XS
2 toutes mes commandes, afin de
suivre leurs états.. Test des requêtes permettant la
2.4 récupération des données des S
commandes
Implémentation des managers de
2.5 type REST pour la communication L
avec la partie frontale.

Page 82 sur 116

Chapitre 8 . Sprint 6 : Processus de Passage de Commande Et Écran d’Historique

Implémentation des contrôleurs

2.6 pour la consommation des L
managers crées.
Implémentation des messages et
2.7 signes visuelles indiquant la M
terminaison des actions.

8.2 Analyse

8.2.1 Raffinement et description des cas d’utilisations

• Passage d’une commande

Figure 8-1 : Raffinement de cas d’utilisation « Passage d’une commande »

Afin de pouvoir passer une commande, le client doit obligatoirement avoir accès à son
compte et disposer d’une adresse de livraison. Le tableau 8-2 représente une description
textuelle détaillé du processus de passage d’une commande :

Tableau 8-2 : Description textuelle détaillée du cas d’utilisation « Passage d’une commande »

Titre : Passage d’une commande.

Acteur : Client.
Résumé : Ce CU permet à l’acteur de passer une commande en validant le contenu de son panier.
Pré-condition :
- L’utilisateur possède une connexion internet.
- Le panier comporte des articles.
Scénario nominal 1 :
01. Le système affiche le contenu et le prix total du panier à l’utilisateur.
02. L’utilisateur choisit valider son panier.
03. Le système vérifie si l’utilisateur est connecté à son compte.
04. Le système vérifie si l’utilisateur possède une adresse de livraison.
05. L’utilisateur confirme son adresse de livraison.
06. Le système finalise la procédure de passage d’ordre.
07. Le système renvoie l’utilisateur vers l’écran de panier avec un contenu vide et total à zéro.
Scénario alternatif :
A1. L’utilisateur est connecté
- A1 se déclenche au point 03 du scénario nominal
9. L’utilisateur a accès à son compte.
Le scénario nominal reprend du point 04.
A2. L’utilisateur est non connecté
- A2 se déclenche au point 03 du scénario nominal
9. Le système redirige l’utilisateur vers l’écran de connexion à son compte.
Le scénario nominal reprend du point 03.
A3. L’utilisateur possède une adresse de livraison
- A3 se déclenche au point 04 du scénario nominal
9. Le système rempli les champs d’adresse par les données de l’adresse disponible.
Le scénario nominal reprend du point 05.

Page 83 sur 116

Chapitre 8 . Sprint 6 : Processus de Passage de Commande Et Écran d’Historique

A3. L’utilisateur ne possède pas une adresse de livraison

- A3 se déclenche au point 04 du scénario nominal
9. Le système donne la main à l’utilisateur de remplir les champs de l’adresse pour créer une
nouvelle adresse.
Le scénario nominal reprend du point 05.
Scénario d’erreur :
E1. Connexion internet interrompue
- E1 peut se déclencher à tous point du scenario nominal.
9. Le système informe l’utilisateur et lui demande de ressayer ultérieurement.
E2. Le système n’a pas pu finaliser le processus de passage du commande.
- E2 peut se déclencher au point 06 du scenario nominal.
9. Le système informe l’utilisateur et lui demande de ressayer ultérieurement.
Post-condition :
- Commande passée

• Consultation de l’historique des commande

Figure 8-2 : Raffinement du cas d’utilisation « Consultation de l’historique des commandes »

Une fois l’utilisateur a passé sa commande, il pourra consulter son état dans
l’historique des commandes passées. Le tableau 8-3 présente une description textuelle
minimiser de cas d’utilisation « Consulter l’historique des commandes » :

Tableau 8-3 : Description textuelle du cas d’utilisation « Consultation de l’historique des commandes »

Titre : Consulter l’historique des commandes passées

Acteur : Client.
Résumé : Ce CU permet à l’acteur de consulter l’historique et l’état des commandes passées.
Pré-condition :
- L’utilisateur possède une connexion internet.
- L’utilisateur possède un compte sur l’application.
- L’utilisateur est connecté à son compte
- L’utilisateur a déjà passé au moins une commande
Post-condition :
- État des commandes consulté.

8.2.2 Proposition des maquette

Les maquettes dans la figure 8-3 montre une idée générale sur les fonctionnalités à
ajouter dans la section du profil de l’utilisateur et la figure 8-4 montre une vue préliminaire de
l’interface d’ajout d’une adresse :

Page 84 sur 116

Chapitre 8 . Sprint 6 : Processus de Passage de Commande Et Écran d’Historique

Figure 8-3 : Maquette « Écran du profil » modifiée Figure 8-4 : Maquette « Écran d’ajout d’adresse »

8.3 Conception

Pour la conception du sixième Sprint, nous avons fait recours au diagramme de temps et
au diagramme de classes.

8.3.1 Diagramme de temps

Les diagrammes de temps du langages UML sont utilisés pour explorer le comportement
d’un objets dans son système durant une période déterminée. La figure 8-5 ci-dessous montre
le comportement de l’objet « Panier » :

Figure 8-5 : Diagramme de temps de l’objet « Panier »

En utilisant l’API Moltin, le contenu du panier reste valable pendant sept jour. Si le
client passe sa commande pendant cette période l’objet se transforme en un objet
« Commande », si non le contenu du panier va disparaître après cette période.

8.3.2 Diagramme de classes

La figure 8-6 représente le diagramme de classes en ajoutant les nouvelles classes

intervenantes dans ce Sprint :

Page 85 sur 116

Chapitre 8 . Sprint 6 : Processus de Passage de Commande Et Écran d’Historique

Figure 8-6 : Incrément du diagramme de classe du Sprint 6

Page 86 sur 116

Chapitre 8 . Sprint 6 : Processus de Passage de Commande Et Écran d’Historique

8.4 Réalisation

8.4.1 Outils

Les outils « Postman », « Alamofire », « Sketch » et « prepo » nous ont accompagné

tout au long de la réalisation des incréments de notre application « HomeShop ».

8.4.2 Captures d’écran de l’incrément 6 potentiellement livrable

Durant cette partie, nous démontrons les résultats de ce sprint à travers la présentation
de quelques captures d’écran de l’incrément réalisé.

La figure 8-7 présente l’écran de l’ajout d’une adresse de livraison. Si le client dispose
déjà d’une adresse, les données des champs seront remplit automatiquement par l’application.

Figure 8-7 : Écran d’ajout d’une adresse de livraison

Page 87 sur 116

Chapitre 8 . Sprint 6 : Processus de Passage de Commande Et Écran d’Historique

Une fois le client a confirmé sa commande, le processus du passage d’une commande

se déclenche. La figure 8-8 montre le déroulement de ce processus :

Figure 8-8 : Processus de passage du commande pour un client qui a une adresse de livraison

Page 88 sur 116

Chapitre 8 . Sprint 6 : Processus de Passage de Commande Et Écran d’Historique

La figure 8-9 montre le cas où le client ne dispose pas encore d’une adresse de livraison,
il devrai remplir les champs afin de pouvoir passer sa commande :

Champ rempli grâce à l’intégration de

l’incrément du Sprint précèdent
« Comptes et Profils »

Figure 8-9 : Processus de passage du commande pour un client qui n’a pas encore une adresse de livraison

Page 89 sur 116

Chapitre 8 . Sprint 6 : Processus de Passage de Commande Et Écran d’Historique

La figure 8-10 montre la finalisation de l’écran de la section profil après l’intégration

des user stories de ce Sprint :

Bouton permet l’accès à l’historique

des commandes passées

Tous les autres boutons feront

l’objet d’une deuxième release.

Figure 8-10 : Écran de profil utilisateur final de « HomeShop »

Page 90 sur 116

Chapitre 8 . Sprint 6 : Processus de Passage de Commande Et Écran d’Historique

La figure 8-11 présente l’écran de consultation de l’historique des commandes :

Figure 8-11 : Écran de l’historique des commandes de « HomeShop »

Conclusion

Durant ce Sprint, nous avons effectué la conception et l’implémentation des écrans

compte et profil en tant qu’application du premier, deuxième et troisième critères de notre DoD.

Ce Sprint a été présenté dans le cadre d’une réunion de fin de la première release durant
la réunion de la « Sprint Review ». Cette réunion était à la présence de l’équipe du projet, le PO
ainsi que le chef de département mobile comme représentant des stakeholder.

Page 91 sur 116

 Chapitre 9

9 Synthèse de la Release : Préparation au

Déploiement de « HomeShop »

Plan

Introduction...................................................................................................................................... 93
9.1 Lunch Screen de l’application ........................................................................................... 93
9.2 Icône de l’application ......................................................................................................... 93
9.3 Diagramme de classes final ................................................................................................ 94
9.4 Diagramme de paquetages ................................................................................................. 97
9.5 Diagramme de déploiement ............................................................................................... 98
9.6 Analyse SWOT .................................................................................................................... 98
9.7 Product Backlog de la deuxième release ........................................................................... 99
Conclusion ........................................................................................................................................ 99
Chapitre 9 . Synthèse de la Release: Préparation au Déploiement de « HomeShop »

Introduction

Ce dernier chapitre tente d’aborder la phase de synthèse de la première release développée

tout au long de la période de notre stage. Tous les sprints précédents ont abouti à des incréments
potentiellement livrables, mais à présent nous arrivons à la mise en exploitation d'une première
version de produit. Nous y allons tout d’abord, présenter l’écran de lancement et l’icône de
notre application HomeShop. Ensuite, nous allons présenter le diagramme de classes final de
la release, le diagramme de paquetage et le diagramme de déploiement. Finalement, nous allons
clôturer ce chapitre par une analyse SWOT6 du projet et un Product Backlog englobant le travail
à poursuivre et démarrant la maintenance évolutive et perfective du produit.

9.1 Lunch Screen de l’application

« Lunch Screen » ou écran de lancement apparaît instantanément au démarrage de

l’application. Il est rapidement remplacé par le premier écran de l’application, ce qui donne
l'impression que l’application est rapide et réactive. La figure 9-1 présente notre écran de
lancement de l’application :

Figure 9-1 : Écran de lancement « HomeShop »

9.2 Icône de l’application

Pour le déploiement d’une application mobile iOS sur l’« App Store », il est obligatoire
d’attribuer une icône pour l’application. Elle formera l’ image de marque initial de l’application.
La figure 9-2 présente l’icône de « HomeShop » :

6
SWOT (Strengths / Weaknesses / Opportunities / Threats) ou FFOM en français ( Forces/ Faiblesses /
Opportunités / Menaces) : une méthode permet d’identifier les facteurs internes et externes favorables et
défavorables à la réalisation d’un projet ou produit.

Page 93 sur 116

Chapitre 9 . Synthèse de la Release: Préparation au Déploiement de « HomeShop »

Figure 9-2 : Logo « HomeShop »

9.3 Diagramme de classes final

L’avancement dans les Sprints toute au long de la réalisation du projet a permis de

construire pas à pas le digramme de classes afin d’arriver à une dernière version du diagramme
qui est présenté et détaillé respectivement dans la figure 9-3 et le tableau 9-1 ci-dessous. Certes,
l’avancement dans l’application en abordant une deuxième release peut également agrandir le
nombre de classe et mener vers d’autre version du diagramme.

Page 94 sur 116

Chapitre 9 . Synthèse de la Release: Préparation au Déploiement de « HomeShop »

Figure 9-3 : Diagramme de classe de la Release

Page 95 sur 116

Chapitre 9 . Synthèse de la Release: Préparation au Déploiement de « HomeShop »

Tableau 9-1 : Dictionnaire de diagramme de classe final

Classes Description
Classe non persistante représente un utilisateur de l’application qui ne possède pas encore un
Visitor
compte.
Classe non persistante gérée dans la session, comporte l’identifiant unique pour un visiteur et sa
Implicit Token
date d’expiration.
Classe persistante contient toutes les informations d’un utilisateur inscrit dans l’application et qui
Customer
possède un compte.
Classe non persistante gérée dans la session, comporte l’identifiant d’authentification d’un client
CustomerToken
et sa date d’expiration.
Classe persistante contient toutes les informations concernant une catégorie, ainsi que les
Category
méthodes à effectuer par l'administrateur pour la gestion des catégorie.
Classe persistante contient toutes les informations concernant un produit, ainsi que les méthodes
Product
à effectuer par l'administrateur pour la gestion des produit.
Classe non persistante gérée dans la session représente un exemplaire d’un produit qui peut être
Item
ajouté, retiré du panier et passé en commande.
Classe non persistante gérée dans la session AR, représente l’équivalent en 3D d’un produit mis
VirtualObject
en vente.
SceneAR Classe non persistante gérée dans la session AR, contient toutes les informations d’une Scène AR.
Photo Gallery Classe non persistante représente l’objet de la galerie de photos sur l’appareil mobile.
Cart Classe non persistante gérée dans la session contient toutes les informations concernant un panier.
Classe d’association entre un panier et un exemplaire de produit non persistante, contient toutes
CartLine
les informations d’une ligne de panier.
Order Classe persistante contient toutes les informations concernant un panier.
Classe d’association non persistante entre un ordre et un exemplaire de produit non persistante,
OrderLine
contient toutes les informations d’une ligne de commande.
Address Classe persistante contient toutes les informations concernant une adresse de livraison d’un client.

Page 96 sur 116

Chapitre 9 . Synthèse de la Release: Préparation au Déploiement de « HomeShop »

9.4 Diagramme de paquetages

Figure 9-4 : Diagramme de paquetage de la release

Page 97 sur 116

Chapitre 9 . Synthèse de la Release: Préparation au Déploiement de « HomeShop »

Ci-dessus, la figure 9-4 montre une vision de décomposition de notre diagramme de

classe en diagramme de paquetage, où nous avons identifié trois paquets :

• Utilisateurs et droits d’accès : englobe toute les informations des utilisateurs de

l’application.
• Réalité augmentée : englobe le volet de test des modèles 3D
• M-Commerce : englobe le volet de l’m-commerce

9.5 Diagramme de déploiement

Un diagramme de déploiement représente le déploiement physique des différents

modules intervenant dans le système. La figure 9-5 présente le diagramme de déploiement de
« HomeShop » sur l’App Store de Proxym-IT:

Figure 9-5 : Diagramme de déploiement

9.6 Analyse SWOT

Il s’agit d’une méthode qui combine l'étude des forces et des faiblesses d'une organisation,
d'un territoire, d'un secteur ou d’un produit, avec celle des opportunités et des menaces de son
environnement. Le tableau 9-2 présente le résultat d’analyse des applications basé sur réalité́
augmentée tel que « HomeShop » :

Tableau 9-2 : Analyse SWOT de « HomeShop »

Force Faiblesse

Nombreux domaines d’application Manque de ressource et documentation

Production à la demande
Nouvelle technologie

Page 98 sur 116

Chapitre 9 . Synthèse de la Release: Préparation au Déploiement de « HomeShop »

Menace Opportunité

Les innovations technologiques qui peuvent Grosse demande des applications AR à

substituer la réalité augmentée. l’échelle internationale.
Technologie pas encore connu chez les Nombre limité des concurrents en Tunisie
Tunisiens

9.7 Product Backlog de la deuxième release

Notre stage a duré quatre mois, cette période a suffi d’aboutir une première release. Le
tableau 9-4 présente le Product Backlog contenant les user stories qui forment l’objet d’une
deuxième release que Proxym-IT prendra la relève de poursuivre :

Tableau 9-3 : Product Backlog du deuxième release

ID Feature/Epic User Story Priority

En tant que visiteur, je veux chercher

et filtrer les articles, afin de trouver ce Should
que je veux plus rapidement.
1 Écran d’accueil
En tant que visiteur, je veux voir les
articles en promotion, afin de profiter Could
de l'occasion.
En tant que client, je souhaite ajouter
des produits à ma liste de favoris, afin Should
de pouvoir les commander plus tard.
Scène de test avec la En tant que visiteur, je veux accéder à
2
réalité augmentée la scène de RA avec l'option
d'adaptation de plan afin de pouvoir Could
tester l'adaptabilité des modèles dans
le plan détecté.
En tant que client, je veux accéder à
Écran de gestion des mes favoris, afin de les consulter,
3 Could
favoris supprimer un article ou ajouter des
articles au panier.
En tant que visiteur, je veux accéder à
l’ensemble des articles, afin de
4 Écran des articles variés Could
sélectionner les produits que je
souhaite tester en RA.
En tant que client, je veux avoir accès
aux des différentes méthodes de
5 Processus de paiement Would
payement, afin de payer ma
commande.

Conclusion

Ce chapitre nous a permis de finaliser la réalisation de l’application en tant que projet de

fin d’étude et d'avoir une vision plus claire sur le futur du projet en tant qu’application
commercialisé sur le marché.

Page 99 sur 116

Conclusion Générale

Conclusion Générale

La réalité augmentée est une technologie riche et prometteuse qui touche tous les
domaines. Les principaux fabricants de smartphones (Apple, Samsung et Huawei) pensent que
ce marché pourrait atteindre les 60 milliards de dollars d’ici à 2020.

L’objectif de ce projet est de concevoir et développer une application mobile sous la

plateforme iOS basée sur réalité augmenté, elle représente un store virtuel de meubles de
maison. En adoptant le cadre de processus Scrum de la méthodologie Agile dans le
développement de notre application, nous avons pu avancer rapidement dans le projet tout en
validant les incréments entre les différents Sprints par des tests de fonctionnalités.

Sur le plan professionnel, l’avantage de ce projet fut multiple. Il nous a permis de

collaborer autour d’un projet assez important, de découvrir qu’est-ce que le travail en tant
qu’équipe Scrum sur un terrain professionnel et de perfectionner nos compétences en
développement mobile iOS, en analyse, en conception ainsi qu’en communication.

Nous avons trouvé cette mission très intéressante et enrichissante, puisqu’il s’agit d’un
domaine peu connu où nous aimerons approfondir nos compétences. Au terme de ce projet de
fin d’études, nous estimons que nous avons pu atteindre les objectifs que nous nous sommes
fixés. Toutefois, des perspectives d’amélioration et d’évolution de la version développée se
posent afin d’aboutir à une deuxième release qui inclue :

• L’implémentation des « User Stories » qui forme l’objet d’une deuxième release cité
auparavant dans le chapitre de synthèse de la release.
• L’implémentation d’un module de recommandation des articles automatique en se
basant sur l’historique des commandes passées.
• Le développement d’un module de paiement sécurisé en utilisant la technologie « Block
Chain ».

Finalement, Ce stage a vraiment confirmé nos ambitions futures d’exercer un métier dans
le domaine d’ingénierie informatique.

Page 100 sur 116

 Webographie
[1] Proxym-Group: http://www.proxym-group.com/

[2] FEVAD: https://www.fevad.com/

[3] CSA: https://www.csa.fr/

[4] Enquête FEVAD du 5 février 2019 https://www.fevad.com/13810-2/

[5] Médiamétrie: https://www.mediametrie.fr/

[6] Produits les plus achetés sur mobile en 2018: https://www.ecommercemag.fr/Thematique/techno-

ux-1226/Breves/2018-commerce-sous-projecteurs-331925.htm#UUST0uuMWIuMBShE.97

[7] Experts AR : https://blog.marketing-management.io/e-commerce-mobile-2018

[8] AR vs VR vs MR: https://www.fi.edu/difference-between-ar-vr-and-mr

[9]Historique AR: https://www.artefacto-ar.com/realite-augmentee/

[10]Définition Scrum https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-

French.pdf (Page 3, section « Définition de Scrum »)

[11]Figure processus Scrum: https://brainhub.eu/blog/differences-lean-agile-scrum/

[12]DevTeam Scrum: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-

French.pdf (Page 7, section « Taille d’équipe de développement » )

[13]Apple MVC, Figure MVC traditionnelle , Figure Apple MVC : https://medium.com/ios-os-x-

development/ios-architecture-patterns-ecba4c38de52

[14] MoSCoW: https://medium.com/product-academy-thiga/priorisez-votre-backlog-le%C3%A7on-6-

6795c006326e

[15] Defintion of Done Scrum : https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-

Guide-French.pdf (Page18 section « Defintion de “Fini” »)

[16] T-ShirtSize: https://www.nutcache.com/fr/blog/methodes-estimation-agiles/

[17] E-Commerce plateformes: https://www.codeinwp.com/blog/best-ecommerce-platform/

[18] Experts e-commerce: https://www.quora.com/What-do-you-think-of-API-oriented-eCommerce-

platforms-like-Moltin-and-Marketcloud-instead-of-products-like-WooCommerce-and-
Magento/answer/Jeff-Finkelstein-1

[19] Apple Developer: https://developer.apple.com/

[20] Documentation Unity : https://docs.unity3d.com/Manual/index.html

Page 101 sur 116

 10 Liste des Abréviations

- AR / RA Augmented Reality / Réalité augmenté. 7, 17, 19, 20, 28, 29, 30, 34, 43, 44,
45, 48, 99, 101.
- VR Virtual Reality. 7, 101.
- MR Mixed Reality. 7, 101.

- M-Commerce Mobile Commerce. 6, 7, 9, 98.

- FEVAD Fédération du e-commerce et de la vente à distance. 6, 101.

- CSA Conseil Supérieur de l’Audiovisuel. 6, 101.

- PO Product Owner. 11, 14, 19, 25, 29, 34, 42, 44, 46, 48, 58, 59, 68, 91.
- SM Scrum Master. 11.
- DevTeam Develepoment Team. 11, 29, 30, 46, 48, 101.

- PB Product Backlog. 12, 19, 41.

- PBI Product Backlog Item. 19.
- SB Sprint Backlog. 12.
- DoD Defintion of Done. 23, 34, 42, 55, 59, 68, 80, 91.

- IT Technologies de l'information. 4.
- TIC Technologies de l'information et de la Communication. 19.
- Iot Internet of Things. 5.

- MVC Model View Controller. 15, 16.

- UML Unified Modeling Language. 21, 85.

- HTTP Hypertext Transfer Protocol. 18, 39, 51, 66, 76.

- REST Representational State Transfer. 1, 26, 27, 28, 36, 39, 44, 45, 61, 70, 71, 82.
- API Application Programming Interface. 1, 18, 19, 24, 26, 27, 29, 30, 32, 39, 85.
- URL Uniform Resource Locator. 31, 34.

- Apple UI Apple User Interface. 29, 30.

- IDE Integrated Development Environment. 25.

- PaaS Platform as a service. 28.

- RDS Relational Database Service. 32.
- S3 Simple Storage Service. 32.

- SWOT Strengths / Weaknesses / Opportunities / Threats. 93, 98.

Page 102 sur 116

 Résumé

Ce travail s'inscrit dans le cadre de l’accomplissement de notre stage de fin de nos études
en ingénierie à l’Institut supérieur de l'informatique et des technologies de la communication
(ISITCom). Le stage, a eu lieu dans la société Proxym-IT ayant comme objectif le
développement d’une application mobile, compatible avec tous les dispositifs iOS, qui aide les
clients des agences immobilières à tester des produits et des meubles dans leurs maisons avant
de commander quoi que ce soit. Grâce à la nouvelle technologie de la "Réalité Augmentée" on
a pu donner de très bons résultats et une vision réaliste avec des calculs précis. Une application
simple à manipuler. Avec un simple clic tout sera placer automatiquement. Trouvez le plaisir
de tester votre fourniture immobilière sans même sortir de votre domicile!

Mots clés : iOS, Réalité augmentée, ARKit, SceneKit, API Moltin, Web services.

Abstract

This work is part of the accomplishement of our internship graduation at the Higher
Institute of Computer Science and Communication Technologies (ISITCom). The course was
held in the company Proxym-IT to develop a mobile application, compatible with all iOS
devices, that helps real estate agency customers to test products and furniture in their homes
before ordering anything. Thanks to the new technology "augmented reality" we have been
able to reach encouraging results and a realistic vision with precise calculations. A simple
application to handle. With a simple click, everything will be automatically placed, feel free to
enjoy getting your furniture without even leaving home !

Key words : iOS, Réalité augmentée, ARKit, SceneKit, API Moltin, Web services.