Tuni Shop

DEDICATION
Avec l’expression de ma reconnaissance, je didié ce modeste travail à ce ceux qui, quels que
soient les termes embrassés, je n’arriverais jamais à leur exprimer mon amour sincère
À l’homme, mon précieux offre du dieu, qui doit ma vie, ma réussite et tout mon respect.Tu as
toujours été à mes côtes pour me soutenir et m’encourager. Que ce travail traduit ma gratitude et
mon affection
À mon trés cher père, Abdelwaheb.
À la femme qui a souffert sans me laisser souffrir, qui n’a jamais dit non ames exigence et n’a
épargné aucun efort pour me rendre heureux
À mon adorable mère, Samia.
À mes deux merveilleuses sœurs Mariem & Zaineb. Je tiens à vous dédier ces mots empreints
d’amour et d’admiration. Vous êtes les personnes les plus spéciales dans ma vie et je suis
profondément reconnaissant de vous avoir comme sœurs.
À ma chère grand mère Hayet, Chaque moment partagé avec toi est un trésor précieux, rempli
de souvenirs joyeux et de précieuses leçons de vie. Ta générosité sans faille et ton sourire radieux
ont le pouvoir de rendre chaque instant mémorable.
À mes professeurs. Je tiens à exprimer ma profonde gratitude et ma reconnaissance. Leur

dévouement, leur expertise et leur passion pour l’enseignement ont joué un rôle essentiel dans ma
formation académique et personnelle.
Ezzddinne Mhamdi
FS-SFAX Page i
DEDICATION
Je voudrais dédier ce modest travail avec le plus grand amour et la plus grande gratitude
À la femme la plus importante de ma vie qui m’a donné tout ce que j’ai aujourd’hui, qui n’avez
jamais douté de mes capacité. Que Dieu vous protège et vous accorde une bonne santé et une
longue vie.
À mon adorable mère, Najiba.
À mon très cher frère Amin et sa belle femme Sameh, ont été mes guides et ma source
d’inspiration, toujours présents pour m’écouter, m’encourager et me fournir un soutien
indéfectible.
À mes merveilleuses sœurs Emna & Salwa & Sana. je dédie ces mots remplis d’affection et
d’admiration. Je suis profondément touchée d’avoir des sœurs aussi merveilleuses que vous, et je
suis ravie de vous avoir à mes côtés.
À mes professeurs, Je tiens à exprimer ma profonde gratitude et ma reconnaissance. Leur
dévouement, leur expertise et leur passion pour l’enseignement ont joué un rôle essentiel dans ma
formation académique et personnelle.
À tous mes amis qui ont été mes compagnons de tous les instants, leurs présence a apporté de
la joie dans ma vie et ont rendu le parcours plus supportable.
Fakhreddine Youssef
FS-SFAX Page ii
REMERCIEMENT
Nous avons un grand plaisir de garder cette page en signe de gratitude et de profonde reconnaissance
à tous ceux qui nous ont aidé de près ou de loin à la réalisation de ce projet.
Nous sommes trés reconnaissant à notre encadrant à la faculté des sciences de sfax, Monsieur
Mohamed Tahar Bhiri, d’avoir accepté de diriger ce travail sans oublier ses conseils et sa participation
régulière au cheminement de ce rapport avec rigeur et bienveillance.
Nous tenons à remercier Monsieur Hedi Manai, notre encadrant professionnel, pour sa disponibilité
tout au long ce stage, ses judicieux conseils et ses encouragements, qu’il trouve ici notre respectueuse
reconnaissance.
Nous tenons à remercier les membres de jury de nous avoir offert l’occasion de présenter notre
projet devant leur honorable assistance et d’avoir accepté d’évaluer ce projet.
FS-SFAX Page iii

TABLE DES MATIÈRES
LISTE DES FIGURES viii
Liste des tableaux ix
LISTE DES ABRÉVIATIONS x
INTRODUCTION GÉNÉRALE xi
1 Etude du projet 2
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Entreprise d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Conseil en cloud computing . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Intégration IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 Inforgérence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.4 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Context du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 Solutions proposées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.2 Identification des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . 8
1.4.3 Identification des besoins non fonctionnels . . . . . . . . . . . . . . . . . 10
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Méthode et outils utilisés 11

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Méthode classique de développement . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Méthode agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
FS-SFAX Page iv
TABLE DES MATIÈRES
2.3.2 Manifeste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.4 Méthode retenue SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Outils logiciels utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 Langage de programmation : Golang . . . . . . . . . . . . . . . . . . . . 16
2.4.1.1 Possibilités vis-à-avis de la programmation synchrone . . . . . . 17
2.4.1.2 Possibilités vis-à-avis de la programmation asynchrone . . . . . 18
2.4.1.3 Possibilités vis-à-avis de la programmation orientée objet . . . . 18
2.4.2 GORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.3 Framework GIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.3.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.3.2 Composantes Framework . . . . . . . . . . . . . . . . . . . . . 21
2.4.4 Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6 Architecture logicielle du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Développement d’une boutique numérique

26
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Fonctionnalités : Backlog product . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Planification des releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 Release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.1 Sprint : Gestion d’authentification . . . . . . . . . . . . . . . . . . . . . . 30
3.4.1.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.1.2 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.1.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.1.4 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . 33
3.4.2 Sprint : Gestion des employés . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.2.2 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.2.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.2.4 Diagramme de séquences . . . . . . . . . . . . . . . . . . . . . 38
3.5 Release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5.1 Sprint : Gestion des boutiques . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5.1.2 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.5.1.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
FS-SFAX Page v
TABLE DES MATIÈRES

3.5.2 Sprint : Gestion des cartes . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5.2.2 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.5.2.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.5.2.4 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . 44
3.6 Release 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.6.1 Sprint : Gestion des messages . . . . . . . . . . . . . . . . . . . . . . . . 45
3.6.1.2 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.6.1.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.6.1.4 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . 47
3.6.2 Sprint : Intégration paiement . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.6.2.2 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.6.2.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4 Documentation 56
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2 Extraction d’un diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3 Documentation Swagger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4 Interfaces Homme-Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
CONCLUSION GÉNÉRALE 71
BIBLIOGRAPHIE 71
FS-SFAX Page vi
LISTE DES FIGURES
1.1 Logo de Tunisian Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Méthode classique de développement . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Itération agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 La méthode SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Logo du language Golang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Exemple d’un programme synchrone . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 Exemple d’un programme concurrent . . . . . . . . . . . . . . . . . . . . . . . . 18
2.7 Quelques caractéristique du concept produit . . . . . . . . . . . . . . . . . . . . . 19
2.8 Quelques caractéristique du concept panier . . . . . . . . . . . . . . . . . . . . . 19
2.9 Exemple d’utlisation de la bibliothèque "Gorm" . . . . . . . . . . . . . . . . . . . 20
2.10 Logo du Framework Gin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.11 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1 Découpage du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Diagramme de séquences « S’incrire » . . . . . . . . . . . . . . . . . . . . . . . 34
3.3 Diagramme de séquences « Rénitialiser mot de passe » . . . . . . . . . . . . . . . 35
3.4 Diagramme de séquences « Gestion des employés » . . . . . . . . . . . . . . . . 38
3.5 Diagramme de séquences « Gestion des boutiques » . . . . . . . . . . . . . . . . 42
3.6 Diagramme de séquences « Gestion des carts » . . . . . . . . . . . . . . . . . . . 45
3.7 Diagramme de séquences « Gestion des messages » . . . . . . . . . . . . . . . . . 48
3.8 Capture d’initialisation de Paymee . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.9 Capture de réponse d’initialisation de Paymee . . . . . . . . . . . . . . . . . . . . 50
3.10 Capture montre que le paiement est réussi . . . . . . . . . . . . . . . . . . . . . . 51
3.11 Capture montre que le paiement est réfusé . . . . . . . . . . . . . . . . . . . . . . 52
3.12 Diagrrame de séquences « Intégration paiement » . . . . . . . . . . . . . . . . . . 54
4.1 Exemple d’extraction d’une classe métier à partir d’une structure . . . . . . . . . . 58

4.2 Exemple d’extraction des méthodes à partir d’une structure . . . . . . . . . . . . . 58
4.3 Exemple d’extraction d’une association à partir du code . . . . . . . . . . . . . . . 59
4.4 Diagramme de classe issu de notre logiciel TuniShop . . . . . . . . . . . . . . . . 60
FS-SFAX Page vii

LISTE DES FIGURES
4.5 Logo du Swagger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.6 la documentation Swagger du sprint "Gestion des employés" . . . . . . . . . . . . 62
4.7 la documentation Swagger détaillé de la fonction «GetAllUsers» . . . . . . . . . . 63
4.8 Informations sur l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.9 Informations personnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.10 Email de vérification de l’inscription . . . . . . . . . . . . . . . . . . . . . . . . 64
4.11 Code de vérification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.12 Mot de passe oublié . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.13 Email de réinitialiser le mot de passe . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.14 Réinitialisation du mot de passe . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.15 Liste des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.16 List des Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.17 Paramètres de boutique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.18 Ajout d’Attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.19 Profil du Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.20 Page d’accueil de boutique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.21 Panier du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
FS-SFAX Page viii

Liste des tableaux
1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Equipe et rôles Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Backlog product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Backlog du Sprint Gestion d’authentification . . . . . . . . . . . . . . . . . . . . . 31
3.3 Test fonctionnel du sprint "Gestion d’authentification" . . . . . . . . . . . . . . . 33
3.4 Backlog du Sprint Gestion des employés . . . . . . . . . . . . . . . . . . . . . . . 36
3.5 Test fonctionnel du sprint « Gestion des employés » . . . . . . . . . . . . . . . . . 37
3.6 Backlog du Sprint « Gestion des boutiques » . . . . . . . . . . . . . . . . . . . . . 40
3.7 Test fonctionnel du sprint « Gestion des boutiques » . . . . . . . . . . . . . . . . . 41
3.8 Backlog du Sprint « Gestion des carts » . . . . . . . . . . . . . . . . . . . . . . . 43
3.9 Test fonctionnel du sprint « Gestion des carts » . . . . . . . . . . . . . . . . . . . 44
3.10 Backlog du sprint Gestion des messages . . . . . . . . . . . . . . . . . . . . . . . 46
3.11 Test fonctionnel du sprint « Gestion des messages » . . . . . . . . . . . . . . . . . 47
3.12 Backlog du sprint « Intégration paiement » . . . . . . . . . . . . . . . . . . . . . . 48
3.13 Test fonctionnel du sprint « Intégration paiement » . . . . . . . . . . . . . . . . . 53
FS-SFAX Page ix
LISTE DES ABRÉVIATIONS
API Application Programming Interface
CI/CD Continuous Integration/Continuous Delivery
DB DataBase
JWT JSON Web Tokens
HTTP Hypertext Transfer Protocol
HTML HyperText Markup Language
ORM Object-Relational Mapping
OOP Object-Oriented Programming
OWASP Open Web Application Security Project
REST Representational state transfer
UML Unified Modeling Language
URL Uniform Resource Identifier
FS-SFAX Page x
INTRODUCTION GÉNÉRALE
De nos jours le commerce électronique est un secteur en pleine expansion qui a révolutionné le
mode de fonctionnement des entreprises dans le monde moderne. Cette technologie de pointe a
permis aux consommateurs de parcourir et d’acheter des produits et des services depuis le confort
de leur domicile, et a ouvert de nouvelles possibilités aux entreprises pour étendre leur portée et
accéder aux marchés mondiaux. À l’ère du numérique, le commerce électronique est devenu une
composante essentielle de l’économie, et son impact sur le monde des affaires ne fera que croître
dans les années à venir.
Malgré son évolution au fil des ans, des améliorations sont encore possibles pour répondre à la
demande sans cesse croissante d’expériences d’achat en ligne. Avec l’essor de la numérisation,
les consommateurs s’attendent à des transactions transparentes et pratiques, et le commerce
électronique doit s’adapter pour répondre à ces besoins. Dans ce cadre et en vue de l’obtention
de notre projet de fin d’études, au sein de l’entreprise Tunisian Cloud, nous avons réalisé une
plateforme e-commerce intitulée TuniShop. Ce projet a pour but de créer une boutique numérique
pour le commerce électronique afin de faciliter les processus de vente des produits. Les clients
peuvent accéder à la boutique depuis différentes plateformes telles que Messenger, Instagram,
Facebook, etc. Lorsqu’un client passe une commande à partir de Facebook, Messenger ou
Instagram, le système enregistre automatiquement le profil du client ainsi que les produits ajoutés
au panier. Par ailleurs, le propriétaire de la boutique peut suivre en temps réel les activités des
paniers de chaque utilisateur grâce à la session client.
FS-SFAX Page xi
INTRODUCTION GÉNÉRALE
Ce rapport comporte quatre chapitres
Le premier chapitre porte sur l’étude de projet. Il débute par une présentation de l’entreprise
d’accueil, puis se concentre sur la problématique rencontrée et la solution proposée. Enfin, il
aborde la capture des besoins, où les différents acteurs sont identifiés, les besoins fonctionnels et
non fonctionnels du projet sont définis.
Le deuxième chapitre de notre projet mettra en lumière la méthodologie et les outils utilisés dans
sa réalisation. Nous commencerons par une analyse critique de la méthode de développement
classique, suivie d’une description détaillée de la méthode SCRUM que nous avons adoptée tout
au long du processus de développement. De plus, nous fournirons une présentation des outils
utilisés ainsi que de l’environnement de travail mis en place. De tels outils sont organisés autour
de langage de programmation Golang et le framwork Gin.
Le troisième chapitre constitue le pilier central de notre rapport, où nous décrivons en détail
les étapes de développement en appliquant soigneusement la méthode agile SCRUM. Nous
commencerons par présenter le backlog product, qui regroupe les fonctionnalités basiques dits
user stories. Ensuite, nous aborderons la planification des releases, décrivant comment nous avons
structuré le travail de notre projet. Enfin, nous approfondirons la définition de nos fonctionnalités,
en fournissant plus des détails .
Le quatrième chapitre a pour objectif de fournir une documentation crédible extraite

essentiellement de notre code source Golang. Une telle documentation concerne les spects
statiques de notre logiciel TuniShop, les sprint et les interfaces d’utilisation de notre logiciel. Pour
y parvenir, nous faisons appel au concept de rétro-ingénierie afin d’extraire systématiquement le
diagramme de classe décrivant les aspects statiques de notre logiciel écrit en Golang.
La conclusion termine ce rapport en résumant les points essentiels de notre stage et en indiquant
quelques prolengements utiles de ce travail.
FS-SFAX Page 1
Chapitre
1
Etude du projet
Sommaire
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Entreprise d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Conseil en cloud computing . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Intégration IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 Inforgérence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.4 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Context du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 Solutions proposées . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.2 Identification des besoins fonctionnels . . . . . . . . . . . . . . . . . . . 8
1.4.3 Identification des besoins non fonctionnels . . . . . . . . . . . . . . . . 10
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
FS-SFAX Page 2
CHAPITRE 1. ETUDE DU PROJET
1.1 Introduction
Dans un premier temps, nous nous présentons les aspects généraux liés à l’entreprise d’accueil :
Tunisian cloud. dans un deuxième temps, nous identifions le contexte de notre projet en insistant
sur les faiblesses des applications actuelles relatives au commerce électronique. En outre, nous
dégageons des solutions possibles aux faiblesses identifiées. Enfin, nous détaillons le cahier
des charges de notre stage compertant les acteurs impliqués et les besoins fonctonnels et non
fonctionnels.
1.2 Entreprise d’accueil
Tunisian Cloud est une entreprise tunisienne spécialisée dans les domaines du Cloud Computing,
la sécurité informatique et l’intégration. Elle est un acteur majeur de la cybersécurité en Afrique,
avec une expertise précieuse dans l’audit de sécurité des systèmes d’information. Elle intervient
dans les aspects préventifs, proactifs et de réponse en offrant une liste complète de services pour de
multiples entreprises. Son expertise et son expérience sont assurées par ses experts de renommée
internationale. La figure 1.1 fournit le logo de l’entreprise Tunisian Cloud [1].
F IGURE 1.1: Logo de Tunisian Cloud
Tunisian Cloud est une société informatique bien établie qui se spécialise dans la fourniture de
solutions informatiques de premier ordre à ses clients. Les services offerts par Tunisian Cloud sont
complets et répondent aux divers besoins d’un large éventail d’entreprises.
FS-SFAX Page 3
1.2.1 Conseil en cloud computing
Tunisian Cloud est reconnu pour son expertise en matière de cloud computing, ayant une
maîtrise complète de cette technologie. Elle possède une connaissance approfondie des différents
modèles et services de cloud computing disponibles pour les entreprises aujourd’hui. Grâce à ses
connaissances approfondies et à son expérience, Tunisian Cloud se positionne en tant que Cloud
Advisor, Cloud Builder, Cloud Application Provider et Cloud Auditor.
1.2.2 Intégration IT
Étant entouré par des fournisseurs de solutions les plus connus du marché et en disposant des
accréditations nécessaires, Tunisian Cloud assure une meilleure intégration de l’environnement
informatique. Elle offre un service complet allant du conseil à la maintenance stratégique.
1.2.3 Inforgérence
Tunisian Cloud reconnaît qu’il n’y a pas de solution unique. En fonction des besoins de
l’organisation, de la taille de l’entreprise et des compétences disponibles au sein de la structure,
Tunisian Cloud propose des options flexibles d’externalisation. Qu’il s’agisse de réaliser une
infogérance informatique sur les sites ou d’externaliser tout ou partie du SI dans un centre
d’hébergement à haute disponibilité, Tunisian Cloud s’engage à fournir la meilleure solution pour
les besoins de ses clients.
1.2.4 Sécurité
Toutes les organisations, quelque soit leurs tailles et leurs secteurs d’activité, sont des cibles
potentielles d’attaques contre leurs systèmes d’information. Toutes les menaces découlant d’une
faille de sécurité créée lors de la configuration, du développement ou de la maintenance ayant été
effectuées, les grandes entreprises ne sont pas les seules à supporter le poids de ces attaques et
menaces. Ces services de sécurité visent à identifier ces failles avant qu’ils ne se transforment en
menaces exploitables.
FS-SFAX Page 4
1.3 Context du projet
Dans cette section, nous allons présenter la problématique liée au développement des boutiques
numériques moderns et les solutions possibles.
1.3.1 Problématique
Malgré que le commerce électronique a incontestablement révolutionné notre façon de faire des
achats, certains inconvénients ont été mis en évidence. L’un des principaux problèmes soulevés
est la simplicité perçue des services fournis par les plateformes de commerce électronique.
Les utilisateurs ont critiqué le manque d’expériences personnalisées et les options limitées de
personnalisation. En outre, L’inaccessibilité des achats sur les plateformes de médias sociaux
populaires comme Facebook, Messenger et Instagram a créé un problème important dans le
maintien d’une session utilisateur cohérente sur ces plateformes et les plateformes de commerce
électronique. Cette difficulté a empêché les clients d’éviter les traces liés à la création de
nouveaux comptes et a eu un impact sur l’expérience utilisateur transparente que les plateformes
de commerce électronique s’efforcent d’offrir. Les consommateurs doivent pouvoir être sûrs que
leurs informations seront conservées en toute sécurité . Malheureusement, malgré la progression la
plupart des plateformes de commerce électronique ne disposent pas encore des mesures de sécurité
nécessaires pour protéger les données des clients. Cette situation est d’autant plus préoccupante que
les cyberattaques et les violations de données sont de plus en plus fréquentes.
FS-SFAX Page 5
1.3.2 Solutions proposées
Les problèmes dégagés lors de l’analyse de la situation actuelle rendent nécessaire l’élaboration
d’une solution informatisée afin d’offrir une autre expérience de vente et d’achat en ligne.
Pour ce faire, nous développerons une boutique numérique conviviale et accessible qui offrira
une expérience d’achat en ligne simple et efficace pour les clients. En permettant aux utilisateurs
d’acheter depuis plusieurs plateformes populaires telles que Facebook, Messenger et Instagram,
nous visons à offrir une accessibilité et commodité accrue pour les clients. Lorsqu’un client
passe une commande sur l’une de ces plateformes, notre système enregistre automatiquement son
profil ainsi que les produits ajoutés à son panier. Cette fonctionnalité est très utile pour les
propriétaires de la boutique, qui peuvent suivre en temps réel les activités de chaque client
grâce à la session client. Cela offre une meilleure compréhension des actions des clients et aide
les propriétaires de boutique à prendre des décisions informées pour améliorer l’expérience
d’achat. En outre, nous inclurons également des fonctionnalités de suivi de performance pour la
boutique. Les propriétaires de la boutique auront accès à des données détaillées sur les ventes, les
taux de conversion et les taux de rebond, ainsi que sur les produits les plus populaires et les pages
les plus visitées. En utilisant ces informations, les propriétaires de boutique pourront prendre des
décisions informées pour optimiser la performance de leur boutique et augmenter les ventes. Notre
projet accorde une attention primordiale à l’implémentation et à l’évolution de la composante de
sécurité, étant donné sa nature commerciale et la nécessité de protéger les données confidentielles.
Dans cette perspective, nous avons intégré des mesures de sécurité supplémentaires en utilisant
une documentation professionnelle OWASP, afin d’assurer la satisfaction et la confiance totale des
utilisateurs. Chaque plateforme nécessite une intégration complète et des tests approfondis afin de
garantir le bon déroulement du processus de paiement. Notre plateforme offre cette fonctionnalité
essentielle.
FS-SFAX Page 6
1.4 Cahier des charges
Lors de la conception d’un système informatique, il est essentiel de comprendre les différents
acteurs impliqués dans le processus, leurs besoins fonctionnels et non fonctionnels. Cette section
est consacré à ses éléments.
1.4.1 Identification des acteurs
Chaque système informatique met des fonctionalités et des informations pertinentes à la disposition
de ses acteurs qui leur permettent d’interagir avec. Ces acteurs peuvent être classés comme
l’indique la table 1.1 :
Acteur secondaire
Client Cet acteur peut interagir avec les

fonctionnalités fournies par la plateforme
de manière à répondre à ses besoins
spécifiques
Acteurs principaux
Administrateur Cet acteur occupe le poste le plus élevé

dans la hiérarchie de la plateforme,
assumant la responsabilité de la gestion
de son entreprise et de la supervision des
utilisateurs en leur attribuant les rôles et
les autorisations appropriés.
Employé Cet intervenant est principalement

chargé de superviser et de coordonner
les opérations des boutiques au sein
de l’entreprise pour lesquelles il est
employé..
TABLE 1.1: Identification des acteurs
FS-SFAX Page 7
1.4.2 Identification des besoins fonctionnels
La phase de spécification des besoins fonctionnels est indispensible pour que les résultats de
la réalisation de notre plateforme soient conformes aux attentes du « Product owner » selon
l’approche agile SCRUM utilisée dans notre stage (voir 2.3.4).
Ainsi, les différentes fonctionnalités que nous envisageons de mettre en place dans le cadre de ce
projet, peuvent être regroupées dans les points suivants selon la table 1.2 :
FS-SFAX Page 8
Acteur Fonctionnalités
Administrateur Permettre de gérer l’entreprise

Permettre de gérer les utlisateurs au sein de l’entreprise
Permettre d’attribuer de rôles et de permissions spécifiques
à chaque utilisateur.
Employé Permettre de gérer les boutiques au sein de l’entreprise à

laquelle il est rattaché.
Permettre de gérer les catégories des produits
Permettre de gérer les sous-catégories des produits
Permettre de gérer les attribues des produits
Permettre de gérer les produits
Permettre de gérer et traiter les commandes reçues
Permettre de gérer les stocks
Permettre de consulter les notifications
Permettre de rédiger et d’envoyer des messages par courrier
électronique, SMS ou messagerie
Permettre d’analyser les statistiques en temps réel
Client Permettre de consulter les boutiques et parcourir ses

différents produits en toute sécurité
Permettre une gestion aisée du panier
Permettre de passer une commande en utilisant les médias
sociaux tels que Facebook et Messenger.
Permttre de suivre l’état de leurs commandes, d’accéder
à l’historique de leurs achats, ainsi que de procéder à
l’annulation ou à la modification d’une commande
Permettre d’effectuer des transactions financières.
TABLE 1.2: Les besoins fonctionnels
FS-SFAX Page 9
1.4.3 Identification des besoins non fonctionnels
Les besoins non fonctionnels permettent l’amélioration de la qualité logicielle de notre plateforme.
Ils agissent comme des contraintes à prendre en considération pour mettre en place une solution
adéquate à ce qui est attendu et garantir la livraison d’une solution logicielle de haute qualité.
Notre stage doit nécessairement répondre aux besoins suivants :
Convivialité :
La plateforme doit être facile à utiliser. Il devra offrir des interfaces conviviales, simples et
ergonomiques afin de fournir une expérience transparente qui permette à nos utilisateurs de
naviguer sans effort tout en atteignant leurs objectifs.
Performance :
Etant donné les données volumineuses a stocker, la plateforme doit réagir rapidement pour
maintenir l’intérêt et l’engagement de l’acteur client.
Sécurité :
Nous devons sécuriser notre plateforme. D’où le besoin de procéder à l’authentification des
différents utilisateurs. Il faut aussi assurer la confidentialité des données, et ce en appliquant des
cryptages au niveau de la base de données.
L’extensibilité :
C’est de pouvoir ajouter des nouvelles fonctionnalités ou de mettre à jour celles existantes.
1.5 Conclusion
Nous avons abordé successivement les points suivants : entreprise d’accueil, contexte et cahier des
charges de notre stage. Dans le chapitre suivant, nous allons étudier les méthodes de développemnt
et outils logiciels utilisés dans ce travail.
FS-SFAX Page 10
Chapitre
2
Méthode et outils utilisés
Sommaire
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Méthode classique de développement . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Méthode agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2 Manifeste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.4 Méthode retenue SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Outils logiciels utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 Langage de programmation : Golang . . . . . . . . . . . . . . . . . . . 16
2.4.2 GORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.3 Framework GIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.4 Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6 Architecture logicielle du projet . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
FS-SFAX Page 11
CHAPITRE 2. MÉTHODE ET OUTILS UTILISÉS
2.1 Introduction
Dans ce chapitre, nous allons présenter la méthode agile SCRUM retenue pour ce stage. De plus,
nous allons décrire et illustrer les outils logiciels utilisés dans ce travail à savoir le langage de
programmation Golang, la bibliothéque GORM et le framework Gin.
2.2 Méthode classique de développement
2.2.1 Présentation
La méthode classique de gestion de projet, également appelée méthode traditionnelle ou méthode

prédictive(« cascade » ou « waterfall), Elle est caractérisée par une planification détaillée et une
exécution séquentielle des tâches, chacune de ces étapes doit être terminée avant de passer à la
suivante. La méthode classique de développement comporte les phases suivants : Spécification,
Conception, Implementation, Test, Utilisation et Maintenance [2]. L’enchaînement des phases est
fourni par la figure 2.1. Chaque phase prend en entrée des documents et fournit en sortie des
documents. Par exemple, la phase de Spécification prend en entitée le cahier des charges et fournit
en sortie un document de spécification.
F IGURE 2.1: Méthode classique de développement
FS-SFAX Page 12
2.2.2 Evaluation
La méthode classique de développement, également connue sous le nom de modèle en cascade,

présente plusieurs points faibles qui peuvent limiter son efficacité et sa pertinence dans certains
contextes. Voici une description des principaux points faibles de cette approche :
• Manque de flexibilité : la méthode classique de gestion de projet ne permet aucun retour en

arrière. Cette approche peu flexible se révèle contraignante en cas d’imprévu.
• Peu d’interaction en cours de projet avec le client : grâce au cadrage décrit ci-dessus, le
client n’intervient pas en cours de projet. Le contrôle qualité a donc lieu tout à la fin.
• Effet tunnel : la méthode classique de gestion de projet implique une livraison du produit
dans sa version finale. Elle favorise donc :
• l’effet tunnel (manque de communication et de visibilité entre le client et le développeur).
• la déception du client (ses besoins ont évolué avec le temps, le produit ne lui correspond
plus).
2.3 Méthode agile
2.3.1 Présentation
La méthode agile est une approche du développement logiciel dont l’objectif est de fournir en
continu des logiciels opérationnels crées sur la base d’itérations rapides. Ainsi, le code est le coeur
de la méthode agile [3].
L’ultime itération de l’approche agile fournit le logiciel demandé en accord avec le client. Une
itération agile est schématisée par la figure 2.2 .
FS-SFAX Page 13
F IGURE 2.2: Itération agile
La phase de Refactoring permet d’améliorer le code sans toucher à son conportement.
2.3.2 Manifeste
En 2001, un group d’experts mondiaux en génie logiciel a conçu et rédigé le manifeste agile
qui insiste sur la nécessité de mettre de la qualité dans les produits réalisés afin de limiter aux
maximum les risques de bugs et pour assurer une continuité des futurs développements. La
simplicité c’est-à-dire l’art de minimiser la quantité de travail inutile est essentielle. Le manifeste
agile s’appuie sur les principes fondateurs suivants [4] :
• Les individus et leurs interactions plus que les processus et les outils
• Des logiciels opérationnels plus qu’une documentation exhaustive
• La collaboration avec les clients plus que la négociation contractuelle
• L’adaptation au changement plus que le suivi d’un plan
FS-SFAX Page 14
2.3.3 Evaluation
Les méthodes de développement de logiciels agile sont axées sur la distribution rapide de petites
parties de logiciels opérationnels pour améliorer la satisfaction client. Elles se basent sur une
approche qui encourage l’adaptation et le travail d’équipe pour favoriser l’amélioration continue.
En général, le développement logiciel agile implique la réunion régulière et en personne de petites
équipes autonomes de développeurs logiciels et de représentants métier tout au long du cycle de
vie. La méthode agile privilégie une approche simplifiée plutôt que la documentation logicielle et
favorise les changements à toutes les étapes du cycle de vie, au lieu d’y faire obstacle.
2.3.4 Méthode retenue SCRUM
Le framework Scrum est peut-être le plus utilisé aujourd’hui, mais tous les frameworks agiles ne
sont pas des structures Scrum, et inversement. Scrum permet de gérer des tâches conçues pour
de petites équipes pluridisciplinaires de 5 à 9 personnes qui découpent leur travail en actions
réalisables dans un délai cohérent appelé « sprint ». Les équipes Scrum sont composées de
membres, d’un Scrum Master et d’un Scrum Owner. En général, ce framework est mis en œuvre
lorsqu’un grand projet peut être réparti en sprints de 1 à 4 semaines. Un élément clé du framework
Scrum est la « rétrospective », c’est-à-dire une réunion qui permet à chacun de donner son point de
vue. Sa devise pourrait être « inspecter et adapter » [5]. La figure 2.3 décrit le processus SCRUM.
F IGURE 2.3: La méthode SCRUM
FS-SFAX Page 15
La méthodologie SCRUM fait intervenir trois rôles principaux qui sont :

• Product Owner : C’est le représentant des clients, il définit l’ordre dans lequel les
fonctionnalités seront développées ;
• Scrum Master : Il agit comme un « Coach » et non pas comme un dirigeant, son rôle est
d’aider l’équipe à avancer de manière autonome en cherchant en permanence à s’améliorer ;
• Equipe : l’équipe est constituée des personnes qui seront chargées d’implémenter les
besoins du client. Elle doit tout faire pour délivrer le produit dans les délais prévus ;
Les participants à notre stage effectué dans l’entreprise Tunisian Cloud sont décrits dans la table
2.1 .
Personnes Rôles Scrum
Mr. Lamouchi Bassem Product Owner
Mr. Hedi Manai Scrum Master
Mhamdi Ezzddinne, Youssef Fakhreddine Equipe
TABLE 2.1: Equipe et rôles Scrum
2.4 Outils logiciels utilisés
2.4.1 Langage de programmation : Golang
Golang dit encore Go est développé par Google en 2009 [6]. Il s’agit d’un langage de
programmation impératif fortement inspiré a la fois de deux langages populaires C et Pascal. Ansi,
Go est un langage typé et compilé. Il offre des possibilités vis-a-vis de la programmation synchrone
(ou séquentielle), asynchrone (ou concurrente) et orientée objet. La figure 2.4 présente le logo du
Golang.
F IGURE 2.4: Logo du language Golang
FS-SFAX Page 16
2.4.1.1 Possibilités vis-à-avis de la programmation synchrone
Go permet d’écrire des programmes séquentiels en réutilisant au mieux les constructeurs de types,
les variables simples et structurés, les structures de contrôle, la définition des sous-programmes
et l’appel synchrone des sous-programmes. Le listing 2.5 fournit un exemple d’un programme
séquentiel Go issue de notre stage permettant d’écrire la processus de réalisation d’un email au
sein de notre platforme. Il s’agit d’un appel synchrone de la fonction RunServer venant de notre
module server.
F IGURE 2.5: Exemple d’un programme synchrone
FS-SFAX Page 17
2.4.1.2 Possibilités vis-à-avis de la programmation asynchrone
Un programme concurrent écrit en Go comporte plusieurs flots d’exécution. Pour y parvenir, Go

fournit des co-routines dits goroutines et des cannaux de communication et de synchronisation
favorisant l’ordonnancement des processus légers. Le listing 2.6 fournit un exemple de programme
concurrent en Go. Un tel programme comperte une fonction strlen acceptant deux paramétres s de
type chaine de caractéres et un canal de communication appelé C pertant une information de type
entier. La fonction strlen calcule la lengueur de s et transmet le résultat sur C (ligne 2). Le fonction
principal main permet de créer un canal de communication C (ligne 6) et de lancer deux processus
légers (les deux lignes 7 et 8) à l’aide de deux appels aynchrones de la fonction strlen. La ligne 9
récupére le deux résultats respectivement dans x et y
F IGURE 2.6: Exemple d’un programme concurrent
2.4.1.3 Possibilités vis-à-avis de la programmation orientée objet
Go supporte un mécanisme rudimentaire permettant le regroupement de donnés (en utilisant le

constructeur de type struct) et les traitements (en utilisant des méthodes travaillant sur ces donnés).
Le concept d’héritage n’est pas supporté par Go. Le listing 2.7 et 2.8 fournint des concepts métier
issus de notre stage décrits en Go. De tels concepts décrivant en Go les deux notions Panier et
Produit.
FS-SFAX Page 18
F IGURE 2.7: Quelques caractéristique du concept produit
F IGURE 2.8: Quelques caractéristique du concept panier
FS-SFAX Page 19
2.4.2 GORM
L’ORM est une technique de programmation permettant de faire la correspondance entre un code
et une base de données relationnelle. La bibliothéque GORM offre des fonctionnalités permettant
la manipilation des bases de données relationnelle a partir d’un code écrit en Go [7]. Le listing 2.9
fournit une utilisation de la bibliothéque GORM issue de notre stage. Sachant que le pilote de la
base de données est PostgresSQL.
F IGURE 2.9: Exemple d’utlisation de la bibliothèque "Gorm"
2.4.3 Framework GIN
2.4.3.1 Présentation
Le framework Gin est l’un des packages Web populaires de l’écosystème Go pour la création
d’applications Web. Gin fournit la plupart des fonctionnalités dont vous aurez besoin dans un
framework Web doté d’une API de type martini avec des performances élevées et une gestion facile
des erreurs [8]. L’architecture Gin suit généralement une approche MVC (Modèle-Vue-Contrôleur)
ou une approche similaire pour organiser le code de l’application. Les principales caractéristiques
de Gin sont :
• Rapide
• Prise en charge du middleware
• Sans crash
FS-SFAX Page 20
• Validation JSON
• Gestion des erreurs
• Extensible
La figure 2.10 présente le logo du framework Gin.
F IGURE 2.10: Logo du Framework Gin
2.4.3.2 Composantes Framework
• Router : Le router est une composante centrale de Gin qui gère le routage des requêtes
HTTP vers les fonctions de gestion associées. Il permet de définir des routes pour différentes
méthodes HTTP (GET, POST, PUT, DELETE, etc.) et de spécifier les fonctions de gestion
correspondantes.
• Handlers : Les handlers sont des fonctions qui sont exécutées lorsque le router fait
correspondre une requête à une route spécifique. Les handlers prennent en charge le
traitement des requêtes, l’accès aux données, la logique métier et la génération des réponses.
Dans Gin, les handlers sont généralement des fonctions qui prennent en charge un contexte
Gin spécifique en tant que paramètre.
• Middleware : Les middlewares sont des composants intermédiaires qui s’exécutent entre
la réception d’une requête et l’exécution des contrôleurs. Ils peuvent être utilisés pour
effectuer des opérations telles que l’authentification, l’autorisation, la gestion des erreurs,
la journalisation, la mise en cache, etc. Les middlewares dans Gin sont des fonctions qui
peuvent être ajoutées aux routes pour effectuer des opérations avant et après le traitement
des requêtes.
• Binding and Validation : Gin propose des fonctionnalités de liaison (binding) et de
validation des données de requête entrantes. Cela facilite la récupération des données de
requête dans des structures Go définies et la validation de ces données selon des règles
prédéfinies. Cela aide à garantir que les données reçues sont correctes et conformes aux
attentes.
• Groupes de routes (Route Groups) : Les groupes de routes permettent de regrouper des
routes liées ensembles, facilitant ainsi l’organisation et la gestion de routes similaires. Cela
permet d’appliquer des middlewares spécifiques à un groupe de routes, de partager des
paramètres communs, ou de définir des préfixes de chemin pour les routes.
FS-SFAX Page 21
2.4.4 Angular
Angular est un framework de développement d’applications web open source, basé sur TypeScript,
développé et maintenu par Google. Il est largement utilisé pour la création d’interfaces utilisateur
riches, dynamiques et réactives.
Angular suit le modèle de conception du développement d’applications basées sur des composants
(component-based development). Il permet de créer des applications modulaires, où chaque
composant représente une partie spécifique de l’interface utilisateur et de la logique métier. Les
composants peuvent être imbriqués et réutilisés pour construire des fonctionnalités complexes.
L’une des caractéristiques clés d’Angular est sa capacité à fournir une liaison de données
bidirectionnelle entre les composants et les modèles de données. Cela signifie que les modifications
apportées à l’interface utilisateur sont automatiquement reflétées dans les données et vice versa,
sans nécessiter de code supplémentaire [9].
2.5 Environnement logiciel
Nous avons utilisé, entre autre, les outils logiciels suivant :

PostgreSQL est un puissant système de base de données relationnelle objet open source avec plus
de 35 ans de développement actif qui lui a valu une solide réputation de fiabilité, de robustesse des
fonctionnalités et de performances [10].
Postman est une plateforme pour la création, l’utilisation et de tester les API. Postman simplifie
chaque étape du cycle de vie des API et rationalise la collaboration afin que vous puissiez créer de
meilleures API plus rapidement [11].
FS-SFAX Page 22
Ngrok est un outil de tunneling qui permet de créer des tunnels sécurisés entre un serveur local et
Internet. Il facilite l’exposition de serveurs et d’applications Web locaux derrière des pare-feu, des
réseaux privés ou des adresses IP dynamiques [12].
GitLab est une plateforme de développement logiciel open source de bout en bout avec contrôle
de version intégré, suivi des problèmes, révision du code, CI/CD, etc. Auto-hébergez GitLab sur
vos propres serveurs, dans un conteneur ou sur un fournisseur de cloud [13].
diagrams.net (draw.io) est un logiciel de dessin graphique multiplateforme gratuit et open source
développé en HTML5 et JavaScript. Son interface peut être utilisée pour créer des diagrammes tels
que des organigrammes, des structures filaires, des diagrammes UML, des organigrammes et des
diagrammes de réseau [14].
Trello est l’outil visuel de gestion du travail qui permet aux équipes d’imaginer, de planifier, de
gérer et de célébrer leur travail ensemble de manière collaborative, productive et organisée [15].
FS-SFAX Page 23
Twilio est la principale plateforme de communication cloud au monde qui vous permet d’impliquer
des clients sur tous les canaux : SMS, voix, vidéo, e-mail, WhatsApp, etc. Les API à prépaiement
permettent aux entreprises d’adapter leurs communications de manière fiable [16] .
Paymee est un nouveau concept de portefeuilles électronique qui a pour ambition de révolutionner
les habitudes des consommateurs tunisiens. Le but serait ainsi de pouvoir payer un marchand,
recevoir les paiements de vos clients, envoyer de l’argent à vos proches, ou encore payer vos
achats sur Internet [17].
2.6 Architecture logicielle du projet
L’une des étapes importantes dans le processus de la mise en oeuvre d’une application est le choix
adéquat d’un motif de conception puisqu’il facilite la communication, fait gagner en terme de
rapidité et diminiue d’une manière éminente les coûts.
Dans ce projet, nous avons opté pour le patron de conception MVC. Son principal intérêt est
la séparation des responsabilités en divisant l’interface graphique d’un programme en trois entités
distinctes ayant chacune un rôle précis lors du traitement de l’information, ce qui rend l’application
plus maintenable et plus évolutive.
Les rôles des trois entités sont les suivants :
• Le modèle : Contient les données manipulées par le programme. Il assure la gestion de ces
données et garantit leur intégrité ;
• La vue : Fait l’interface avec l’utilisateur. Son premier rôle est d’afficher les données
qu’elle a récupéré auprès du modèle et son second rôle est de recevoir toutes les actions
de l’utilisateur. Ses différents évènements sont envoyés au contrôleur ;
• Le contrôleur : Chargé de la synchronisation du modèle et de la vue. Il reçoit tous les
évènements de l’utilisateur et déclenche les actions à éffectuer.
FS-SFAX Page 24
F IGURE 2.11: Architecture MVC
2.7 Conclusion
Dans ce chapitre nous avons présenté la méthode agile SCRUM utilisée dans ce travail. Egalement,
nous avons décrit et illustré les outils employés pour implémenter notre platforme TuniShop. De
tels outils englobent essentiellement le langage de programmation Go, la bibliothéque GORM et
le framework Gin. Dans le chapitre suivant, nous allons appliquer la méthode agile SCRUM sur
notre cahier des charges décrit dans 1.4 .
FS-SFAX Page 25
Chapitre
3
Développement d’une boutique numérique
Sommaire
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Fonctionnalités : Backlog product . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Planification des releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 Release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.1 Sprint : Gestion d’authentification . . . . . . . . . . . . . . . . . . . . . 30
3.4.2 Sprint : Gestion des employés . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5.1 Sprint : Gestion des boutiques . . . . . . . . . . . . . . . . . . . . . . . 39
3.5.2 Sprint : Gestion des cartes . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.6 Release 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.6.1 Sprint : Gestion des messages . . . . . . . . . . . . . . . . . . . . . . . 45
3.6.2 Sprint : Intégration paiement . . . . . . . . . . . . . . . . . . . . . . . . 48
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
FS-SFAX Page 26
CHAPITRE 3. DÉVELOPPEMENT D’UNE BOUTIQUE NUMÉRIQUE
3.1 Introduction
Dans ce chapitre, nous allons appliquer la méthode agile SCRUM sur le cahier des charges de
notre stage (voir le chapitre 1, la section 4 ). Dans un premier temps, nous allons établir les user
stories formant le Backlog Product. Dans un deuxiéme temps, nous allons découper le Backlog
Product en plusieurs releases. Sachant que chaque release comporte plusieurs sprints, et chaque
sprint comporte un ensemble de user stories. Enfin, nous allons décrire en détails quelques sprints
3.2 Fonctionnalités : Backlog product
Le backlog product est l’artefact le plus important de méthode agile SCRUM, il consiste à présenter
la liste des fonctionalités ou encore les « User-Stories » constituant le produit souhaité. Chaque
fonctionnalité est caractérisée par :
• Le champ ID détermine un identifiant unique pour chaque user-story.
• Le champ User-story décrit la fonctionnalité désirée par l’utilisateur.
• Le champ Priorité renseigne sur l’importance attribuée au user-story. On distingue :
• élevé : user-story de priorité élevée.
• moyenne : user-story de priorité moyenne
• faible : user-story de priorité faible.
La table 3.1 regroupe 22 user-stories formant notre futur logiciel TuniShop. Conformémant
aux recommendations de la méthode agile SCRUM, ces user-stories sont indépendantes et
élémentaires. Ces user-stories sont numérotées de 1 à 22.
FS-SFAX Page 27
ID User-story Priorité
1 En tant qu’utilisateur, je voudrais m’inscrire élevé

2 En tant qu’utilisateur, je voudrais créer mon entreprise élévé
3 En tant que administrateur, je voudrais ajouter des employés élevé
au sein de l’entreprise
4 En tant que administrateur, je voudrais assigner de rôles et élevé
de permissions aux employés au sein de l’entreprise afin de
faciliter les responsabilité et les autorisations
5 En tant que utilisateur, je pourrais changer ou rénitialiser élevé
mon mot de passe
6 En tant que employé, je pourrais gérer les boutiques moyenne
7 En tant que employé, je pourrais gérer les catégories moyenne
8 En tant que employé, je pourrais gérer les sous-catégories moyenne
9 En tant que employé, je pourrais gérer des attributs au moyenne
boutique
10 En tant que employé, je pourrais gérer les produits du moyenne
boutique
11 En tant que employé, je pourrais affecter des prix pour moyenne
chaque produit selon les attributs
12 En tant que employé, je pourrais gérer les coupons pour moyenne
chaque produit
13 En tant que client je voudrais ajouter mes produits préféré à moyenne
mon panier
14 En tant que client, je voudrais passer des ordres depuis mon moyenne
panier
15 En tant qu employé, je pourrais gérer les ordres des clients moyenne
16 En tant qu administrateur, je voudrais suivre les traces de élevé
mes employés au sein de l’entreprise
17 En tant qu employé, je pourrais envoyer des élevé
messages(mail,sms,messenger) pour les clients
FS-SFAX Page 28
18 En tant qu administrateur, je pourais reçevoir des moyenne

notifications pour l’entreprise
19 En tant qu employé, je pourais reçevoir des notifications moyenne
pour le boutique
20 En tant que client, je voudrais commenter à un produit faible
21 En tant qu’utilisateur, je voudrais répondre aux faible
commentaires
22 En tant que client, je pourrais assurer des paiements élevé
TABLE 3.1: Backlog product
3.3 Planification des releases
Un release est un ensemble de sprints. Un sprint est un sous-ensemble de Backlog-product. La

figure 3.1 présente le découpage retenu de notre projet en trois releases (Release 1, Release 2 et
Release 3) comportant respectivement 3, 8 et 5 sprints.
F IGURE 3.1: Découpage du projet
Pour des raisons d’économie d’espace, nous nous limitons à la présentation de deux sprints à
chaque release.
FS-SFAX Page 29
3.4 Release 1
Dans la suite, nous allons décrire les deux sprints formant ce Release 1.
3.4.1 Sprint : Gestion d’authentification
Le but de ce premier sprint consiste à mettre en oeuvre le processus d’authentification qui à son
tour déclenche l’accomplissement de la fonctionnalité gestion des entreprises. Ce premier sprint
comporte 4 user stories venant du Backlog-Product (voir Table 3.1).
3.4.1.1 Backlog du sprint
La table 3.2 décrit les user-stories formant le sprint "Gestion d’authentification". Elles sont au
nombre de quatre. Les tâches associés à une user storie sont Développement, Test et Ecriture d’un
diagramme de séquences.
FS-SFAX Page 30
ID User story ID Tâche
En tant qu’utilisateur, je voudrais

1.1 Développer le cas "S’inscrire"
m’inscrire
1.2 Tester le cas "S’inscrire"
1
Réaliser le diagramme de séquences
1.3
de la fonctionnalité "S’inscrire"
2.1 Développer le cas "S’authentifier"
m’authentifier
2.2 Tester le cas "S’authentifier"
2
2.3
de la fonctionnalité "S’authentifier"
3.1 Développer le cas "Modifier mot de passe"
modifier mon mot de passe
3.2 Tester le cas "Modifier mot de passe"
3
3.3
de la fonctionnalité "Modifer Mot de passe"
En tant qu’utilisateur, je pourrais
effectuer une réinitialisation du mot 4.1 Développer le cas "Rénitialiser mot de passe"
de passe en cas d’oubli.

4 4.2 Tester le cas "Rénitialiser mot de passe"
4.3
de la fonctionnalité "Rénitialiser mot de passe"
TABLE 3.2: Backlog du Sprint Gestion d’authentification
FS-SFAX Page 31
3.4.1.2 Réalisation
La réalisation du sprint Gestion d’authentification a nécessité l’utilisation de divers bibliothèques

appropriés en Go.
Pour vérifier le format des données entrante nous avons utilisé le paquet regexp permettant de
fournir les possibilités nécessaires pour rechercher, valider et manipuler des données à l’aide des
expressions régulières.
Une fois que les données entrantes ont été vérifiées, le système procède à la génération d’un
hachage sécurisé du mot de passe en utilisant la bibliothèque bcrypt. L’algorithme bcrypt, réputé
pour ses caractéristiques de sécurité robustes, est spécifiquement conçu pour le hachage des mots
de passe. Son mécanisme de hachage unique repose sur une fonction de salage complexe (pour
éviter les collisions) offrant une protection efficace contre les tentatives d’attaque par force brute
et par dictionnaire.
Lors de l’enregistrement, le système génère un code unique valable 10 minutes et l’envoie à l’aide
du logiciel de confiance gomail. Ce paquet est dynamique pour créer et envoyer des courriels via
divers serveurs SMTP.
Le système attribue des rôles tels que administrateur, client et employé à l’utilisateur en
utilisant la bibliothèque de contrôle d’accès appelée Casbin. Cette bibliothèque facilite l’ajout
d’une politique de regroupement en assurant que seules les personnes autorisées ont accès aux
informations sensibles.
Une fois que l’utilisateur a terminé avec succès le processus d’authentification, le système génère
un jeton Web JSON (JWT) en utilisant le paquet golang-jwt qui sert de preuve de l’identité
vérifiée de l’utilisateur. Ces jetons JWT jouent un rôle crucial dans la sécurité des applications
web, car ils sont utilisés à la fois à des fins d’authentification et d’autorisation, garantissant que
seuls les utilisateurs authentifiés ont accès aux ressources appropriées.
FS-SFAX Page 32
3.4.1.3 Test
Pour tester le sprint Gestion d’authentification, nous avons établi deux cas de test : Test
d’inscription et Test d’authentification (voir colonne "Cas de test" Table 3.3). la colonne
"Démarche" indique la séquence d’actions permettant d’introduire les données de test. La colonne
"Comportoment attendu " indique les résultats attendus décrits d’une façon informelle.
Cas de test Démarche Comportement attendu
Lorsqu’un utilisateur n’est pas enregistré,

un code de vérification est généré
L’utilisateur entre ses
et envoyé par email. En revanche,
coordonnés
si l’utilisateur existe déjà, un message
Test d’inscription d’erreur est affiché.
Redirection vers la page d’authentification
L’utilisateur entre si le code est correct et n’est pas expiré.
le code Sinon un message d’erreur s’affiche et le
sytème renvoie un autre code.
Chaque utilisateur est redirigé vers la

Après l’accès à l’interface page appropriée en fonction de son rôle
Test d’authentification d’authentification, l’utilisateur une fois que ses coordonnées ont été
entre ses coordonnées vérifiées avec succès. Sinon un message
d’erreur s’affiche
TABLE 3.3: Test fonctionnel du sprint "Gestion d’authentification"
3.4.1.4 Diagrammes de séquences
La figure 3.2 fournit le diagramme de séquence lié au user story "s’incrire".
FS-SFAX Page 33
F IGURE 3.2: Diagramme de séquences « S’incrire »
La figure 3.3 donne le diagramme de séquence concernant le user story "Rénitialiser mot de passe"
FS-SFAX Page 34
F IGURE 3.3: Diagramme de séquences « Rénitialiser mot de passe »
3.4.2 Sprint : Gestion des employés
Le but de Ce sprint vise à mettre en place la fonctionnalité de la gestion des employéss avec leurs
différents privilèges. Ce deuxième sprint comporte 3 user-stories venant du Backlog-Product (voir
Table 3.1).
FS-SFAX Page 35
Ce sprint regroupe les user-stories liées au concept métier utilisateur (voir Table 3.4)
1.1 Développer le cas "Ajouter employé"

En tant qu’administrateur, je
1 1.2 Tester le cas "Ajouter employé"
voudrais ajouter un employé
Réaliser le diagramme de séquences de la
1.3
fonctionnalité "Ajouter employé"
2.1 Développer le cas "Modifier employé"

En tant qu’administrateur, je
2 2.2 Tester le cas "Modifier employé"
voudrais modifier les données d’un employé
Réaliser le diagramme de séquences de la
2.3
fonctionnalité "Modifier employé"
En tant qu’utilisateur, je pourrais 3.1 Développer le cas "Supprimer employé"

3 effectuer une réinitialisation du 3.2 Tester le cas "Supprimer employé"
mot de passe en cas d’oubli. Réaliser le diagramme de séquences de la
3.3
fonctionnalité "Supprimer employé"
TABLE 3.4: Backlog du Sprint Gestion des employés
La réalisation du sprint : Gestion des employés réutilise avec profit des fonctionnalités venant des
bibliothéque interfacées par Go.
Afin de garantir l’autorisation d’accès aux ressources par l’émetteur d’une requête, nous avons mis
en place une fonction middleware basée sur Casbin dans un serveur Gin en utilisant Go (Golang).
Cette fonction middleware assure la gestion de l’autorisation en se basant sur les règles de contrôle
d’accès définies par Casbin. Afin d’assurer la conformité des données entrantes, nous avons mis
en œuvre des mécanismes de validation à l’aide de la bibliothèque de regex. Pour renforcer la
sécurité des mots de passe, nous avons adopté le package bcrypt pour leur chiffrement. De plus,
pour l’acheminement des coordonnées, nous avons utilisé le package gomail. En ce qui concerne
l’affectation des rôles, nous avons implémenté la bibliothèque Casbin.
FS-SFAX Page 36
3.4.2.3 Test
Pour tester le sprint : Gestion des employés, nous avons établi trois cas de test représentatifs (voir
Table 3.5)
Si les données fournies sont

L’administrateur saisit les données valides, une invitation est
Test d’ajout d’un
nécessaires pour créer un compte émise dans le cas où le compte
employé
pour l’employé. n’existe pas. Dans le cas contraire,
un message d’erreur est affiché.
Les données seront enregistrées
Après la création du compte, dans le cas
sur mémoire secondaire uniquement
où un employé aurait oublié son mot de
Test modification si elles satisfont aux critères de
passe ou si un administrateur souhaite
d’un employé validation ; dans le cas contraire,
mettre à jour les informations, il est
un message d’erreur sera généré
requis de saisir les nouvelles données.
et affiché.
L’administrateur permet de supprimer Si la suppression de l’employé

un employé au sein de son entreprise réussit, la base de données est
Test suppression
en sélectionnant celui-ci dans la liste mise à jour. En cas d’échec, un
d’un employé
des employés et en cliquant sur le message d’erreur est affiché
bouton "Supprimer". pour informer l’administrateur.
TABLE 3.5: Test fonctionnel du sprint « Gestion des employés »
La figure 3.4 fournit le diagramme de séquences concernant le sprint "Gestion des employés"
FS-SFAX Page 37
3.4.2.4 Diagramme de séquences
F IGURE 3.4: Diagramme de séquences « Gestion des employés »
FS-SFAX Page 38
3.5 Release 2
Dans la suite, nous allons décrire uniquement deux sprints de Release 2.
3.5.1 Sprint : Gestion des boutiques
Il est essentiel de mettre en place un processus de gestion de boutique, et notre sprint actuel se
focalise spécifiquement sur la mise en œuvre de ce processus. Cette mise en œuvre comprend
diverses tâches telles que la gestion des catégories, des sous-catégories et des attributs, ainsi que la
rationalisation de la gestion des produits, des coupons et des cartes.
Ce sprint regroupe les user-stories liées au concept métier boutique (voir Table 3.6)
FS-SFAX Page 39
En tant qu’employé, je
1.1 Développer le cas "Créer boutique"
pourrais créer une boutique
1.2 Tester le cas "Créer boutique"
1
1.3 Réaliser le diagramme de séquences de la
fonctionnalité "Gestion des boutiques"
pourrais modifier une 2.1 Développer le cas "Modifier boutique"
boutique
2 2.2 Tester le cas "Modifier boutique"
pourrais supprimer 3.1 Développer le cas "Supprimer boutique"
une boutique
3 3.2 Tester le cas "Supprimer boutique"
TABLE 3.6: Backlog du Sprint « Gestion des boutiques »
Pour la création ou modification de la boutique, il est nécessaire de saisir les données requises,
lesquelles seront ensuite validées à l’aide de l’utilisation de la bibliothèque de correspondance de
motifs réguliers regex.
Lors de la création de la boutique, les informations, telles que l’ID du créateur, sont extraites
à l’aide de la fonction ExtractTokenValues du middleware, qui permet de récupérer l’ID de
l’émetteur de la requête.
FS-SFAX Page 40
3.5.1.3 Test
Pour tester ce sprint : Gestion des boutiques, nous avons établi trois cas de test représentatifs (voir
Table 3.5)
Si les données sont valides

et uniques, l’employé est
L’employé procède à la saisie des redirigé vers la page
Test création
données nécessaire pour la d’accueil de la boutique.
d’une boutique
structure de boutique Dans le cas contraire,
un message d’erreur
est affiché.
Lorsque l’employé a crée une Les données seront
boutique et souhaite modifier enregistrées sous réserve
Test modification
ses données, il lui suffit de de leur validation. En cas
de boutique
saisir les nouvelles d’invalidité, un message
informations. d’erreur sera affiché.
Si les données saisies sont

correctes, l’opération est
L’employé dispose d’une
validée et la boutique sera
fonctionnalité lui permettant
supprimé. Cependant, si
Test suppression de supprimer le boutique en
les données saisies sont
d’une boutique fournissant son adresse
incorrectes, un message
e-mail ainsi que son mot de
d’erreur est affiché pour
passe.
informer de l’échec de la
suppression de l’entreprise.
TABLE 3.7: Test fonctionnel du sprint « Gestion des boutiques »
La figure 3.5 fournit le diagramme de séquences concernant le sprint "Gestion des boutiques"
FS-SFAX Page 41
F IGURE 3.5: Diagramme de séquences « Gestion des boutiques »
FS-SFAX Page 42
3.5.2 Sprint : Gestion des cartes
Dans ce sprint, notre objectif est de mettre l’accent sur la détection des produits ajoutés par le
client dans son panier. Cette initiative vise à garantir la précision des commandes et à optimiser le
processus de paiement, contribuant ainsi à accroître la satisfaction de nos clients.
Ce sprint regroupe les user-stories liées au concept métier carts (voir Table 3.8)
En tant que client, Je souhaite 1.1 Développer le cas "Gestion de carts"

inclure un produit dans mon
1 panier d’achats.
1.2 Tester le cas "Gestion des Carts"
fonctionnalité "Gestion des carts"
En tant que client, je suis en 2.1 Développer le cas "Gestion des carts"
mesure d’ajuster la quantité
2 des produits ajoutés.
2.2 Tester le cas "Gestion des carts"
En tant que client, je pourrais 3.1 Développer le cas "Gestion de carts"

supprimer un produit de mon
3 panier
3.2 Tester le cas "Gestion des carts"
TABLE 3.8: Backlog du Sprint « Gestion des carts »
FS-SFAX Page 43
Nous avons utilisé les bibliothéques dvcrit précédement à savoir gestion des boutiques
3.5.2.3 Test
Pour tester ce sprint : Gestion des carts, nous avons établi deux cas de test représentatifs (voir Table
3.9)
Dans le cas où le produit est

Pour le client, lors de la
disponible, tout se déroulera
consultation des produits
correctement. Cependant,
dans la boutique, il lui
Test d’ajout si le produit n’est pas
suffit de cliquer sur "Add
d’un produit disponible en stock,
item" afin d’inclure
un message d’erreur sera
l’article sélectionné dans
affiché pour indiquer son
son panier d’achat.
absence.
Une fois que le produit
est ajouté, le client peut Les données seront sauvegardées
facilement modifier la uniquement si la quantité
Test de
quantité en accédant à sélectionnée est inférieure à la
modification
l’interface du panier et quantité existante. Dans le cas
de quantité
en utilisant les boutons contraire, un message d’erreur
de contrôle dédiés à la sera affiché.
quantité.
TABLE 3.9: Test fonctionnel du sprint « Gestion des carts »
3.5.2.4 Diagramme de séquence
La figure 3.6 fournit le diagramme de séquences concernant le sprint "Gestion des carts"
FS-SFAX Page 44
F IGURE 3.6: Diagramme de séquences « Gestion des carts »
3.6 Release 3
Nous avons décrire les deux sprints : Gestion des messages et Intégration paiement
3.6.1 Sprint : Gestion des messages
Durant ce sprint dédié à notre plateforme de commerce électronique, notre objectif est d’améliorer
l’expérience client en mettant en place une fonctionnalité de messagerie personnalisée basée sur
les étiquettes de statut des clients. Cette initiative vise à tenir nos clients informés et engagés,
renforçant ainsi leur propension à effectuer des achats récurrents et à développer leur fidélité envers
notre plateforme.
FS-SFAX Page 45
Ce sprint regroupe les user-stories liées au concept métier messages (voir Table 3.10)
En tant qu’employé, je souhaite

communiquer avec un client en lui
1.1 Développer le cas "Envoyer e-mail"
envoyant un message par courrier
électronique à son adresse e-mail.
1
1.2 Tester le cas "Envoyer e-mail"
fonctionnalité "Gestion des messages"
En tant qu’employé, j’ai l’intention

d’établir une communication avec un 2.1 Développer le cas "Envoyer sms"
client en lui adressant un message SMS.

2 2.2 Tester le cas "Envoyer sms"
En tant qu’employé, J’ai l’intention

d’établir une communication avec un
3.1 Développer le cas "Envoyer message"
client en initiant un échange par le biais
de Messenger.
3
3.2 Tester le cas "Envoyer message"
TABLE 3.10: Backlog du sprint Gestion des messages
FS-SFAX Page 46
Afin d’assurer l’acheminement efficace des messages par courrier électronique, nous avons fait
appel à des bibliothèques spécialisées telles que gomail.
Pour faciliter l’envoi de messages SMS, la réalisation d’appels vocaux et la gestion des numéros
de téléphone, nous avons intégré la bibliothèque twillio-go dans notre système. Cette bibliothèque
nous permet d’interagir avec l’API de Twilio, offrant ainsi une solution professionnelle pour
l’envoi de messages par SMS.
3.6.1.3 Test
Pour tester ce sprint : Gestion des messages, nous avons établi deux cas de test représentatifs (voir
Table 3.11)
Si un employé n’est pas autorisé à

Avant de pouvoir envoyer un
envoyer les messages, le système
message, un employé doit
Envoyer message génère un message d’erreur pour
d’abord accéder à l’interface
l’informer de cette restriction
de création de messages.
d’accès.
Un employé peut souhaiter

Si le message contient un contenu
envoyer différents types de
malveillant, le système détecte et
Envoyer message messages, tels que des
affiche une erreur d’accès pour
fichiers ou des images,
des raisons de sécurité.
par exemple.
TABLE 3.11: Test fonctionnel du sprint « Gestion des messages »
3.6.1.4 Diagramme de séquence
La figure 3.7 fournit le diagramme de séquences lié au sprint "Gestion des messages".
FS-SFAX Page 47
F IGURE 3.7: Diagramme de séquences « Gestion des messages »
3.6.2 Sprint : Intégration paiement
Ce sprint représente l’élément central de notre plateforme, avec une focalisation particulière sur
l’intégration de Paymee dans notre code afin de réaliser la dernière étape attendue par le client, à
savoir le processus de paiement.
Ce sprint regroupe les user-stories liées au concept métier paiement (voir Table 3.12)
ID User story ID Tache
En tant que client, je souhaite 1.1 Développer le cas "Effectuer paiement"

effectuer un paiement.
1 1.2 Tester le cas "Effectuer paiement"
fonctionnalité "Intégration paiement"
TABLE 3.12: Backlog du sprint « Intégration paiement »
FS-SFAX Page 48
Dans le processus de paiement, nous avons mis en œuvre une méthode d’intégration avec
redirection de Paymee. Cela signifie que lorsqu’un client souhaite effectuer un paiement, il est
redirigé vers une page de paiement hébergée par un fournisseur de services de paiement ou une
passerelle de paiement tiers.
La première étape de ce processus consiste à initialiser le paiement en collectant les informations
essentielles du client, telles que son nom, son prénom, son adresse email et son numéro de
téléphone. De plus, les détails de la commande, tels que l’identifiant, le montant du paiement
et toute remarque spécifique au paiement, sont également requis pour cette étape.
Pour réaliser cette étape d’initialisation, nous avons utilisé un environnement Sandbox afin de
simuler des transactions et de tester l’intégration de la plateforme de paiement, sans effectuer de
transactions réelles. Pendant les tests d’initialisation, nous avons utilisé la méthode POST pour
envoyer les informations à l’URL Sandbox suivante :
https ://sandbox.paymee.tn/api/v2/payments/create, afin que les informations puissent être
vérifiées dans le système Paymee. La figure 3.8 ci-dessous illustre le processus d’initialisation
de Paymee.
F IGURE 3.8: Capture d’initialisation de Paymee
FS-SFAX Page 49
Une fois cette étape accomplie avec succès, le système redirigera le client vers une page de
paiement hébergée où il pourra saisir toutes les informations requises de sa carte de paiement.
Après l’initialisation du paiement, la réalisation interne du test est déclenchée, ce qui renvoie
un paiement sous forme d’URL représentant la page de paiement hébergée, ainsi qu’un jeton
permettant de vérifier l’utilisateur. La figure 3.9 présente la réponse correspondant à l’initialisation
de Paymee.
F IGURE 3.9: Capture de réponse d’initialisation de Paymee
FS-SFAX Page 50
Afin de tester en toute sécurité l’ensemble de ce processus, nous avons utilisé Ngrok comme un
outil permettant d’établir un tunnel sécurisé vers un serveur local à des fins de développement et
de test. Cela nous a permis de garantir la confidentialité et la sécurité des échanges de données lors
de nos tests. La dernière étape consiste en la vérification du paiement, à ce stade, Paymee procède
à toutes les vérifications nécessaires pour s’assurer que tout est en ordre. Si toutes les vérifications
sont concluantes, le paiement est effectué avec succès. Dans le cas contraire, des mesures
appropriées sont prises. Le processus interne de cette étape s’articule de la manière suivante :
Paymee offre la possibilité d’envoyer le statut de paiement à l’URL du webhook (Ngrok).
Ensuite, l’URL de retour (return_url) vérifie le statut de paiement et traite la commande en
conséquence. Pour garantir l’intégrité de la réponse, une somme de contrôle (check_sum) est
générée en utilisant la formule suivante : md5(token + payment_status(1 ou 0) + API Token).
Ainsi, les données sont envoyées à l’URL du webhook à la fois en cas de réussite et en cas
d’échec du paiement. Les deux figures 3.10 et 3.11 ci-dessus illustrent la réponse générée par le
système de Paymee pour la vérification des paiements.
F IGURE 3.10: Capture montre que le paiement est réussi
FS-SFAX Page 51
F IGURE 3.11: Capture montre que le paiement est réfusé
3.6.2.3 Test
Pour tester ce sprint : Intégration paiement, nous avons établi trois cas de test représentatifs (voir
Table 3.13)
FS-SFAX Page 52
En cas de fourniture d’informations de

paiement incorrectes ou manquantes
Une fois les
lors du processus de paiement, le
Initialiser paiement informations de
système génère un message d’erreur
la carte saisies
pour notifier l’utilisateur de cette
restriction d’accès
Si la carte de paiement utilisée est rejetée par

la banque ou l’émetteur de la carte, cela peut
être attribué à diverses raisons telles qu’un
Une fois le solde insuffisant, une expiration de la carte,
Effectuer paiement paiement une saisie incorrecte des détails de la carte ou
effectué d’autres problèmes liés à la carte. Dans de tels
cas, le système génère un message d’erreur
pour informer l’utilisateur de la restriction
d’accès rencontrée.
En cas d’expiration de la durée de validité de
Une fois que le
la transaction avant la réussite du paiement,
client a effectué
le système génère une erreur indiquant que
un paiement.
la transaction a expiré.
TABLE 3.13: Test fonctionnel du sprint « Intégration paiement »
La figure 3.12 fournit le diagramme de séquences relatif au sprint "Intégration paiement".
FS-SFAX Page 53
F IGURE 3.12: Diagrrame de séquences « Intégration paiement »
FS-SFAX Page 54
3.7 Conclusion
Dans ce chapitre, nous avons appliqué soigneusement la méthode agile SCRUM sur notre cahier
des charges décrit dans le chapitre 1. Ainsi, nous avons identifié les 22 user-stories du document
Backlog Product de notre projet. Ensuite, nous avons découpé le Backlog Product en trois releases.
Release 1 comporte 3 sprints, Release 2 englobe 8 sprints et Release 3 contient 5 sprints. Chaque
sprint est un sous-ensemble de l’ensemble de référence Backlog Product. Nous avons vérifié que
l’union mathématique de 16 sprints sont egale à l’ensemble de référence Bcklog Product. De
même, nous avons vérifié que l’intersection mathématique de tous les sprints sont l’ensemble
vide. Enfin, nous avons détaillé uniquement deux sprints concernant chaque release . Dans le
chapitre suivant, nous allons extraire les aspects statiques de notre logiciel TuniShop écrit en Go
en appliquant un processus de rétro-ingéniérie. En outre, nous allons documenter les sprints en
utilisant la technologie Swagger. Enfin, nous allons décrire les interfaces conviviales fournies par
notre logiciel.
FS-SFAX Page 55
Chapitre
4
Documentation
Sommaire
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2 Extraction d’un diagramme de classes . . . . . . . . . . . . . . . . . . . . . . 57
4.3 Documentation Swagger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4 Interfaces Homme-Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
FS-SFAX Page 56
CHAPITRE 4. DOCUMENTATION
4.1 Introduction
Ce chapitre est consacré à la documentation a posteriori de notre logiciel "TuniShop". Dans un

premier temps, nous allons extraire les aspects statiques du logiciel en Go. Ces aspects statiques
sont fournit sous forme d’un diagramme de classes. Dans un deuxiéme temps, nous allons produire
de la documentation des sprints en utilisant Swagger. Enfin, nous allons décrire les interfaces
Homme-Machine proposées par notre logiciel TuniShop.
4.2 Extraction d’un diagramme de classes
Le logiciel TuniShop est produit selon la méthode agile Scrum. Les sprints sont réalisés, modifés,
testés et enrichis au fur et à mesure en fonction des besoins de l’utilisation. Pour des raisons liées
à la maintenance logicielle englobant notamment l’évolutivité, nous allons dans la suite proposer
des régles permettant l’extraction des aspects statiques sous forme d’un diagramme de classes de
notre logiciel TuniShop. Ce travail s’inscrit dans le cadre de la rétro-ingénierie[18] appliquée au
code souce Go.
L’extraction d’un diagramme de classe UML à partir d’un code source Go comporte deux étapes :
Etape 1 : Génération des classes UML
Regrouper les structures (type struct) et ses fonctions comme des classes UML. Les champs de
type simple venant d’une structure donnée sont assimilés à des attributs UML. Et les fonctions
ayant un paramàtre à base de la dite struct sont assimilàs à des méthodes UML (voir Figure 4.1)
FS-SFAX Page 57
F IGURE 4.1: Exemple d’extraction d’une classe métier à partir d’une structure
Etape 2 : Génération des associations binaires UML

L’identification des associations binaires inter-classes s’appuie sur des champs figurant dans le
type struct traité. Un champ à base d’un autre struct retenu comme classe lors de l’Etape 1 est
considéré comme une association (voir figure 4.2 et 4.3).
F IGURE 4.2: Exemple d’extraction des méthodes à partir d’une structure
FS-SFAX Page 58
F IGURE 4.3: Exemple d’extraction d’une association à partir du code
FS-SFAX Page 59
En appliquant manuellement les deux Etapes 1 et 2 décrites précédement sur le code source de
notre projet, nous avons obtenu le diagramme de classe fourni par la figure 4.4 .
F IGURE 4.4: Diagramme de classe issu de notre logiciel TuniShop
FS-SFAX Page 60
4.3 Documentation Swagger
Swagger est la technologie la plus appréciée pour la documentation API. Plus précisément, pour
documenter les API REST, très souvent utilisées. Swagger a été développé par Reverb, mais il
s’agit désormais d’une solution indépendante et open source, sous la gouvernance de la fondation
Linux, et plus précisément de l’OpenAPI Initiative. Avec ce changement d’acteurs, Swagger a
été rebaptisé « spécification OpenAPI », même s’il reste officieusement connu sous le nom plus
accrocheur de « Swagger ».[19] La figure 4.5 présente le logo du Swagger.
F IGURE 4.5: Logo du Swagger
Nous avons utilisé avec profit la technologie Swagger afin d’extraire les interfaces des fonctions
Go (Voir figure 4.6 et 4.7)
FS-SFAX Page 61
F IGURE 4.6: la documentation Swagger du sprint "Gestion des employés"
FS-SFAX Page 62
F IGURE 4.7: la documentation Swagger détaillé de la fonction «GetAllUsers»
4.4 Interfaces Homme-Machine
Les interfaces Homme-Machine proposées par notre logiciel TuniShop sont produites en réutilisant
la technologie Angular(voir 2.4.4).
Les figures 4.7, 4.8, 4.9 et 4.10 représentent les interfaces de s’inscrire dans notre application
FS-SFAX Page 63
F IGURE 4.8: Informations sur l’entreprise
F IGURE 4.9: Informations personnelles
F IGURE 4.10: Email de vérification de l’inscription
FS-SFAX Page 64
F IGURE 4.11: Code de vérification
Les figures 4.11, 4.12 et 4.13 représentent les interface d’oubli de mot de passe
F IGURE 4.12: Mot de passe oublié
FS-SFAX Page 65
F IGURE 4.13: Email de réinitialiser le mot de passe
F IGURE 4.14: Réinitialisation du mot de passe
Les figures 4.14, 4.15, 4.16 et 4.17 représentent les interfaces de certaines fonctionnalités de notre
application
FS-SFAX Page 66
F IGURE 4.15: Liste des utilisateurs
F IGURE 4.16: List des Clients
FS-SFAX Page 67
F IGURE 4.17: Paramètres de boutique
F IGURE 4.18: Ajout d’Attribut
Les figures 4.18, 4.19 et 4.20 représentent les interfaces de notre boutique
FS-SFAX Page 68
F IGURE 4.19: Profil du Client
F IGURE 4.20: Page d’accueil de boutique
FS-SFAX Page 69
F IGURE 4.21: Panier du client
4.5 Conclusion
Dans ce chapitre, nous avons fourni de la documentation liée a notre logiciel de gestion d’une
boutique numérique TuniShop. Cette documentation comporte un diagramme de classe extrait
manuellement à partir de code source du logiciel, des API liées aux sprints et des interfaces
Homme-Machine.
FS-SFAX Page 70
CONCLUSION GÉNÉRALE
En appliquant soigneusement la méthode agile SCRUM, nous avons développé un logiciel

TuniShop permettant la gestion des boutiques numériques modernes. Le logiciel comporte 22
user stories distrubuées sur 18 sprints. Cette logiciel a été dévoen utilisant principalement les
technologies modernes appropriées suivantes : language de programmation Go, faramwork
Gin dvdié pour la programmation Web, bibliothéque GORM et framwork Angular dédié aux
interfaces Homme-Machine. Quant aux perspectives de ce travail, nous pourrions envisager les
prolongement suivants :
• proposer des modules de statistiques

• améliorer d’avantage les protocoles de sécurité liés à l’utilisation de notre logiciel
• automatiser le processus d’extraction des aspects statiques sous d’un diagramme de classe
UML proposé dans le chapitre 4.
FS-SFAX Page 71
BIBLIOGRAPHIE
[1] Tunisian Cloud. TC Company Information [en ligne]. Disponible sur :

https ://www.tunisiancloud.com/
[2] Méthode Classique. Introduction de la méthode classique [en ligne]. Disponible sur :
https ://www.appvizer.fr/magazine/operations/gestion-de-projet/methode-classique-gestion-de-projet
[3] Méthode Agile. Définition de la méthode agile [en ligne]. Disponible sur :
https ://www.redhat.com/fr/devops/what-is-agile-methodology : :text=La
[4] Manifeste Agile. Le minifeste agile Disponible sur :

https ://blog.myagilepartner.fr/wp-content/uploads/2019/10/Manifeste-agile-Scrum-PDF.pdf
[5] Framework Scrum. Définition de la méthode agile Scrum Disponible sur :

https ://www.planzone.fr/blog/quest-ce-que-la-methodologie-scrum
[6] Golang. Documentation de la language Golang Disponible sur :

https ://go.dev/doc/
[7] Gorm. Documentation de la bibliothèque GORM Disponible sur :

https ://gorm.io/docs/index.html
[8] Gin. Documentation de la framework Gin Disponible sur :

https ://gin-gonic.com/docs/
[9] Angular. Documentation de la framework Angular Disponible sur :

https ://angular.io/guide/what-is-angular
[10] PostgresSQL. Documentation du PostgresSQL Disponible sur :

https ://www.postgresql.org/docs/
[11] Postman. Documentation du logiciel Postman Disponible sur :

https ://www.postman.com/company/about-postman/
FS-SFAX Page 72
BIBLIOGRAPHIE
[12] Ngrok. Documentation du logiciel Ngrok Disponible sur :

https ://ngrok.com/docs
[13] Gitlab. Documentation Gitlab Disponible sur :

https ://about.gitlab.com/company/
[14] Draw.io. Documentation Draw.io Disponible sur :

https ://www.drawio.com/
[15] Trello. Documentation du Trello Disponible sur :

https ://trello.com/guide/trello-101
[16] Twilio. Documentation du Twilio Disponible sur :

https ://www.capterra.fr/software/180158/twilio-communications-platform
[17] Paymee. Définition du Paymee Disponible sur :

https ://linstant-m.tn/single-article/ar2938 p aymee − la − start − up − qui − va −
revolutionner − les − modes − de − paiement
[18] Rétro-ingénierie. Définition de la méthode de rétro-ingénierie Disponible sur :

https ://staff.info.unamur.be/dbm/publication/1996/inforsid96.pdf
[19] Swagger. Documentatio Swagger Disponible sur :

https ://www.ionos.fr/digitalguide/sites-internet/developpement-web/quest-ce-que-swagger/
FS-SFAX Page 73

Tuni Shop

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tuni Shop

Uploaded by

Copyright:

Available Formats

DEDICATION

À mes professeurs. Je tiens à exprimer ma profonde gratitude et ma reconnaissance. Leur

FS-SFAX Page iii

LISTE DES FIGURES viii

Liste des tableaux ix

LISTE DES ABRÉVIATIONS x

2 Méthode et outils utilisés 11

3 Développement d’une boutique numérique

3.5.1.4 Diagramme de séquences . . . . . . . . . . . . . . . . . . . . . 41

1.1 Logo de Tunisian Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Méthode classique de développement . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Découpage du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Exemple d’extraction d’une classe métier à partir d’une structure . . . . . . . . . . 58

FS-SFAX Page vii

4.5 Logo du Swagger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

FS-SFAX Page viii

1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Equipe et rôles Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Backlog product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

API Application Programming Interface

CI/CD Continuous Integration/Continuous Delivery

JWT JSON Web Tokens

HTTP Hypertext Transfer Protocol

HTML HyperText Markup Language

ORM Object-Relational Mapping

OOP Object-Oriented Programming

OWASP Open Web Application Security Project

REST Representational state transfer

UML Unified Modeling Language

URL Uniform Resource Identifier

Ce rapport comporte quatre chapitres

Le quatrième chapitre a pour objectif de fournir une documentation crédible extraite

1.2 Entreprise d’accueil

F IGURE 1.1: Logo de Tunisian Cloud

1.2.1 Conseil en cloud computing

1.3 Context du projet

1.3.2 Solutions proposées

1.4 Cahier des charges

1.4.1 Identification des acteurs

Client Cet acteur peut interagir avec les

Administrateur Cet acteur occupe le poste le plus élevé

Employé Cet intervenant est principalement

TABLE 1.1: Identification des acteurs

1.4.2 Identification des besoins fonctionnels

Administrateur Permettre de gérer l’entreprise

Employé Permettre de gérer les boutiques au sein de l’entreprise à

Client Permettre de consulter les boutiques et parcourir ses

TABLE 1.2: Les besoins fonctionnels

1.4.3 Identification des besoins non fonctionnels

2.2 Méthode classique de développement

La méthode classique de gestion de projet, également appelée méthode traditionnelle ou méthode

F IGURE 2.1: Méthode classique de développement

La méthode classique de développement, également connue sous le nom de modèle en cascade,

• Manque de flexibilité : la méthode classique de gestion de projet ne permet aucun retour en

2.3 Méthode agile

F IGURE 2.2: Itération agile

La phase de Refactoring permet d’améliorer le code sans toucher à son conportement.

2.3.4 Méthode retenue SCRUM

F IGURE 2.3: La méthode SCRUM

La méthodologie SCRUM fait intervenir trois rôles principaux qui sont :

Personnes Rôles Scrum

Mr. Lamouchi Bassem Product Owner

Mr. Hedi Manai Scrum Master