Safé Et Zeineb

Ministère de l’enseignement supérieur
et de la recherche scientifique
Université de Tunis
RAPPORT DE FIN D’ÉTUDES EN VUE DE L’OBTENTION DU DIPLÔME DE
« LICENCE EN BUSINESS COMPUTING »

SPÉCIALITÉ : E-BUSINESS
Conception et développement d’une

plateforme e-learning
Réalisé par Encadrant :

KHEDHER Zeineb académique : Dr. BOUZIRI Hend
SELMI Safé professionnel : Mr. HAMDI Sayed
Organisme d’accueil « Opuskills Lab »
2021-2022
J’autorise ces étudiants à faire le dépôt de leur rapport de stage en vue d’une
soutenance.
Encadrant professionnel, HAMDI Sayed
Signature et cachet
J’autorise ces étudiants à faire le dépôt de leur rapport de stage en vue d’une
soutenance.
Encadrant académique, BOUZIRI Hend
Signature
1
DÉDICACE
Nous dédions ce modeste travail à :

“ À nos chers parents,
En premier lieu ceux que personne ne peut compenser les
sacrifices qu’ils ont consenti pour notre éducation et notre bien
être à nos parents qui se sont sacrifiés pour nous prendre en
charge tout au long de notre formation et qui sont à l’origine de
notre réussite.
À nos famille et nos amis,
qui nous ont accordé leur soutien dans les instants les plus
difficiles.
À l’équipe d’OPUS LAB,
Pour leurs efforts continus, les moments que nous avons vécu
ensemble et les souvenirs qu’on a eu au cours de ce stage.
”
SELMI Safé
KHEDHER Zeineb
2
REMÉRCIMENT
Nos remerciements les plus sincères vont à toute personne ayant eu la bonté et la
patience de satisfaire notre curiosité et de nous aider dans notre travail par leur
précieux conseils, réponses et recommandations.
Nous tenons à remercier notre CEO BEN BOUZID Ahmed, notre encadrant de stage
HAMDI Sayed et notre graphic designer GHARBI Siwar qui nous ont offert l’opportunité
d’effectuer ce stage dans les meilleures conditions et qui nous ont fortement
impressionné par leurs grandes expériences et leur concrète contribution au bon
déroulement de ce travail.
À notre encadrant académique DR BOUZIRI Hend, nous adressons notre plus profonde
reconnaissance pour son bon encadrement et pour les conseils fructueux qu’elle n’a cessé
de nous prodiguer.
Nous devons chaque bribe de notre connaissance à nos enseignants à l’ESSECT qui ont
si bien mené leur noble quête d’enseigner les bases du génie logiciel, nous les remercions
pour le savoir qu’ils nous ont transmis.
Que messsieurs les membres du jury trouvent ici l’expression de notre reconnaissance
pour avoir accepté d’évaluer notre travail.
Et toutes les personnes qui ont contribué de prés ou de loin au bon déroulement de ce
travail, qu’elles voient en ces mots l’expression de notre gratitude pour leur présence,
pour leur dévouement et pour l’aide inestimable qu’elles nous ont apportées au long de
ce parcours .
3
TABLE DES MATIÈRES
Dédicace 2
Remérciment 3
Introduction générale 16
1 Etude préliminaire 18
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . 19
1.1 Organigramme de la startup . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2 Incubateur de la startup : BIATLABS . . . . . . . . . . . . . . . . . . . . . 20
2 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1 Benchmarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3 Méthodologie adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1 Cycle de vie de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Artéfacts SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Répartition de rôles avec SCRUM . . . . . . . . . . . . . . . . . . . . . . 29
4 Choix technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4
5.1 Architecture et stacks utilisés . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2 Architecture logique backend . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Architecture logique front-end . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4 Architecture physqique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2 Plannification du projet 38
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.4 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . 46
3 Pilotage du projet avec SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.1 Équipe et rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3 Structure et découpage du projet . . . . . . . . . . . . . . . . . . . . . . . 50
3.4 Planning de la réalisation du projet . . . . . . . . . . . . . . . . . . . . . 51
3.5 Diagramme de Gantt du projet . . . . . . . . . . . . . . . . . . . . . . . 52
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3 SPRINT 1 - Authentification et gestion des comptes 53

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.1 Diagramme de cas d’utilisation du sprint . . . . . . . . . . . . . . . . . . 56
2.2 Raffinement des diagrammes de cas d’utilisation du sprint . . . . . . . . 56
2.3 Description textuelles des cas d’utilisation . . . . . . . . . . . . . . . . . 58
3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.1 Diagrammes de séquence détaillés . . . . . . . . . . . . . . . . . . . . . . 61
5
3.2 Diagramme de classe global du premier sprint . . . . . . . . . . . . . . . 65
4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.1 Schémas de la base de données . . . . . . . . . . . . . . . . . . . . . . . 66
4.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3 Interfaces de la plateforme . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5 Tests unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4 SPRINT 2 - Gestion du contenu de la plateforme 76

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.1 Diagramme de cas d’utilisation de sprint . . . . . . . . . . . . . . . . . . 78
2.2 Raffinement des diagrammes des cas d’utilisation . . . . . . . . . . . . . 79
2.3 Descriptions textuelles des cas d’utilisation . . . . . . . . . . . . . . . . . 80
3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.1 Diagrammes de cas d’utilisations détaillés . . . . . . . . . . . . . . . . . 85
3.2 Diagramme de classe global du sprint . . . . . . . . . . . . . . . . . . . . 89
4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.3 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5 Tests unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5 SPRINT 3 - Exploitation du contenu de la plateforme 104

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
2.1 Diagramme de cas d’utilisation du sprint . . . . . . . . . . . . . . . . . . 107
2.2 Raffinement des diagrammes de cas d’utilisation . . . . . . . . . . . . . . 107
2.3 Descriptions textuelles des cas d’utilisation . . . . . . . . . . . . . . . . 109
3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6
3.1 Diagrammes de séquences détaillés . . . . . . . . . . . . . . . . . . . . . 112
3.2 Diagramme de classe global du sprint . . . . . . . . . . . . . . . . . . . . 115
4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.3 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5 Tests unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6 SPRINT 4 - Forum et statistiques 129

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
2.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . 132
2.2 Raffinement des cas d’utilisation du sprint . . . . . . . . . . . . . . . . . 132
2.3 Description textuelles des cas d’utilisation . . . . . . . . . . . . . . . . . 134
3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
3.1 Diagrammes de séquence détaillés . . . . . . . . . . . . . . . . . . . . . . 136
3.2 Diagramme de classe du sprint . . . . . . . . . . . . . . . . . . . . . . . . 139
4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
4.2 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
4.3 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Conclusion et Perspectives 145
Références bibliographiques 148
7
LISTE DES TABLEAUX
1.1 Points forts et points faibles de DataCamp . . . . . . . . . . . . . . . . . . . . . . 22

1.2 Points forts et points faibles de Taki Academy . . . . . . . . . . . . . . . . . . . . 23
1.3 Points forts et points d’efforts de Khan Academy . . . . . . . . . . . . . . . . . . 24
1.4 Analyse générale de l’étude d’exsistant . . . . . . . . . . . . . . . . . . . . . . . 25
1.5 Rôles définis par SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.2 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.1 Backlog du produit sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.2 Description textuelle du cas d’utilisation « S’authentifier » . . . . . . . . . . . . . 59
3.3 Description textuelle du CU « Modifier profil » . . . . . . . . . . . . . . . . . . . 60
3.4 Description textuelle du cas d’utilisation « Chercher apprenant » . . . . . . . . . 61
3.5 Collection User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.6 Collection rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.7 Collection Ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.8 Collection refreshToken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.1 Backlog du produit sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.2 Description textuelle du cas d’utilisation « Ajouter parcours » . . . . . . . . . . . 81
4.3 Description textuelle du cas d’utilisation « Ajouter skill » . . . . . . . . . . . . . . 82
4.4 Description textuelle du cas d’utilisation « Modifier skill » . . . . . . . . . . . . . 83
8
4.5 Description textuelle du cas d’utilisation « Supprimer skill » . . . . . . . . . . . . 84
4.6 Description textuelle du cas d’utilisation « Chercher path » . . . . . . . . . . . . 84
4.7 Collection Super skill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.8 Collection skill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.9 Collection quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.10 Collection checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.11 Collection projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.12 Collection Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.13 Collection path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.14 Collection challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.15 Collection edge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

5.2 Description textuelle du cas d’utilisation « S’inscrire à un parcours » . . . . . . . 110
5.3 Description textuelle du Cas d’utilisation «Consulter skill» . . . . . . . . . . . . . 110
5.4 Description textuelle du cas d’utilisation « Affecter apprenant » . . . . . . . . . . 111
5.5 Description textuelle du cas d’utilisation «Corriger travaux des étudiants » . . . . 112
5.6 Collection Voucher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.7 Collection Affect instructor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.8 Collection Enrolled path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.9 Collection Node status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

6.3 Description textuelle du cas d’utilisation « Consulter pourcentage des apprenants
inscrits » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
6.4 Description textuelle du cas d’utilisation « Consulter nombre de nœuds visités par
jour » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
6.5 Collection message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.6 Collection sallon de communication . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.7 Collection membres du sallon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.8 Collection statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
9
TABLE DES FIGURES
1.1 Organigramme d’OpusLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.2 Interface de DataCamp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3 Taki Academy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.4 Khan Academy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.5 Cycle de vie de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.6 React JS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.7 Node JS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.8 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.9 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.10 Express JS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.11 REST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.12 Tailwind CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.13 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.14 Redux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.15 Amazon Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.16 Redis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.17 Stack utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.18 Architecture Logique BackEnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.19 Model View ViewModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.20 architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.21 L’architecture détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10
2.1 Visual Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.2 Google chrome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.3 Github . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4 Gitlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.5 Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.6 XD Adobe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.7 Draw.io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.8 Overleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.9 Microsoft Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.10 Acteurs du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.11 Diagramme de cas d’utilisation général . . . . . . . . . . . . . . . . . . . . . . . 47
2.12 Découpage en sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.13 Structuration des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.14 Structuration des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.15 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.1 Diagramme de cas d’utilisation général du sprint 1 . . . . . . . . . . . . . . . . . 56

3.2 Analyse de cas d’utilisation « Gérer comptes utilisateurs » . . . . . . . . . . . . . 57
3.3 Analyse du cas d’utilisation « Gérer étudiants » . . . . . . . . . . . . . . . . . . . 57
3.4 Anlyse du cas d’utilisation « Modifier paramètres du compte » . . . . . . . . . . . 58
3.5 Diagramme de séquence détaillé «Créer compte» . . . . . . . . . . . . . . . . . . 62
3.6 Diagramme de séquence détaillé «S’authentifier» . . . . . . . . . . . . . . . . . . 63
3.7 Diagramme de séquence détaillé «Modifier email» . . . . . . . . . . . . . . . . . 64
3.8 Diagramme de séquence détaillé «Lister étudiants» . . . . . . . . . . . . . . . . . 64
3.9 Diagramme de séquence détaillé «Ajouter étudiant» . . . . . . . . . . . . . . . . 65
3.10 Diagramme de classe global du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . 65
3.11 Authentification avec JWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.12 Inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.13 Liste des étudiants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.14 Modal d’ajout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.15 Connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.16 Gérer compte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.17 Code souce du test unitaire du cas d’utilisation « Créer compte » . . . . . . . . . 72
11
3.18 Resultat du premier test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.19 Resultat du deuxieme test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.20 Code souce du test unitaire du cas d’utilisation «S’authentifier » . . . . . . . . . . 74
3.21 Resultat du premier test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.22 Resultat du deuxieme test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.1 Diagramme de cas d’utilisation du sprint 2 . . . . . . . . . . . . . . . . . . . . . 79

4.2 Raffinement de cas d’utilisation «Gérer nœuds» . . . . . . . . . . . . . . . . . . 79
4.3 Raffinement de cas d’utilisation «Gérer skill» . . . . . . . . . . . . . . . . . . . . 80
4.4 Raffinement de cas d’utilisation «Gérer path» . . . . . . . . . . . . . . . . . . . . 80
4.5 Diagramme de séquence détaillé «Créer path» . . . . . . . . . . . . . . . . . . . 85
4.6 Diagramme de séquence détaillé "Lister quiz» . . . . . . . . . . . . . . . . . . . . 86
4.7 Diagramme de séquence détaillé «Ajouter quiz» . . . . . . . . . . . . . . . . . . . 87
4.8 Diagramme de séquence détaillé «Modifier quiz» . . . . . . . . . . . . . . . . . . 88
4.9 Diagramme de séquence détaillé «Supprimer quiz» . . . . . . . . . . . . . . . . . 89
4.10 Diagramme de classe global sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.11 Lister les super skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.12 Lister les skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.13 Gestion des nœuds et des paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.14 Ajouter nœud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.15 Modifier nœud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.16 Supprimer nœud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.17 Interface créer path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.18 Liste des paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.19 Liste des challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.20 Test de l’upload d’un fichier .md . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.21 Résultat des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.22 Test d’ajout d’un challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.23 Résultat du test 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.24 Résultat du test 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.25 Test unitaire du cas d’utilisation « Modifier super skill » . . . . . . . . . . . . . . . 102
4.26 Résultat du test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
12
5.1 Diagramme de cas d’utilisation du sprint . . . . . . . . . . . . . . . . . . . . . . 107
5.2 Raffinement de cas d’utilisation «S’inscrire à un path» . . . . . . . . . . . . . . . 108
5.3 Raffinement de cas d’utilisation «Corriger travaux des étudiants» . . . . . . . . . 108
5.4 Raffinement de cas d’utilisation «Suivre path» . . . . . . . . . . . . . . . . . . . 109
5.5 Diagramme de séquence détaillé «Passer nœud suivant» . . . . . . . . . . . . . . 113
5.6 Diagramme de séquence détaillé «Passer quiz» . . . . . . . . . . . . . . . . . . . 114
5.7 Diagramme de séquence détaillé «Passer special quiz» . . . . . . . . . . . . . . . 114
5.8 Diagramme de séquence détaillé «Passer special quizzes» . . . . . . . . . . . . . 115
5.9 Diagramme de séquence détaillé «Affecter étudiant» . . . . . . . . . . . . . . . . 115
5.10 Diagramme de classe global du sprint . . . . . . . . . . . . . . . . . . . . . . . . 116
5.11 Suivre path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.12 S’inscrire à un path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.13 Lister superskills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.14 Parcours de l’étudiant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.15 Interface superskill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.16 Interface skill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.17 Interface Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.18 Interface Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.19 Interface des quiz suggérés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.20 Interface projet final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.21 Interface liste des étudiants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.22 Interface correction travaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.23 Test unitaire du cas d’utilisation « Affecter instructeur » . . . . . . . . . . . . . . 125
5.24 résultat du premier cas de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.25 résultat du deuxième cas de test . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.26 Test unitaire du cas d’utilisation « Consulter skill » . . . . . . . . . . . . . . . . . 127
5.27 Résultat du premier cas de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.28 Résultat du deuxième cas de test . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6.1 Diagramme de cas d’utilisation du sprint 4 . . . . . . . . . . . . . . . . . . . . . 132

6.2 Raffinement de cas d’utilisation «Consulter les statistiques de la plateforme» . . 133
13
6.5 Diagramme de séquence détaillé «Consulter nombre des utilisateurs» . . . . . . 136
6.6 Diagramme de séquence détaillé «Visualiser le pourcentage des nœuds consultés
et non consultés par jour» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.7 Diagramme de séquence détaillé «Visualiser les classes d’âges des apprenants» . 137
6.8 Diagramme de séquence detaillé «Lister les chat rooms» . . . . . . . . . . . . . . 138
6.9 Diagramme de séquence detaillé «Créer chat room» . . . . . . . . . . . . . . . . 138
6.10 Diagramme de classe su quatrième sprint . . . . . . . . . . . . . . . . . . . . . . 139
6.11 Créer room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.12 interface statistique de l’administrateur . . . . . . . . . . . . . . . . . . . . . . . 142
6.13 interface statistique de l’étudiant . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.14 interface statistique du créateur de cours . . . . . . . . . . . . . . . . . . . . . . 143
6.15 interface créer chat room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
6.16 interface forum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
14
Introduction générale
LISTE DES ACRONYMES
LMS : Learning Management System

MENA : Une région du monde comportant l’Afrique du Nord et le Moyen-Orient
UML : Unified Modeling Language
MVVM : Model-View-ViewModel
TCP : Transmission Control Protocol
API : Application Programming Interface
SGBD : Relational DataBase management System
CLI : Command-Line Interface
MERN : Mongodb-Express-ReactJs-NodeJs
REST : Representational State Transfer
API : Interface de Programmation d’Application
JWT : JSON Web Token
AWS : Amazon Web Service
HTTP : Hypertext Transfer Protocol
15
INTRODUCTION GÉNÉRALE
A
U cœur de la digitalisation, par le temps qui presse, l’Homme a pris conscience des nou-
veaux défis qui prennent place partout : dans les espaces publics, les lieux de travail,
dans nos foyers, nos vêtements sur nos corps et dans l’ensemble des objets qui nous
entourent.
L’évolution du marché de l’emploi et des compétences nécessaires, ont conduit à la naissance

de nouveaux emplois, on peut avoir des exemples comme développeur web , développeur mo-
bile, web designer, community manager, ingénieur data scientist, intelligence artificielle et la
robotique.
Le digital redessine le paysage des emplois et des compétences, revêt divers costumes dont
certains seront évident pour que finalement la personne pointe son objectif et fait en sorte que
la palette des outils et des techniques s’étoffe régulièrement. En vous orientant vers les métiers
du numérique, vous pourrez également changer plusieurs fois de statut au cours de votre car-
rière. Les professionnels du digital peuvent ainsi commencer par un emploi salarié et devenir
indépendants s’ils souhaitent effectuer des missions en freelance. Mais l’inverse est tout à fait
possible, si vous ressentez le besoin de vous poser dans un cadre plus stable.
Tout le monde a sa place dans le digital. L’important est de trouver le métier qui vous corres-
pond le mieux, le numérique apporte de nouveaux concepts, de nouveaux savoirs et les trans-
forment, il remet en question son impact sur certains secteurs.
Le secteur de l’éducation n’échappe pas à cette transformation, la pédagogie digitale est de-
venue l’une des formes d’apprentissage les plus adéquates pour la génération actuelle. La trans-
formation digitale dans le secteur de l’éducation est devenue essentielle, elle a pris un nouveau
16
Introduction générale
tournant et surtout avec la pandémie. Le COVID-19 a remis en question le modèle traditionnel

d’éducation en classe et a prouvé que l’apprentissage est possible de n’importe où.C’est ainsi que
l’idée de notre produit s’est imposée.
L’éducation doit-elle inventer de nouvelles formes, de nouveaux périmètres dans le paysage

des disciplines ? Si le numérique ne peut à l’évidence résoudre tous les problèmes de l’apprentis-
sage et de l’enseignement, comment permettre au système éducatif de tirer parti de ses avantages
et de ses atouts ?
Notre plateforme est spécialisée dans les compétences digitales ( graphic design, développe-
ment web, montage vidéo, digital marketing et intelligence artificielle ). Elle présente des forma-
tions approfondies, et adapte le contenu selon les compétences et l’avancement de l’apprenant.
Notre produit offre un système de suivi spécifique et essaie d’améliorer et de développer les
compétences des apprenants en se basant sur des nouvelles techniques d’apprentissage. En effet,
en se référant à l’approche de gamification dans notre système, on peut encourager l’apprenant
à collecter un maximum de points en suivant son path afin de participer aux challenges qui lui
permet de vivre et de gagner une expérience professionnelle et surtout d’être parmis les premiers
et les meilleurs apprenants sur notre plateforme.
Pour ce faire, ce rapport est structuré en 6 chapitres. Le premier chapitre présentera l’orga-
nisme d’accueil et introduira la problématique, l’étude de l’existant et la solution proposée. Le
deuxième chapitre fera l’objet d’une étude de la méthodologie choisie ainsi que quelques no-
tions des technologies utilisées. Les chapitres qui suivent comporteront nos sprints suivant la
méthodologie SCRUM. chaque sprint présentera le backlog du produit, la spécification de be-
soins ,la conception , la réalisation et le test unitaire.
17
CHAPITRE 1
ETUDE PRÉLIMINAIRE
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . 19
2 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3 Méthodologie adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4 Choix technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
18
Chapitre1 : Étude Préalable
Introduction
« Une plateforme e-learning ou LMS, pour Learning Management System, peut se définir
comme un portail web à double entrée. Pour l’apprenant, c’est l’espace de formation qui lui per-
met d’accéder aux parcours mis à sa disposition. Pour le formateur et l’administrateur, c’est l’outil
qui permet le pilotage des formations digitales et hybrides, depuis leurs mises à disposition, jus-
qu’au suivi des statistiques d’utilisation. » [1]
Nous commençons par placer le projet dans son cadre général et d’exposer le contexte de
travail ainsi que les objectifs a atteindre.
1 Présentation de l’organisme d’accueil

Opuslab est un cabinet de formation agile, spécialisé dans les compétences digitales qui sont :
Le développement web, le design graphique et le marketing digital.
Opuslab est une startup fondée en Mars 2021 par ces trois cofondateurs Ahmed BEN BOU-
ZID, Siwar GHARBI et Sayed HAMDI. La première cohorte ( un programme d’incubation et d’ac-
compagnement de jeunes porteurs d’idées)était une formation en développement web niveau
1 qui a été lancé le 06 mars 2021. En avril 2021 Opus lab a fait plus de 15 cohortes et a fait un
impact à plus de 1500 étudiants. En juin 2021 Opus lab a réussi à rejoindre le programme de pré-
incubation de la BIATLABS parmi 32 autres idées, en septembre a validé l’idée du projet avec 10
autres.
Opus lab offre des formations en Digital skills en Business to Client (pour les étudiants) aussi
en Business to Business (pour les entreprises, les organismes, les associations . . .).
Le but d’OpusLab est de délivrer le meilleur contenu et fournir le cadre idéal qui favorise
l’apprentissage et le partage afin d’aider les étudiants à s’améliorer en compétences digitales.
Ainsi que Devenir une référence dans le marché Tunisien et de la région MENA.
L’originalité du produit, ce dernier est spécialisé dans les compétences digitales qui présentent
un contenu approfondi et intelligent (selon les compétences de l’utilisateur) ainsi qu’un système
de suivi et contrôle.
19
1.1 Organigramme de la startup
L’organigramme de la start-up "OpusLab" figure 1.1 présente une vue parfaite de l’oraganisa-
tion des liens hiéarchiques entre les différentes équipes. En effet, c’est une traduction schéma-
tique des objectifs, des missions et des relations fonctionnelles.
FIGURE 1.1 – Organigramme d’OpusLab
La présentation de l’organigramme facilite la compréhension des relations de travail entre les

différents membres de chaque équipe.
1.2 Incubateur de la startup : BIATLABS
BIATLABS est l’incubateur de BIAT, incubateur à but non lucratif qui offre un accompagne-
ment aux entrepreneurs gratuitement et sans équité et couvre le cycle de vie de l’incubation :
pré-incubation, incubation et post-incubation.
Sa vision est d’appuyer l’innovation et l’ambition des jeunes, et de contribuer à l’émergence
d’un écosystème propice à l’entrepreneuriat, à l’investissement et au business, au profit de l’éco-
nomie tunisienne de demain.
Sa mission est d’accompagner des entrepreneurs,à haut potentiel, pour leur permettre de
mieux servir l’économie nationale, créer de la valeur et avoir un impact en Tunisie.
La devise est de fédérer une communauté d’entrepreneurs, de partenaires, d’experts afin de
contribuer au développement de l’écosystème entrepreneurial et économique tunisien.
20
2 Cadre du projet
Dans cette partie, nous présentons une étude de l’existant,la problématique,la solution pro-
posée et les objectifs du projet.
2.1 Benchmarking
L’apprentissage en ligne exploite les technologies interactives et les systèmes de communi-

cation pour améliorer l’expérience d’apprentissage. Il a le potentiel de transformer la façon dont
nous enseignons et apprenons à tous les niveaux. Parmis les applications qui existent on trouve :
• DATACAMP
DataCamp figure 1.2 est une plateforme MOOC « Massive Open Online Course », créée en
2014. l’entreprise se spécialise dans les cours en ligne au service de plus de 350 milles étu-
diants à travers le monde. .
FIGURE 1.2 – Interface de DataCamp
Les cours disponibles sont R, Python et la science des données sous forme de courtes
vidéos, aucune installation requise tout en assurant un centre d’aide et de ressources. En
plus, tous les instructeurs sont des experts de premier plan dans le domaine et avec ce
tableau2.1 on explique plus les points forts et faibles de Datacamp.
21
Points forts Points d’efforts
Donne l’opportunité aux apprenants pour Certaines vidéos sont un peu courtes
combiner les différents cours dans le but de leurs et manquent de détails.
aider à réussir leurs carrières.
Offre des questions de pratique et d’évaluation. Les utilisateurs doivent vraiment creuser
pour trouver des informations sur le plan
d’essai gratuit.
Communauté active. Il n’y a pas de tests formels pour évaluer

vos progrès à la fin des cours.
TABLE 1.1 – Points forts et points faibles de DataCamp
• Taki Academy
Concrètement, TakiAcademy figure 1.3 est une plateforme d’enseignement en ligne en
Tunisie. Fondée en 2013 et compte plus que 80 enseignants. Enseigne les élèves de 4ème
année primaire jusqu’au Bac (toutes les sections). La plateforme compte aujord’hui plus
de 150 000 élèves.
FIGURE 1.3 – Taki Academy
Taki Academy est une plateforme d’apprentissage axée sur les étudiants.Les cours sur
cette plateforme se font principalement à travers des vidéos encadrées par un groupe de
professeurs et éducateurs. Actuellement la plateforme compte plus de 1000 vidéos gra-
tuites qu’on peut consulter sur la chaîne youTube de l’académie. Dans le tableau1.2 on
22
expose quelques points forts et points faibles de la platforme TakiAcademy
Points forts Points faibles
Interface érgonomique et facile à utiliser. La plateforme est limitée à un seul style d’en-
seignement avec les vidéos. Ceci peut ne pas
êtres la meilleur façon d’apprendre pour cer-
tains étudiants.
Possibilité de suivre des cours en direct. Le développement des compétences en com-

munication est négligé. Cela conduira inévi-
tablement à de nombreux diplômés qui ex-
cellent dans les connaissances théoriques,
mais qui ne parviennent pas à transmettre
leurs connaissances aux autres.
TABLE 1.2 – Points forts et points faibles de Taki Academy
• Khan Academy
khan Academy figure 1.4 est une association à but non lucratif fondée en 2008 par Salman
Khan. Sur le principe de « fournir un enseignement de grande qualité à tous, partout ».
FIGURE 1.4 – Khan Academy
le site web publie en ligne un ensemble gratuit de plus de 2 200 mini-leçons, via des
tutoriels vidéo hébergés sur YouTube, abordant les mathématiques, l’informatique, l’his-
23
toire, la finance, la physique, la chimie, la biologie, l’astronomie, la musique, l’art pictural et

l’économie, ce tableau1.3 révéle quelques points forts et points faibles de KhanAcademy.
Points forts Points faibles
gratuit et accessible par tout le monde. il n y’a pas une interface d’interaction
entre les utilisateurs.
offre une expérience d’apprentissage Certains chapitres n’ont pas d’exercices et

qui rassemble à un jeu. ainsi, les étudiants n’auront pas une idée de
leurs niveaux.
TABLE 1.3 – Points forts et points d’efforts de Khan Academy
2.2 Problématique
De nombreux étudiants ne semblent pas engagés dans des cours d’apprentissage en ligne,ils
n’exploitent pas ce qu’ils ont appris en projets concrets en raison du style d’apprentissage clas-
sique fourni par la majorité des plateformes d’apprentissage en ligne. Le but de l’enseignement
est de réaliser le transfert, les étudiants doivent être capables de transférer leurs apprentissages
de la salle de classe vers la résolution de problèmes du monde réel. En les encourageant à ren-
contrer de nouvelles idées, à s’engager avec le matériel de cours et à réfléchir, dans ce tableau1.4
on compare les plateformes suivantes selon certains critères.
— Authentification et autorisation : s’assurer que l’accès aux différents espaces est protégé.
— Interface utilisateur attrayante et facile à utiliser : la simplicité et l’ergonomie des interfaces
et la facilité d’utilisation des fonctionnalités fournies.
— Gestion du profil : l’utilisateur du site dispose d’un profil avec ses informations person-
nelles.
— Fonctionnalités intelligentes : fonctionnalités qui utilisent des domaines de l’intelligence
artificielle.
— Gamification : encourager les apprenants à s’engager dans le comportement d’apprentis-
sage souhaité.
24
Data Camp Taki Academy Khan Academy
Authentification et autorisation oui oui oui
Gestion de profils oui oui oui
Fonctionnalités intelligentes oui non oui
Gamification oui non oui
Gestion des cours oui non oui
Gestion des communautés non non non
TABLE 1.4 – Analyse générale de l’étude d’exsistant
Nous avons constaté que le système éducatif, en particulier les étudiants en Tunisie, n’ont pas
des compétences nécessaires pour décrocher des stages ou des emplois, il y a un écart entre le
marché et le système éducatif.
2.3 Solution proposée
L’objectif de la plateforme est de favoriser une véritable expérience d’apprentissage pour les
étudiants en offrant un contenu de qualité et un système de suivi continu.
Séance de tutorat personnalisée : les individus ont des styles d’apprentissage différents qui
doivent être pris en compte avant de fournir du contenu.
Gestion de la communauté : les apprenants ayant des objectifs éducatifs communs colla-
borent pour se connecter avec les instructeurs, s’engager dans un apprentissage entre pairs et se
soutenir mutuellement pour atteindre les objectifs d’apprentissage.
Notre plateforme offre la possibilité de participer aux challenges avec les partenaires d’Opus-
Lab. Ceci est une opportunité pour l’étudiant en lui permettant de s’ouvrir au monde profession-
nel et de concrétiser ses connaissances acquises sur des projets réels.
Le système de score va encourager les étudiants à mieux assimiler le contenu pour avoir un
maximum de points dans les tests. En effet, notre but est de sortir du cadre d’enseignement clas-
sique et de rendre l’étudiant autonome en focalisant sur le concept d’apprendre en jouant.
La plateforme vise aussi à rendre le travail de l’instructeur aussi simple que possible, qui lui
permet de suivre l’avancement des étudiants en se basant sur des courbes et des graphes.
25
2.4 Objectifs
L’objectif d’OpusLab est d’enseigner et de partager des connaissances et de l’expertise en dé-

veloppement web, graphisme et montage vidéo. L’équipe d’Opus Lab veut enseigner ses parcours
disponibles sur une plateforme d’apprentissage en ligne tout en assurant un programme appro-
fondi contenant des exercices et des mini-projets que les étudiants doivent compléter pour ob-
tenir leurs certificats.
Plus que cela, la plateforme vise aussi à rendre le travail de l’instructeur aussi simple que
possible et essayer de restituer le contenu aussi spécifique que possible au profil de l’étudiant.
OpusLab veut former toute une génération lucide et clairvoyante de la digitalisation et ses
tendances.
3 Méthodologie adoptée
«SCRUM est une approche de gestion de projet agile qui définit le cadre des projets com-
plexes. Celle-ci permet à l’équipe de s’adapter rapidement aux changements que les clients ef-
fectuent régulièrement.» [2]
3.1 Cycle de vie de SCRUM
Le Sprint
«Un sprint est une itération : il s’agit d’une période de 1 à 4 semaines maximum pendant laquelle
une version terminée et utilisable du produit est réalisée. Un nouveau sprint commence dès la
fin du précédent. Chaque sprint implique un objectif et une liste de fonctionnalités à réaliser.»[3]
26
FIGURE 1.5 – Cycle de vie de SCRUM
Planification d’un sprint

Les tâches à accomplir pendant le sprint sont déterminées par l’ensemble de l’équipe scrum
lors des réunions de planification du sprint. Celles-ci se limitent à 8 heures pour chaque sprint
pour un mois. Elle permet à l’équipe d’établir les problématiques qu’elle va traiter au cours de ce
sprint.
Revue du sprint
Il s’agit du bilan du sprint réalisé. Une fois le sprint est terminé, l’équipe scrum et les parties pre-
nantes se réunissent pour valider ce qui a été accompli. Cette réunion dure 4 heures maximum.
Rétrospective du sprint
La rétrospective est interne à l’équipe scrum et dure 3 heures pour un sprint d’un mois. Elle vise
l’adaptation aux changements et l’amélioration continue du processus de réalisation. L’équipe
se sert de la rétrospective pour passer en revue le sprint terminé et déterminer ce qui a bien fonc-
tionné et ce qu’il faut améliorer.
27
Mêlée quotidienne
Cette réunion journalière de 15 minutes est très importante. Elle se fait debout, afin d’éviter de
s’éterniser. C’est ce qui explique que l’on parle de «stand-up meeting». Ce meeting a pour but
de faire un point sur la progression quotidienne du sprint. Cette rencontre permet à l’équipe de
synchroniser ses activités et de faire un plan pour les prochaines 24 heures.
3.2 Artéfacts SCRUM
Le mot artefact désigne un produit ayant subi une transformation, même minime par l’homme.
Les artefacts SCRUM sont basés sur un ensemble de valeurs, principes et pratiques qui four-
nissent la base de la philosophie agile. Ces artefacts ont été spécialement conçus pour maximi-
ser la transparence des informations afin que tout le monde ait la même compréhension de leur
définitions et de leur utilités.
• Le backlog produit :
Le backlog scrum est destiné à recueillir tous les besoins du client que l’équipe projet
doit réaliser. Il contient donc la liste des fonctionnalités intervenant dans la constitution
d’un produit, ainsi que tous les éléments nécessitant l’intervention de l’équipe projet. Tous
les éléments inclus dans le backlog scrum sont classés par priorité indiquant l’ordre de leur
réalisation.
• Le sprint backlog :
Le sprint backlog est une liste qui contient un certain nombre de tâches prédécoupées
sont intégrées dans ces différents cycles.
À la fin de chaque cycle, le travail accompli doit créer de la valeur pour le produit en
développement. Ces cycles sont appelés «sprints». Ils ont une date de début et une date de
fin fixe. La durée d’un sprint est toujours la même. Le guide Scrum conseille de la fixer à 2
ou 3 semaines.
• L’incrément produit :
L’incrément en scrum correspond à l’ensemble des items du backlog de produit qui ont
été accomplis pendant le sprint en cours.
28
3.3 Répartition de rôles avec SCRUM
Les rôles sont définis SCRUM dans ce tableau 1.5.
Rôle Fonctions
Product Owner Définit à quoi le produit doit ressembler et ex-

prime clairement qu’elles sont les fonction-
nalités qu’il doit contenir. C’est la seule per-
sonne responsable à :
- Développer et communiquer explicitement
le but du produit. - Créer et communiquer
clairement les éléments du Backlog de pro-
duit. - Ordonner les éléments du Backlog de
produit par priorité. - S’assurer que le Backlog
de produit est transparent, visible et compris.
Scrum Master Assure le bon déroulement de la méthodolo-

gie de SCRUM et gére la coordination entre
le product owner et l’équipe de développe-
ment.
L’équipe de developpement Constituée de 3 à 5 personnes qui réalisent

le produit. Elles comptent satisfaire toutes les
exigences techniques requises à procurer la
production, chancun doit être autonome et
doit assurer le déroulement des taches tout
en respectant les delais prescrits.
TABLE 1.5 – Rôles définis par SCRUM
4 Choix technique
Dans cette section, nous présentons la liste des langages utilisés pour le développement de
ce projet.
• React JS : «C’est une bibliothèque JavaScript figure 1.6 développée par Facebook qui per-
29
met la réalisation des applications web monopage (SPA) en utilisant des composants réutilisables.»[4]
FIGURE 1.6 – React JS
• Node JS : « NodeJS figure 1.7 est un environnement d’exécution permettant d’utiliser le

JavaScript côté serveur.» [5]
FIGURE 1.7 – Node JS
• Python «Python est un langage de programmation figure 1.8 généraliste de haut niveau.
Sa philosophie de conception met l’accent sur la lisibilité du code avec l’utilisation d’une
indentation significative. » [6]
FIGURE 1.8 – Python
• Mongo DB : « C’est un système de gestion de base de données NoSQL figure 1.9 basé sur
les documents»[7]
FIGURE 1.9 – MongoDB
30
• Express JS : «C’est un framework figure 1.10 pour construire des applications web basées
sur NodeJS.»[8]
FIGURE 1.10 – Express JS
• Rest API :
« Une API REST est un ensemble de règles figure 1.11 qui permettent l’interopérabilité
entre les clients et les serveurs. Elle s’appuie sur le protocole HTTP robuste pour échanger
des données au format JSON, qui est à la fois efficace et facile à lire pour les utilisateurs.»[9]
Images/REST +API.png
FIGURE 1.11 – REST API
« C’est aussi une solution pour partager des ressources et des informations, tout en
maintenant un certain niveau de sécurité, de contrôle et d’authentification, en détermi-
nant qui est autorisé à accéder à quoi. »[10]
• Tailwind CSS : « Tailwind figure 1.12 C’est un framework css facile à utiliser et permet de
personnaliser le design d’une page web»[11]
FIGURE 1.12 – Tailwind CSS
• Docker : « Docker est un ensemble de plateforme, figure 1.13 en tant que produit de service
qui utilise la virtualisation au niveau du système d’exploitation pour fournir des logiciels
dans des packages appelés conteneurs. Les conteneurs sont isolés les uns des autres et
regroupent leurs propres logiciels, bibliothèques et fichiers de configuration ; ils peuvent
communiquer entre eux par des canaux bien définis.»[12]
31
FIGURE 1.13 – Docker
• Redux : « Redux est une bibliothèque JavaScript open source figure 1.14 pour gérer et cen-
traliser l’état de l’application. Il est le plus couramment utilisé avec React pour créer des
interfaces utilisateur. Il a été créé par Dan Abramov et Andrew Clark.»[13]
FIGURE 1.14 – Redux
• Amazon web services(AWS) : « Amazon Web Services figure 1.15, est une filiale d’amazon
qui fournit des plates-formes de cloud computing et des API à la demande aux particuliers,
aux entreprises et aux gouvernements, sur une base de paiement à l’utilisation.»[14]
FIGURE 1.15 – Amazon Web Services
«Redis est un magasin de structure de données en mémoire figure 1.16, utilisé comme
base de données distribuée en mémoire clé-valeur, cache et courtier de messages, avec
une durabilité facultative. Redis prend en charge différents types de structures de données
abstraites, telles que les chaînes, les listes, les cartes, les ensembles, les ensembles triés, les
hyperLogLogs, les bitmaps, les flux et les index spatiaux.»[15]
32
FIGURE 1.16 – Redis
5 Architecture de l’application
Dans cette partie, nous présentons l’architecture et stacks utilisés, l’archichitecture logique
back-end, l’archichitecture logique front-end et l’architecture physique.
5.1 Architecture et stacks utilisés
Le stack MERN figure 1.18 est utilisée pour le développement de la plateforme, où MERN
signifie :
FIGURE 1.17 – Stack utilisés
— Mongodb : il s’agit d’une plateforme NoSQL, un programme de base de données orienté

document. Il est utilisé pour le stockage de données par le backend de votre application
sous la forme de documents JavaScript Object Notation.
— ExpressJs : c’est un logiciel gratuit et open-source. Il s’agit d’un framework d’application
Web et est généralement considéré comme un framework existant pour Node.js.
33
— ReactJS : il est utilisé pour créer des interfaces utilisateur et est une bibliothèque frontale
JavaScript développée par Meta.
— NodeJS : il s’agit d’un environnement d’exécution JavaScript qui permet l’utilisation de ja-
vascript dans le back-end.
5.2 Architecture logique backend
L’idée est d’utiliser le principe de séparation des préoccupations pour éloigner la logique mé-
tier des Routes API node.js. Car un jour, on aura envie d’utiliser notre logique métier sur un outil
CLI, ou dans une tâche récurrente. faire un appel API du serveur node.js à lui-même n’est pas
une bonne idée.
FIGURE 1.18 – Architecture Logique BackEnd
5.3 Architecture logique front-end
«Le modèle MVVM prend en charge la liaison de données bidirectionnelle entre View et View-
Model. Cela permet la propagation automatique des modifications, dans l’état ViewModel à la
vue. En règle générale, ViewModel utilise le modèle d’observateur pour informer le ViewModel
des modifications apportées au modèle. »[15]
— Modèle : cette couche est responsable de l’abstraction des sources de données. Model et
ViewModel fonctionnent ensemble pour obtenir et enregistrer les données.
34
— Vue : le but de cette couche est d’informer le ViewModel de l’action de l’utilisateur. Cette
couche observe le ViewModel et ne contient aucun type de logique d’application.
— ViewModel : il expose les flux de données qui sont pertinents pour la vue.
FIGURE 1.19 – Model View ViewModel
5.4 Architecture physqique
L’architecture à trois-tiers figure 1.20 est une architecture d’application logicielle qui organise
les applications en trois niveaux : le niveau de présentation, ou interface utilisateur ; le niveau
application, où les données sont traitées ; et le niveau base de données, où les données associées
à l’application sont stockées et gérées.
35
FIGURE 1.20 – architecture physique
La communication entre le serveur et le client est assurée de deux manières différentes en

fournissant une API RESTful et en utilisant WebSockets.
FIGURE 1.21 – L’architecture détaillée
— REST API : signifie "Transfert d’État représentatif", permet l’utilisation d’une architecture
de système en couches où les API sont déployées sur le serveur A, les données stockées sur
le serveur B et les demandes sont authentifiées sur le serveur C.
— Websocket : WebSocket est un protocole de communication informatique, fournissant des
canaux de communication en duplex intégral sur une seule connexion TCP. L’utilisation
de WebSockets dans notre application consiste à fournir la fonctionnalité de discussion à
l’utilisateur.
36
Conclusion
Le principal avantage du choix de l’architecture MVVM est de permettre une véritable sépa-
ration entre la vue et le modèle au-delà de la réalisation de la séparation et de l’efficacité qu’on
peut gagner. En termes réels, cela signifie que lorsque notre modèle doit changer. Il peut être
modifié facilement sans que la vue en ait besoin et vice versa.
37
CHAPITRE 2
PLANNIFICATION DU PROJET
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . 39
2 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3 Pilotage du projet avec SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
38
Chapitre2 : Étude préliminaire du projet
Introduction
Dans ce chapitre, nous avons procédé à l’analyse des besoins pour exprimer les fonctionna-
lités concrètes du produit et préciser les indicateurs de qualité de l’exécution de ces fonctionna-
lités.
1 Environnement de développement
Dans cette partie, nous présentons l’environnement matériel et logiciel dont on a utilisé pour
la réalisation de notre plate-forme.
1.1 Environnement matériel
Pour la réalisation de ce travail nous avons utilisé des ordinateurs portables.
Caractéristiques Désciption
Marque PC PORTABLE HP GAMING

PC PORTABLE ASUS GAMING
Processeur AMD Ryzen 5
Disque dur 512 Go SSD
RAM 16 GO
Carte graphique Nvidia GeForce GTX 1050
Système d’exploitation Windows 11 professionnel
TABLE 2.1 – Environnement matériel
1.2 Environnement logiciel
Dans cette section, nous présentons la liste des logiciels utilisée pour l’élobaration de notre
plate-forme .
• Visual Code :
«Visual Studio Code figure 2.1 est un éditeur de code open-source développé par Microsoft
supportant un très grand nombre de langages grâce à des extensions. Il supporte l’auto-
complétion, la coloration syntaxique, le débogage et les commandes git.»[16]
39
FIGURE 2.1 – Visual Code
• Google chrome :
« Google Chrome figure 2.2 est un navigateur web multiplateforme développé par Google.
Il a d’abord été publié en 2008 pour microsoft windows, construit avec des composants
logiciels libres d’Apple WebKit et de Mozilla Firefox. Il a ensuite été porté sur Linux, macOS,
iOS et Android.» [17]
FIGURE 2.2 – Google chrome
• GitHub :
«GitHub figure 2.3 est un site de partage de code , sur lequel on peut publier des projets
dont le code est géré avec le système de gestion de version Git . Par défaut , le système
est open source , ce qui signifie que tout le monde peut consulter le code , l’utiliser pour
apprendre ou l’améliorer et collaborer aux projets . »[18]
FIGURE 2.3 – Github
• GitLab :
« Gitlab figure 2.4 Couvre l’ensemble des étapes du DevOps. Se basant sur les fonction-
nalités du logiciel Git, elle permet de piloter des dépôts de code source et de gérer leurs
différentes versions.»[19]
40
FIGURE 2.4 – Gitlab
• Postman :
«Postman figure 2.5 est un outil gratuit permettant de tester des API»[20]
FIGURE 2.5 – Postman
• XD adobe :
« XD adobe figure 2.6 est Un logiciel incontournable de la suite Adobe Créative Cloud.
Il a vocation à faciliter la conception de maquettes, wireframes et prototypes et aboutir à
des interfaces digitales agréables et efficaces.»[21]
FIGURE 2.6 – XD Adobe
• Draw.io : «Draw.io figure 2.7 est un logiciel de dessin graphique multiplateforme gratuit et
open source. Utilisé pour créer des diagrammes UML, des organigrammes, des diagrammes
de réseau etc. »[22]
FIGURE 2.7 – Draw.io
• Overleaf :
«Overleaf figure 2.8 plateforme en ligne gratuite permettant d’éditer du texte en LATEX
sans aucun téléchargement d’application. En outre, elle offre la possibilité de rédiger des
41
documents de manière collaborative.»[23]
FIGURE 2.8 – Overleaf
• Microsoft Teams :
« Microsoft Teams figure 2.9 permet l’organisation des réunions, des conversations et
des appels , et collaborez depuis un seul endroit, que vous soyez à domicile, au travail, à
l’école.»[23]
FIGURE 2.9 – Microsoft Teams
2 Capture des besoins

La capture des besoins constitue une étape importante qui nous permet d’avoir une idée plus
claire et détaillée sur notre système. Deux types de besoins seront détectés : les besoins fonction-
nels et les besoins non fonctionnels, ainsi que les différents acteurs du système.
2.1 Identification des acteurs
Un acteur est une « entité » externe (utilisateur humain, dispositif matériel ou autre sys-
tème)au système qui interagit directement avec le système.
42
FIGURE 2.10 – Acteurs du système
Pour tous les acteurs de notre système figure 2.10 , nous définissons les différents objectifs
qu’il tente d’atteindre en utilisant la platforme.
• Administrateur :
L’administrateur est un des fondateurs de la startup qui sera chargé de superviser les comptes
utilisateurs, affecter les codes vouchers aux étudiants lors de l’inscription, créer les comptes
des instructeurs et des créateurs de cours et débloquer les paths pour l’étudiant.
• Créateur de cours :
Le créateur de cours peut être l’un des fondateurs ou bien une nouvelle personne rejoi-
gnant l’équipe après sa demande d’inscription auprès d’Opus Lab. Cette personne sera
chargée de gérer les paths disponibles et les nœuds qui les composent.
• Instructeur :
L’instructeur peut être l’un des fondateurs ou bien une nouvelle personne inscrite comme
instructeur par l’administrateur. Cet acteur sera chargé d’évaluer les checkpoints et les pro-
jets finaux des étudiants inscrits dans un path qui lui a été affecté.
• Visiteur :
Le visiteur doit remplir un formulaire d’inscription sur la plateforme et acheter un voucher
auprès d’Opus Lab pour pouvoir suivre le path qu’il a choisi.
• Etudiant (apprenant) :
L’étudiant peut suivre le path dont il a acheté : il peut suivre les super skills, les skills, passer
des quizs, faire des checkpoints et réaliser un projet final afin de collecter des points qui lui
permet par la suite à participer à des challenges disponibles sur la plateforme d’opus Lab.
43
2.2 Besoins fonctionnels
Les besoins fonctionnels sont l’expression de ce que le produit ou le service délivré par le
projet devrait être. Les besoins fonctionnels sont ordonnés selon les acteurs.
• Visiteur :
— Création compte : l’étudiant peut créer son propre compte en remplissant un formu-
laire.
• Etudiant :
— Consulter dashboard : l’étudiant peut connaître son rang dans la plateforme et son
avancement dans chaque parcours ainsi que le nombre des nœuds consultés par jour.
— Consultation des path disponibles.
— Choisir un path : l’étudiant peut choisir le parcours qui lui convient.
— Gestion de compte : chaque étudiant peut modifier les paramètres de son compte.
— Suivre path : une fois l’étudiant s’est inscrit à un path, il peut suivre ses nœuds.
— Passer quiz : après chaque skill, il existe des questions que l’étudiant doit répondre
pour passer au skill suivant.
— Passer un checkpoint : après chaque cours il est obligatoire de passer une activité qui
sera un petit programme à développer pour passer au super skill suivant.
— Réalisation du projet final : à la fin de chaque path, il y a un projet final à réaliser pour
avoir le certificat.
— Participation à un challenge : c’est une activité facultative qui demande un certain
nombre de points pour y participer.
— Consulter avancement : l’étudiant peut savoir en pourcentage son avancement dans
chaque path.
— Participer forum : l’étudiant peut envoyer et recevoir des messages à un autre étudiant
ou bien un instructeur.
• L’instructeur :
— Consulter dashboard : l’instructeur peut

— Gestion de compte : chaque instructeur peut modifier les paramètres de son compte.
44
— Consultation liste des étudiants : l’instructeur peut visualiser la liste des étudiants ins-
crits dans le path dont il est affecté.
— Evaluation de l’étudiant(test de niveau, checkpoint ,projet final ) : l’instructeur peut
noter les rendus de chaque étudiant.
— Consultation de l’avancement de l’étudiant.
— Consultation de la liste des nœuds : l’instructeur peut visualiser la liste des nœuds
dont il l’enseigne.
— Participation à un forum : L’instructeur peut envoyer et recevoir des messages à un
étudiant.
• Créateur de cours :
— Gestion de compte : chaque créateur de cours peut modifier les paramètres de son
compte.
— Consulter dashboard :
— Gestion des nœuds : le créateur de cours peut ajouter,modifier et supprimer différents
types de nœuds (super skill, skill, quiz, checkpoint et projet final).
— Gestion des paths : le créateur de cours peut créer, modifier et supprimer un path (un
path = ensemble de nœuds).
— Gestion des challenges : le créateur de cours peut ajouter, supprimer et modifier des
challenges.
— Gestion des quiz suggérés : le créateur de cours peut ajouter, supprimer et modifier
des quiz que l’étudiant peut passer s’il a besoin de gagner plus de points.
• Administrateur :
— Consulter dashboard : savoir certains détails généraux sur la plateforme (nombre d’étu-
diants, instructeur, créateur de cours, les intervalles d’âges des étudiants et le pour-
centage des étudiants inscrits dans des paths).
— Gestion de compte : chaque administrateur peut modifier les paramètres de son compte
(nom,prénom,email,mot de passe, date de naissance et numéro de téléphone).
— Ajouter utilisateur : l’administrateur peut ajouter un étudiant, un instructeur, un créa-
teur de cours ou bien un administrateur.
45
— consulter statistiques : l’administrateur peut connaître toutes les actualités de la pla-

teforme.
— l’administrateur peut affecter un étudiant ou un instructeur à un path.
— l’administrateur peut modifier les comptes utilisateurs.
2.3 Besoins non fonctionnels
Il s’agit des besoins qui caractérisent le système. Ce sont des besoins en matière de perfor-
mance, de type de matériel ou le type de conception. Ces besoins peuvent concerner les contraintes
d’implémentation (langage de programmation, type SGBD, de système d’exploitation...).
• Gestion de sécurité :
Notre application doit respecter surtout la confidentialité des données et des informations
personnelles.
• La maintenabilité :
Notre système doit être conforme à une architecture standard et claire permettant sa main-
tenance et sa réutilisation.
• Ergonomie de la plateforme : Notre application doit être adaptée, avec une interface facile
et claire.
• Performance :
Notre application doit être performante ayant un impact positif sur leurs utilisateurs.
2.4 Diagramme de cas d’utilisation global
Le diagramme de cas d’utilisation global figure 2.11 nous permet d’avoir une vision abstraite
sur le comportement de notre système. Dans ce diagramme, on présente les acteurs principaux
de l’application qui sont : l’administrateur, le createur de cours, l’instructeur et l’étudiant.
46
FIGURE 2.11 – Diagramme de cas d’utilisation général
Tous les utilisateurs doivent s’authentifier avant la réalisation de chaque cas d’utilisation.
3 Pilotage du projet avec SCRUM

Dans cette partie, nous présentons les rôles selon SCRUM (scrum master, product owner et
l’équipe de développement), le backlog du produit et enfin la structure et découpage du projet.
47
3.1 Équipe et rôles
Dans un projet SCRUM, l’équipe joue un rôle fondamental. Elle permet d’optimiser la pro-
ductivité et la flexibilité. En effet, elle doit être auto-organisée et multi-fonctionnelle.
Product owner Scrum master Equipe de développement

Ahmed BOUZID Sayed HAMDI Zeineb KHEDHER, Safé SELMI
La méthode SCRUM intègre généralement la participation de plusieurs acteurs. Dans notre

contexte, il s’agit des acteurs mentionnés dans le tableau ci-dessus .
3.2 Backlog du produit
Le backlog du produit (le carnet de commandes en français) constitue une liste ordonnée et
unique des exigences propres à un produit. Cette liste comporte des estimations (coûts) et des
valeurs (business value).
48
wUS User Story Priorités Effort
US[1] En tant qu’utilisateur, je peux m’authentifier 1 20 heures

à mon compte afin d’accéder à mon tableau
de bord.
US[2] En tant qu’utilisateur, je peux gérer mon pro- 1 6 heures

fil afin de paramétrer mes coordonnées selon
mes préférences.
US[3] En tant qu’administrateur, je peux gérer les 1 24 heures

comptes utilisateurs afin de les rendre per-
sonnalisés.
US[4] En tant que créateur de cours, je peux gérer 2 63 heures

les paths afin de construire un parcours per-
sonnalisé.
US[5] En tant que créateur de cours, je peux déspo- 2 16 heures

ser des tests afin de valider les niveaux des
étudiants pour chaque leçon.
US[6] En tant que créateur de cours, je peux dépo- 2 16 heures

ser les challenges afin de permettre aux étu-
diants de vivre une expérience profession-
nelle.
US[7] En tant qu’administrateur, je peux affecter 2 10 heures

des étudiants et des instructeurs à un niveau,
afin de leurs permettre de suivre ou valider les
cours.
US[8] En tant qu’utilisateur, je peux consulter le 2 10 heures

contenu de la plateforme afin de de prendre
une idée sur le contenu.
US[9] En tant qu’étudiant je peux psasser quiz, 3 72 heures

checkPoint, projet final afin de tester mon ni-
veau et réussir la formation.
49
US[10] En tant qu’étudiant, je peux participer aux 3 72 heures

challenges afin de vivre une expérience pro-
fessionnelle.
US[11] En tant qu’utilisateur, je peux consulter les 4 72 heures

statistiques afin de connaître tout sur la pla-
teforme selon mon rôle.
US[12] En tant qu’étudiant, je peux participer au fo- 4 63 heures

rum afin de deamnde de l’aide sur quelques
lacunes.
US[13] En tant qu’étudiant, je peux suivre mon avan- 4 5 heures

cement afin d’avoir une ideé sur mon amélio-
ration au cours du temps.
TABLE 2.2 – Backlog du produit
C’est le product owner qui se charge de sa tenue , de son évolution et de son enrichissement.
C’est également à lui de le rendre disponible pour les équipes et les parties prenantes comme
C’est montré dans le tableau 2.2 ci-dessus .
3.3 Structure et découpage du projet
Dans cette section, nous allons établir la planification de nos sprints à l’intérieur de release
qu’on a fixée précédemment. Notre release peut contenir les sprints figure 2.12 suivants :
FIGURE 2.12 – Découpage en sprint
50
Il ne s’agit pas uniquement de piocher des éléments dans le « backlog » pour constituer un
sprint. Il faut avant tout définir une planification pour déterminer de quelle façon les objectifs
fixés pourront être atteints. La sélection et l’organisation des tâches à réaliser sont donc deux
étapes clés de la méthode de travail en sprints.
FIGURE 2.13 – Structuration des sprints
Nous allons établir la planification de nos sprints figure 2.11 à l’intérieur de release qu’on a
fixée précédemment .
3.4 Planning de la réalisation du projet
Dans cette section , nous présentons figure 2.14 le plannig de la réalisation de notre projet.
FIGURE 2.14 – Structuration des sprints
51
3.5 Diagramme de Gantt du projet
Par cette figure 2.15 nous présentons une planification previsionnelle du projet .
FIGURE 2.15 – Diagramme de Gantt
Conclusion
Le backlog du produit nous a permis de partitionner les fonctionnalités en quatre sprints
selon les rôles de chaque acteur , en prévisionnant le durée de chaque user story .
52
CHAPITRE 3
SPRINT 1 - AUTHENTIFICATION ET
GESTION DES COMPTES
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5 Tests unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
53
Chapitre 3 : SPRINT 1 : Authentification et gestion des comptes
Introduction
La création de compte et sa gestion est une étape primordiale pour chaque utilisateur sou-
haitant expérimenter les fonctionnalités de la plateforme. On commence par l’identification des
acteurs et la spécification fonctionnels de l’application. Ensuite, nous abordons la phase de la
conception suivie de la phase de la réalisation et nous finissons avec les tests unitaires.
1 Backlog du sprint
Le backlog du produit présente un ensemble des fonctionnalités extraites par l’équipe scrum
à partir du backlog de produit et qui vont être réalisés pendant ce sprint. Les tâches à achever
pendant notre premier sprint sont présentées dans le tableau 3.1 suivant :
ID Fonctionnalitées User Story Story point
US[1] En tant qu’étudiant,

je peux m’identifier à 5 heures
à mon compte afin d’accéder
à mon tableau de bord
US[2] En tant qu’instructeur, je peux
m’authentifier à mon compte
afin d’accéder à mon tableau 5 heures
de bord.
US[3] En tant que créateur de cours,
je peux m’authentifier à mon 5 heures
compte afin d’accéder à
Authentification
mon tableau de bord.
US[4] En tant qu’administrateur,
compte afin d’accéder à mon
tableau de bord.
US[5] En tant qu’administrateur ,

je peux créer un compte 4 heures
utilisateur afin de gérer
54
certaines fonctionnalités .
US[6] En tant qu’administrateur, je
peux consulter et ajouter
et modifier des comptes 10 heures
étudiants,instructeurs ou
Gestion des comptes
créateurs de cours.
compte afin d’accéder à mon
tableau de bord.
US[8] En tant qu’étudiant ,

je peux gérer mon
compte à afin de 2 heures
paramétrer mes coordonnées
selon mes préférences.
US[9] En tant que créateur de ,
cours je peux gérer mon
US[10] En tant qu’instructeur,
je peux gérer mon
Gestion des paramètres
je peux gérer mon compte
afin de paramétrer mes 2 heures
coordonnées selon mes
besoins.
TABLE 3.1 – Backlog du produit sprint
55
2 Spécification des besoins

Cette phase consiste à comprendre le contexte du système. Il s’agit de déterminer les fonc-
tionnalités et les acteurs les plus pertinents et d’identifier les cas d’utilisation initiaux.
2.1 Diagramme de cas d’utilisation du sprint
Dans ce diagramme de cas d’utilisation 3.1 on décrit précisément les cas d’utilisation du
premier sprint. Tous les utilisateurs peuvent remplir un formulaire pour s’inscrire et gérer leurs
comptes personnels.
FIGURE 3.1 – Diagramme de cas d’utilisation général du sprint 1
2.2 Raffinement des diagrammes de cas d’utilisation du sprint
Dans cette partie on décrit les cas d’utilisation du premier sprint .
56
Analyse de cas d’utilisation « Gérer comptes utilisateurs »

Tout visiteur qui veut avoir son propre compte pour accéder à l’espace du cours doit remplir
un formulaire contenant les champs du nom , prénom , adresse mail , mot de passe et le numéro
de téléphone , qui seront enregistrés dans la base de données . Le visiteur peut être qu’un étudiant
les autres acteurs ne peuvent créer leurs comptes qu’avec l’intervention de l’administrateur.
FIGURE 3.2 – Analyse de cas d’utilisation « Gérer comptes utilisateurs »
Analyse du cas d’utilisation « Gérer compte étudiant »

L’administrateur peut gérer les comptes utilisateurs prenant l’exemple d’un compte étudiant pré-
senté par cette figure 3.3 .
FIGURE 3.3 – Analyse du cas d’utilisation « Gérer étudiants »
Analyse de cas d’utilisation «Modifier paramétres du compte»

Chaque utilisateur ayant un compte peut accéder à l’interface «Profil» de son compte pour chan-
ger son nom ou son prénom ,numéro de téléphone, son adresse mail , qui nécessite la réception
57
du code via le nouveau mail ou son mot de passe qui nécessite la saisi de l’ancien mot de passe.
Par cette figure 3.4 on présente le cas d’utilisation qui permet aux utilisateurs de modifier les
données de leurs comptes.
FIGURE 3.4 – Anlyse du cas d’utilisation « Modifier paramètres du compte »
2.3 Description textuelles des cas d’utilisation
Dans cette rubrique, on décrit certains cas d’utilisation par une description textuelle dé-
taillée.
Analyse du cas d’utilisation « S’authentifier »
Ce scénario 3.2 décrit l’authentification des utilisteurs pour accéder à leurs propres comptes.
Acteur Utilisateur
Pré-conditions L’utilisateur est déjà inscrit et possède des identifiants de

connexion.
Post-conditions Utilisateur authentifié.
58
Scénario nominal ➊ Le système affiche l’interface de connexion.

➋ L’utilisateur saisit son adresse mail et son mot de passe.
➌ Le système vérifie l’existence de l’utilisateur.
➍ Le système redirige l’utilisateur vers l’interface de son
compte.
scénarios alternatifs A1 : Email ou mot de passe invalide

L’enchaînement A1 démarre du point 3 du scénario nominal :
➍ Le système affiche un message d’erreur.
➎ Retour à l’étape 2 du scénario nominal.
A2 : L’utilisateur n’a pas vérifié son adresse e-mail

➍ Le système Redirige l’utilisateur vers l’interface d’activation
de compte.
➎ Le système envoie un mail à l’utilisateur contenant un code
d’activation.
➏ L’utilisateur saisit le code d’activation.
➐ Retour à l’étape 4 du scénario nominal.
TABLE 3.2 – Description textuelle du cas d’utilisation « S’authentifier »
Analyse du cas d’utilisation « Modifier adresse e-mail »

La gestion de profil est décrite par ce scénario 3.3
Acteur Utilisateur
Pré-conditions Utilisateur authentifié.
Post-conditions Adresse e-mail modifié.
59
Scénario nominal ➊ Le système affiche l’interface de modification de profil.

➋ L’utilisateur choisit de modifier son adresse e-mail.
➌ L’utilisateur saisit sa nouvelle adresse e-mail et son mot de
passe actuel.
➍ Le système vérifie les données saisis.
➎ Le système déconnecte l’utilisateur et le redirige vers
l’interface de connexion.
scénarios alternatifs A1 : L’un des champs est vide ou invalide

➎ le système affiche un message d’erreur.
➏ Retour à l’étape numéro 3 du scénario nominal.
A2 : L’utilisateur saisit une adresse e-mail utilisée par

un autre utilisateur
➎ Le système envoi un message d’erreur indiquant que cette
adresse e-mail appartient à un autre utilisateur.
TABLE 3.3 – Description textuelle du CU « Modifier profil »
Analyse du cas d’utilisation « Chercher un apprenant »

Ce scénario 3.4 décrit les étapes pour que l’administrateur peut filter un apprenant parmis les
apprenants de la liste .
Acteur Administrateur
Pré-conditions - Administrateur authentifié.

- Liste des apprenants affichée.
Post-conditions Apprenant affiché.
60
Scénario nominal ➊ L’administrateur choisit un critère de filtrage (par nom, par

prénom, par adresse email, par date de naissance ou par nu-
méro de téléphone).
➋ L’administrateur saisit les mots clés.
➌ Le système affiche la liste filtrée des apprenants.
scénarios alternatifs A1 : Aucun résultat trouvée

➌ Le système affiche « Aucun résultat à afficher ».
➍ Retour à l’étape numéro 2 du scénario nominal.
TABLE 3.4 – Description textuelle du cas d’utilisation « Chercher apprenant »
3 Conception
La conception est la deuxième phase dans un sprint. C’est une étape très importante dans
le développement du système . Elle se traduit par la modélisation des processus et des relations
entre objets. Dans cette partie, nous présentons des diagrammes de séquences détaillées, et le
diagramme de classe afin de bien expliquer le fonctionnement de notre application dans le pre-
mier sprint.
3.1 Diagrammes de séquence détaillés
Dans cette rubriques les Diagrammes de séquence détaillés décrivent les cas de création de
comptes et leurs gestions.
Diagramme de séquence détaillé « Créer compte »
Le visiteur dans ce diagramme 3.5 peut créer un compte utilisateur en accédant à l’interface
de création de compte. Il doit remplir un formulaire (nom, prénom, date de naissance, mail et un
mot de passe). Ces données vont être enregistrées dans la base de données si les données sont
correctement saisies et que le compte utilisateur n’existe pas déjà.
61
FIGURE 3.5 – Diagramme de séquence détaillé «Créer compte»
Diagramme de séquence detaillé «S’authentifier»

Par ce diagramme 3.6 on explique l’authentification des utilisateurs. En effet, ils doivent saisir
leurs adresses mails et leurs mots de passe pour accéder à la plateforme.
62
FIGURE 3.6 – Diagramme de séquence détaillé «S’authentifier»
Diagramme de séquence detaillé «Modifier email»

Cette figure 3.7 explique que chaque utilisateur peut modifier les données de son propre
compte en accédant à l’interface «Profil» et en remplissant le champ à modifier. Le changement
de mot de passe nécessite la saisie de l’ancien mot de passe.
63
FIGURE 3.7 – Diagramme de séquence détaillé «Modifier email»
Diagramme de séquence detaillé «Lister étudiants»

Ce diagramme 3.8 permet à l’administrateur de lister tous les étudiants inscrits dans la plate-
forme.
FIGURE 3.8 – Diagramme de séquence détaillé «Lister étudiants»
Diagramme de séquence detaillé «Ajouter étudiant»

Ce diagramme 3.9 permet à l’administrateur d’ajouter un compte utilisateur.
64
FIGURE 3.9 – Diagramme de séquence détaillé «Ajouter étudiant»
3.2 Diagramme de classe global du premier sprint
Le diagramme de classe global 3.10 montre les différents acteurs de la plateforme et la rela-
tion entre eux .
FIGURE 3.10 – Diagramme de classe global du sprint 1
65
4 Réalisation
On décrit dans la réalisation la démarche de développement du code backend par les sché-
mas de base de données et le frontend par les interfaces graphiques avec quelques exemples de
codes implémentés.
4.1 Schémas de la base de données
Dans cette partie, nous présentons les schémas de la base de données.
Attribut Description Type Contraintes
id identifiant de l’utilisateur ObjectID Unique
email Email de l’utilisateur String unique
password mot de passe de l’utilisateur haché élevée 8 caractères au

minimum
firstName Prénom de l’utilisateur String required
lastName Nom de l’utilisateur. String required
phoneNumber Numéro de téléphone de l’utilisateur Number required
birthDate Date de naissance de l’utilisateur. Date optionel
verified Status du compte : utilisé pour que Boolean -

contrôler si l’utilisateur a vérifié son
adresse e-mail.
roles Rôles attribués à l’utilisateur. Utilisé Array<Roles> -

pour contrôler les permissions de
chaque utilisateur.
createdAt Date de création de l’utilisateur. Date -
updatedAt Date de la dernière mise à jour d’un uti- Date -

lisateur.
TABLE 3.5 – Collection User
66
id Identifiant du rôle. ObjectID Unique
name Intitulé du rôle. String unique
resources Liste des ressources affectés à un rôle. Array<Resource> -

Le propriétaire d’un rôle a accès au res-
sources affectés a ce rôle.
createdAt Date de création du rôle Date -
updatedAt Date de la dernière mise à jour d’un rôle Date -
TABLE 3.6 – Collection rôles
id Identifiant de la ressource ObjectID Unique
name Intitulé de la ressource String unique
resources Liste des ressources affectés à un rôle. Array<Resource> -

le propriétaire d’un rôle a accès au res-
sources affectés a ce rôle
permissions Ce que l’utilisateur peut faire avec une Permission -

ressource (lecture, écriture, mise à jour
ou suppression)
createdAt Date de création de la ressource Date -
updatedAt Date de la dernière mise à jour de la res- Date -

source
TABLE 3.7 – Collection Ressources
id Identifiant du refresh token ObjectID Unique
refresh token Le refresh token est utilisé pour obtenir String required
des accès token supplémentaires
expires In La date d’expiration du refresh token Date required
67
owner L’utilisateur qui possède le refresh to- User required

ken
createdAt Date de création du refresh token Date -
updatedAt Date de la dernière mise à jour du re- Date -

fresh token
TABLE 3.8 – Collection refreshToken
4.2 Implementation
✦ Authentification avec Json Web Tokens :

« JSON Web Token (JWT) est une norme ouverte ( RFC 7519 ) qui définit un moyen
compact et autonome pour transmettre en toute sécurité des informations entre les parties
en tant qu’objets JSON.»[8]
Pour sécuriser notre système d’authentification nous avons utilisé le JWT. La sécurité
se traduit par la vérification de l’intégrité de données à l’aide d’une signature numérique.
« Les jetons signés peuvent vérifier l’intégrité des données qu’ils contiennent » [8]
Principe de base :
1. L’utilisateur se connecte avec son adresse email et son mot de passe depuis le na-
vigateur qui va envoyer une requête HTTP au serveur contenant les paramètres de
connexion.
2. Le serveur vérifie les données, génère un JWT et l’envoie vers le client HTTP.
3. Le client conserve le JWT de son côté pour pouvoir le communiquer au serveur à
chaque nouvelle requête.
4. Lorsque le serveur reçoit une nouvelle requête, il vérifie la validité du JWT pour auto-
riser ou non l’accès à la ressource demandée.
68
FIGURE 3.11 – Authentification avec JWT
4.3 Interfaces de la plateforme
Dans cette section , nous présentons les interfaces de la plateforme commençant par l’inter-
face d’inscription 3.12
FIGURE 3.12 – Inscription
69
Ces interfaces 3.13 et 3.14 où l’administrateur peut aussi faire inscrire un étudiant , ajouter
un instructeur , un créateur de cours et un administrateur en saisissant leurs noms , prénoms ,
adresses mail et mots de passe.
FIGURE 3.13 – Liste des étudiants
Il est nécessaire pour chaque visiteur d’entrer son nom , prénom, son numéro de téléphone,
son adresse mail et son mot de passe pour pouvoir se connecter chaque fois avec son propre
compte , toutes ces informations vont être vérifiées avant de les sauvegarder. Enfin ces données
vont être enregistrées dans la base de données.
FIGURE 3.14 – Modal d’ajout
70
Après que l’utilisateur se connecte en saisissant l’email et le mot de passe d’inscription dans
le formulaire de connexion 3.15 ,il pour avoir l’accès à la plateforme avec son propre compte.
FIGURE 3.15 – Connexion
Tout utilisateur inscrit peut gérer son propre compte dans cette interface 3.16, c’est à dire
modifier les données de son compte (sa photo de profil , son nom ,son prénom , son adresse
mail, son mot de passe et son numéro de téléphone ).
FIGURE 3.16 – Gérer compte
71
5 Tests unitaires
Dans cette rubrique, on utilise les tests unitaire qui sont un moyen de vérifier qu’un extrait de
code fonctionne correctement. C’est l’une des procédures mises en œuvre dans le cadre d’une
méthodologie de travail agile.
On a effectué les tests unitaire par l’application Postman qui sert à exécuter des requêtes
HTTP directement depuis une interface graphique. On peut tout simplement choisir l’URL, la
méthode HTTP (le plus souvent GET, POST, PUT, PATCH et DELETE), les headers, les query pa-
rams et dans certains cas le body de la requête.
Test unitaires du cas d’utilisation « Créer un compte »
Nous présentons ci-dessous le code source et le résultat de deux cas de test :
1. Toutes les données sont correctement saisies.

2. L’utilisateur existe déjà.
FIGURE 3.17 – Code souce du test unitaire du cas d’utilisation « Créer compte »
72
FIGURE 3.18 – Resultat du premier test
FIGURE 3.19 – Resultat du deuxieme test
73
Test unitaires du cas d’utilisation « S’authentifier »

Nous présentons le code source et le résultat de deux cas de test :
1. Toutes les données sont valides.

2. Mot de passe invalide.
FIGURE 3.20 – Code souce du test unitaire du cas d’utilisation «S’authentifier »
FIGURE 3.21 – Resultat du premier test
74
FIGURE 3.22 – Resultat du deuxieme test
Conclusion
Dans ce chapitre, on s’est focalisé sur l’authentification des utilisateurs. L’apprenant peut
créer son propre compte et se connecter. L’administrateur peut aussi lui créer un compte et pour
les deux cas un code de confirmation lui sera envoyé par mail. Quant aux administrateurs, les ins-
tructeurs et les créateurs de cours, seule l’administrateur peut leur créer leurs comptes. Chaque
utilisateur connecté peut gérer son propre compte.
75
CHAPITRE 4
SPRINT 2 - GESTION DU CONTENU DE LA

PLATEFORME
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5 Tests unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
76
Chapitre 4 : SPRINT 2 : Gestion du contenu de la plateforme
Introduction
La gestion du contenu de la plateforme est la partie où le créateur de cours va intervenir pour
implémenter le contenu qui va être servi aux autres acteurs. Nous commençons d’abord par
l’identification des acteurs et la spécification fonctionnels de l’application. Ensuite nous abor-
dons la phase de la conception suivie de la phase de la réalisation et nous finissons avec les tests
unitaires.
1 Backlog du sprint
Le backlog du produit présente un ensemble des fonctionnalités extraites par l’équipe scrum
à partir du backlog de produit et qui vont être réalisés pendant ce sprint. Les tâches à achever
pendant notre deuxième sprint sont présentées dans le tableau 4.1 suivant :
US[1] En tant que créateur de 7 heures

cours, je peux gérer les su-
per skills afin de construire
le cours adéquat au path.
cours, je peux gérer les
skills afin de créer la leçon
adéquate au cours.
US[3] Gestion des noeuds En tant que créateur de 7 heures
cours, je peux gérer les quiz
afin de tester la compréhen-
sion des leçons.
checkpoints afin de tester la
compréhension des cours.
77

projets finaux afin de tester
la compréhension de tout le
path.
US[7] Gestion des paths En tant que créateur de 7 heures

paths afin de créer un
système de formation.
US[8] Gestion des challenges En tant que créateur de 7heures

cours, je peux gérer les chal-
lenges afin d’encourager
les étudiants à vivre une
expérience professionnelle.
TABLE 4.1 – Backlog du produit sprint

tionnalités et les acteurs les plus pertinents et d’identifier les cas d’utilisation de ce sprint .
2.1 Diagramme de cas d’utilisation de sprint
Par ce diagramme de cas d’utilisation 4.1 , on décrit précisement les cas d’utilisation du deuxième
sprint. Le créateur de cours peut gérer tous les types des nœuds, les paths ainsi que déposer des
tests et des challenges.
78
FIGURE 4.1 – Diagramme de cas d’utilisation du sprint 2
2.2 Raffinement des diagrammes des cas d’utilisation
Pour que les cas d’utilisation soient plus compréhensibles, nous avons mis en place l’analyse
de chaque cas présent.
Raffinement du cas d’utilisation «Gérer nœuds»
Ce cas d’utilisation 4.2 permet au créateur de cours d’ajouter, supprimer et modifier un noeud.
FIGURE 4.2 – Raffinement de cas d’utilisation «Gérer nœuds»
Raffinement du cas d’utilisation «Gérer skill»

Cette fiqure 4.3 , présente la gestion du nœud «skill».
79
FIGURE 4.3 – Raffinement de cas d’utilisation «Gérer skill»
Raffinement du cas d’utilisation «Gérer path»

Cette figure 4.4 décrit la création d’un parcours par le créateur de cours avec les nœuds com-
posant le graphe, le parcours va être le chemin que l’étudiant doit suivre pour compléter sa for-
mation.
Raffinement du cas d’utilisation «Gérer path»
FIGURE 4.4 – Raffinement de cas d’utilisation «Gérer path»
2.3 Descriptions textuelles des cas d’utilisation
Les descriptions textuelles décrit les détails de chaque cas d’utilisation .

Analyse de cas d’utilisation «Ajouter path»
80
Le créateur de cours peut ajouter plusieurs paths. Ce scénario 4.2 révèle les détails de l’ajout.
Acteur Créateur de cours
Pré-conditions Minimum un nœud ajouté.
Post-conditions Parcours ajouté.
Scénario nominal ➊ Le créateur clique sur le bouton «Mode création path» pour
entrer en mode suppression.
➋ Le créateur de cours sélectionne les nœuds du parcours.
➌ Le créateur de cours clique sur le bouton «Sauvegarder».
➍ Le système affiche le formulaire d’ajout.
➎ Le créateur de cours remplit le formulaire.
➏ Le système vérifie les données saisies.
➐ Le système ajoute le parcours.
scénarios alternatifs A1 : champs vide

➏ Le système affiche un message d’erreur indiquant que l’un
des champs est vide.
➐ Retour à l’étape numéro 5 du scénario nominal.
TABLE 4.2 – Description textuelle du cas d’utilisation « Ajouter parcours »
Analyse de cas d’utilisation «Ajouter skill »

Le créateur de cours a le droit d’ajouter un skill en remplissant un formulaire , demandant un
label, une description et un fichier de type «md». Ce dernier contenant les détails de ce skill que
l’étudiant peut consulter et étudier.
Pré-conditions Créateur de cours authentifié.
Post-conditions Skill créé.
81
Scénario nominal ➊ Le créateur de cours glisse un nœud de type skill dans la

zone d’édition.
➋ Le système affiche le formulaire de création.
➌ Le créateur de cours remplit le formulaire et dépose un
fichier markdown (.md).
➍ Le système vérifie les informations saisis.
➎ Le système calcule le score et ajoute le nouveau skill.
scénarios alternatifs A1 : L’un des champs est vide

➎ Le système affiche un message d’erreur.
A2 : Le type du fichier est invalide

➎ Le système envoi un message d’erreur indiquant que le type
du fichier est invalide.
TABLE 4.3 – Description textuelle du cas d’utilisation « Ajouter skill »
Analyse de cas d’utilisation «Modifier skill »

Le double cliques sur le nœud permet l’affichage d’un formulaire rempli pour le modifier. Ce
scénario 4.4 explique la démarche à suivre.
Pré-conditions Lister les skills.
Post-conditions Skill modifié
82
Scénario nominal ➊ Le créateur double-clique sur un nœud de type skill.

➋ Le Le système affiche le formulaire rempli.
➌ Le créateur de cours remplit le formulaire avec les nouvelles
informations.
➍ Le système vérifie les informations saisies.
➎ Le système modifie les informations du skill.
scénarios alternatifs A1 : L’un des champs est vide

L’enchaînement A1 démarre du point 4 du scénario nominal
➎ Le système affiche un message d’erreur
➏ Retour à l’étape numéro 3 du scénario nominal
A2 : Le type du fichier est invalide

L’enchaînement A1 démarre du point 4 du scénario nominal
➎ Le système envoi un message d’erreur indiquant que le type
du fichier est invalide
➏ Retour à l’étape numéro 3 du scénario nominal
TABLE 4.4 – Description textuelle du cas d’utilisation « Modifier skill »
Analyse de cas d’utilisation «Supprimer skill »

Le créateur de cours doit cliquer sur le bouton « Mode suppression» pour pouvoir supprimer un
nœud du path. Une description textuelle ci-dessous 4.5 éclaircit les étapes de la suppression.
Pré-conditions Lister les skills.
Post-conditions Skill supprimé.
83
Scénario nominal ➊ Le créateur clique sur le bouton «Mode suppression» pour

entrer en mode suppression.
➋ Le créateur de cours sélectionne les skills à supprimer.
➌ Le créateur de cours clique sur le bouton «supprimer» du
clavier.
➍ Le système affiche une boîte d’alerte indiquant que le nœud
va être supprimé de tous les parcours.
➎ Le créateur de cours confirme la suppression.
➏ Le système supprime le skill.
scénarios alternatifs A1 : Le créateur de cours ne confirme pas la suppression

➎ Le créateur de cours ne confirme pas la suppression.
TABLE 4.5 – Description textuelle du cas d’utilisation « Supprimer skill »
Analyse du cas d’utilisation « Chercher paths »

Cette description textuelle 4.6 permet d’expliquer le filtrage des paths parmis autres .
[HTML]FFCE93Acteur Créateur de cours
Pré-conditions Lister les paths
Post-conditions Paths filtrés
Scénario nominal ➊ Le créateur de cours choisi un path.

➋ Le système affiche le contenu du path sélectionné.
Scénario alternatifs Néant
TABLE 4.6 – Description textuelle du cas d’utilisation « Chercher path »
84
3 Conception
Dans ce qui suit, nous présentons les diagrammes de séquences détaillés de conception des
cas d’utilisation analysés précédemment.
3.1 Diagrammes de cas d’utilisations détaillés
Diagramme de séquence détaillé «Créer path»

Ce diagramme 4.5 décrit l’ajout d’un path par le créateur de cours en détaillant les données à
saisir.
FIGURE 4.5 – Diagramme de séquence détaillé «Créer path»
Diagramme de séquence detaillé «Lister quiz»

Cette figure 4.6 affiche les étapes pour afficher la liste des quiz .
85
FIGURE 4.6 – Diagramme de séquence détaillé "Lister quiz»
Diagramme de séquence detaillé «Ajouter quiz»

Ce diagramme 4.7 permet l’ajout d’un quiz par le créateur de cours pour créer un path bien dé-
terminé.
86
FIGURE 4.7 – Diagramme de séquence détaillé «Ajouter quiz»
Diagramme de séquence detaillé «Modifier quiz»

Dans ce diagramme de séquence 4.8 la modification d’un quiz par le créateur de cours dans l’in-
terface «UIpaths» nécessite l’intervention du controller «modifierQuizController» et l’entité «En-
tite quiz».
87
FIGURE 4.8 – Diagramme de séquence détaillé «Modifier quiz»
Diagramme de séquence detaillé «Supprimer quiz»

Par ce diagramme 4.9 le créateur de cours peut aussi supprimer le quiz qu’il a créé.
88
FIGURE 4.9 – Diagramme de séquence détaillé «Supprimer quiz»
3.2 Diagramme de classe global du sprint
Le diagramme de classe global 4.10 modélise généralement les attributs, les opérations et les
relations entre les objets utils dans ce sprint.
89
FIGURE 4.10 – Diagramme de classe global sprint 2
4 Réalisation
mas de base de données et le frontend par les interfaces avec quelques exemples de codes im-
plémentés.
90
id Identifiant du super skill ObjectID Unique
label Intitulé du super skill String unique
description Description du super skill String Required
score Score obtenu lorsque l’apprenant passe String Default : 0

le super skill
createdAt Date de création du super skill Date -
updatedAt Date de la dernière mise à jour d’un su- Date -

per skill
TABLE 4.7 – Collection Super skill
id Identifiant du skill ObjectID Unique
label Intitulé du skill String Required
contentLink Lien vers un fichier markdown sur le String -

cloud

le super skill
createdAt Date de création du skill Date -
updatedAt Date de la dernière mise à jour du skill Date -
TABLE 4.8 – Collection skill
id Identifiant du quiz ObjectID Unique
label Intitulé du quiz String unique
question La question posée dans le quiz String -
responses Liste des réponses correctes Array<Response> -
91

le quiz
createdAt Date de création de la ressource Date -
updatedAt Date de la dernière mise à jour de la res- Date -

source
TABLE 4.9 – Collection quiz
id Identifiant du checkpoint ObjectID Unique
label Intitulé du checkpoint String Required

cloud
score Score maximal obtenu par l’apprenant String Default : 75

dans un checkpoint
createdAt Date de création du skill Date -
updatedAt Date de la dernière mise à jour du skill Date -
TABLE 4.10 – Collection checkpoint
id Identifiant du projet final ObjectID Unique
label Intitulé du projet final String Required

cloud
score Score maximal obtenu par l’apprenant String Default : 100

dans un projet final
createdAt Date de création du projet final Date -
updatedAt Date de la dernière mise à jour du projet Date -

final
92
TABLE 4.11 – Collection projects
id Identifiant du nœud ObjectID Unique
x Position du nœud sur l’axe horizontal Number Unique
y Position du nœud sur l’axe vertical Number Unique
virtualName Type du nœud String Required
data L’id du document auquel le nœud fait Checkpoint, Required

référence Project, Quiz,
Skill ou Super-
Skill
createdAt Date de création du noeud Date -
updatedAt Date de la dernière mise à jour du Date -

noeud
TABLE 4.12 – Collection Node
id Identifiant du path ObjectID Unique
label Intitulé du path String Required
description Description du path String Required
nodes La liste des noeuds qui construit le path Array<Node> -
createdAt Date de création du path Date -
updatedAt Date de la dernière mise à jour du path Date -
TABLE 4.13 – Collection path
id Identifiant du challenge ObjectID Unique
93
label Intitulé du challenge String Required
description Description du challenge String Required

cloud
RequiredScore Score requis pour participer au chal- String -

lenge
score Score maximal obtenu par l’apprenant String -

dans un challenge
createdAt Date de création du challenge Date -
updatedAt Date de la dernière mise à jour du chal- Date -

lenge
TABLE 4.14 – Collection challenge
id Identifiant du edge ObjectID Unique
source L’id du nœud source String Required
description Description du challenge String Required
target L’id du noeud destination String required
createdAt Date de création du edge Date -
updatedAt Date de la dernière mise à jour du edge Date -
TABLE 4.15 – Collection edge
4.2 Implementation
Ces figures 4.11 et 4.12 présentent le code de la partie front-end qui concerne l’initialisation
des super skills et des skills.
94
FIGURE 4.11 – Lister les super skills FIGURE 4.12 – Lister les skills
Dans la figure 4.13 , nous présentons le code de la partie back-end la création des différents
nœuds : super skills, skills , quizzes, checkpoints et projects finaux . De plus la création des edges
(les liens qui relient les nœuds) et enfin les paths.
FIGURE 4.13 – Gestion des nœuds et des paths
95
4.3 Interfaces
L’interface du graphe est créée par React Flow . React Flow est une bibliothèque pour créer des
applications basées sur des nœuds. Il peut s’agir de simples diagrammes statiques ou d’éditeurs
complexes. Vous pouvez implémenter des types de nœuds et des types de bords personnalisés
et il est livré avec des composants comme une mini-carte et des contrôles de graphique.
Quelques avantages d’utilisation de ce concept :
— Facile à utiliser : comportement de zoom, panoramique fluide, sélections uniques et mul-

tiples de nœuds (nodes) et des d’arêtes (edges).
— Personnalisable : le types des nœuds est personnalisable.
— Rendu rapide : Seuls les nœuds qui ont été changés sont rendus à nouveau et seuls ceux
qui sont dans la fenêtre sont affichés.
— Composants du plugin : arrière-plan, minicarte et commandes.
— Fiable : écrit en typescript et testé avec du cypress.
Le créateur de cours peut créer les nœuds dans le flow avec un Drag and Drop. Flow : L’espace où
les nœuds sont créés après le drag and drop.
Drag and Drop : L’action de glisser un noeud et de le mettre dans le flow.
un nœud peut être :
— Super-skill : sa création nécessite un label et une description qui décrit ce nœud. Ce nœud
peut être défini comme un cours à étudier.
— Skill : sa création demande un label, un fichier de type «md» qui comprend le contenu de
ce nœud. Un skill peut être défini comme une leçon dans le supre-skill.
— Quiz : sa création exige un label, une question et les réponses pour l’étudiant à choisi. Le
quiz peut être de type vrai/faux, question à choix multiples (QCM) ou bien question à choix
unique (QCU).
— Checkpoint : sa création demande un label, une description et un fichier de type "md». Un
checkpoint est un test pour évaluer la compréhension de l’apprenant du cours pour passer
au cours suivant.
— Projet final : sa création nécessite un label, une description et un fichier de type «md». Un
projet final récapitule tout ce que l’apprenant a appris dans un path pour avoir finalement
son certificat.
96
La suppression d’un nœud necéssite le clique sur le bouton «Mode supression». En sélection-
nant le nœud à supprimer et puis sur le bouton «effacer en reculant» du clavier.
FIGURE 4.14 – Ajouter nœud
Les données de création du nœud peuvent être modifiés en double-cliquant sur ce nœud
pour afficher un formulaire 4.15 de modification.
FIGURE 4.15 – Modifier nœud
Interface de la suppression d’un noeud :
97
FIGURE 4.16 – Supprimer nœud
Le créateur de cours peut créer un path dans cette interface 4.17 avec les nœuds qui ont été
créés dans le graphe. Ce path va être le formation que l’étudiant va choisir comme formation. Un
path peut être défini comme une formation personnalisée selon la demande de l’apprenant.
FIGURE 4.17 – Interface créer path
Il peut aussi consulter la liste des paths qu’il a contruit avec un bouton de dropdown.
98
FIGURE 4.18 – Liste des paths
Un des rôle principal du créateur de cours est de créer les challenges pour l’apprenant. Un
challenge peut être un programme à developper pour un des partenaire de la stratup Opus Lab.
Une entreprise ou un client d’un autre domaine qui a besoin de ce projet ou une activité créée par
le créateur de cours ça peut être payant pour que l’étudiant vive une expérience professionnelle.
Cette interface 4.19 permet la création de challenge qui exige un label, une description et un
fichier de type «md» contenant les détails de l’activité à réaliser.
FIGURE 4.19 – Liste des challenges
99
5 Tests unitaires
Dans ce sprint nous allons présenter les test unitaires des cas d’utilisation «Ajouter challenge»
et «Modifier super skill»
Test unitaire du cas d’utilisation « Ajouter challenge »
Pour ajouter un challenge, d’abord il faut faire l’upload d’un fichier avec l’extension .md en
utilisation le service de stockage de données en ligne « Amazon S3 ».
— Test de l’upload d’un fichier .md
FIGURE 4.20 – Test de l’upload d’un fichier .md
FIGURE 4.21 – Résultat des tests
— Test d’ajout d’un challenge
100
FIGURE 4.22 – Test d’ajout d’un challenge
FIGURE 4.23 – Résultat du test 1
101
FIGURE 4.24 – Résultat du test 2
Test unitaire du cas d’utilisation « Modifier super skill »

La figure ci-dessous présente le test de modification de la description d’un super skill.
FIGURE 4.25 – Test unitaire du cas d’utilisation « Modifier super skill »
Ci-dessous le résultat du test lorsque le champs de la description est vide.
102
FIGURE 4.26 – Résultat du test
Conclusion
Dans ce chapitre, nous avons élaboré les cas d’utilisation concernant le créateur de cours gé-
rant le contenu de la plateforme. Le créateur de cours est chargé de créer les nœuds nécessaires
pour construire des formations adéquates à la demande de l’étudiant. Le challenge sera une op-
portunité pour les étudiants pour découvrir le monde professionnel avec tous ses critères (date
limite pour envoyer le travail, la description détaillée du projet, payant, le travail d’équipe,etc).
103
CHAPITRE 5
SPRINT 3 - EXPLOITATION DU CONTENU

DE LA PLATEFORME
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
5 Tests unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
104
Chapitre 5 : SPRINT 3 : Exploitation du contenu de la plateforme
Introduction
Dans le chapitre précédent nous avons élaboré comment le créateur de cours peut gérer le
contenu de la plateforme avec les nœuds qu’il crée . Dans ce chapitre, nous analysons les détails
de l’exploitation de ce contenu qui constitue le troisième sprint. Nous commençons par l’ana-
lyse et la spécification des besoins, puis l’analyse des cas d’utilisation du sprint 3, la conception
ensuite la réalisation et le test.
1 Backlog du sprint
Le backlog du produit 5.1 présente un ensemble des fonctionnalités extraites par l’équipe
scrum à partir du backlog de produit et qui vont être réalisés pendant ce sprint. Les tâches à
achever pendant notre troisième sprint.

je peux affecter un
étudiant à un path 4 heures
afin de lui permettre de
Afféctation à un path
suivre les cours.
je peux affecter un
instructeur à un path 4 heures
afin de lui permettre d’en-
seigner un path.
US[3] En tant que visiteur, je peux 5 heures

consulter la liste des paths
afin de choisir le parcours
qui me convient.
105
US[4] Consulter contenu En tant que visiteur, je peux 3 heures

consulter la liste des super
skills et skills d’un path afin
de s’informer du contenu du
parcours.
US[5] En tant qu’apprenant,

je peux passer un quiz, afin 10 heures
de passer au skill suivant.
US[6] En tant qu’apprenant,

je peux passer un check- 7 heures
point afin de
passer au superskill suivant.
Passer quiz,checkpoint
US[7] En tant qu’apprenan, 7 heures

et projet final je peux réaliser un projet fi-
nal afin d’obtenir un certifi-
cat de fin de path.
US[8] Participer challenges En tant qu’apprenant, je 7 heures

peux participer à un chal-
lenge, afin de gagner de
l’expérience profession-
nelle.
TABLE 5.1 – Backlog du sprint

106
2.1 Diagramme de cas d’utilisation du sprint
En élaborant ce diagramme de cas d’utilisation 5.1 on décrit précisément les cas d’utilisation
du troisième sprint. Le créateur de cours peut gérer tous les types de nœuds, les paths ainsi que
déposer des tests et des challenges.
FIGURE 5.1 – Diagramme de cas d’utilisation du sprint
2.2 Raffinement des diagrammes de cas d’utilisation
Pour que les cas d’utilisation soient plus compréhensibles, nous avons mis en place l’analyse
de chaque cas présent.
Raffinement du cas d’utilisation «S’inscrire à un path»
Ce cas 5.2 permet à l’apprenant de s’inscrire à un path après avoir consulté la liste des paths.
107
FIGURE 5.2 – Raffinement de cas d’utilisation «S’inscrire à un path»
Raffinement du cas d’utilisation «Corriger travaux des apprenants»

Ce cas 5.3 permet à l’instructeur de télécharger et corriger les travaux mis par les étudiants en
accédant à la liste des apprenants.
FIGURE 5.3 – Raffinement de cas d’utilisation «Corriger travaux des étudiants»
Raffinement du cas d’utilisation «Suivre path»

Ce cas 5.4 permet à l’étudiant d’exploiter le contenu du path, les nœuds qu’il contient un par
un.
108
FIGURE 5.4 – Raffinement de cas d’utilisation «Suivre path»
2.3 Descriptions textuelles des cas d’utilisation
Analyse du cas d’utilisation «s’inscrire à un path»

Selon la description de chaque path l’apprenant peut choisir celui qui lui convient . Ce scénario
5.2 détaille l’inscription au path choisi par l’apprenant.
Acteur Apprenant
Pré-conditions - Apprenant a consulté le contenu du parcours choisi.

- S’authentifier.
Post-conditions - Apprenant inscrit à un parcours.

- code du path envoyé par mail
Scénario nominal ➊ L’apprenant clique sur le bouton «Commencer la forma-

tion».
➋ Le système affiche le formulaire.
➌ L’apprenant saisit le code voucher et valide.
➍ Le système vérifie le code saisit.
➎ Le redirige l’apprenant à l’interface «Mes parcour».
109
scénarios alternatifs A1 : Code voucher invalide

TABLE 5.2 – Description textuelle du cas d’utilisation « S’inscrire à un parcours »
Analyse de cas d’utilisation «Consulter skill»

Ce scénario 5.3 explique le passage d’un nœud à un autre dans un path tout en collectant un
score après chaque nœud réussi.
Acteur Apprenant
Pré-conditions -Apprenant authentifié.

-Étudiant inscrit dans un path.
Post-conditions Apprenant consulte un skill.
Scénario nominal ➊ L’apprenant clique sur le bouton «Commencez votre path»

➋ Le système affiche le path.
➌ L’apprenant clique sur le bouton «suivant».
➍ Le système met à jour le score du path ainsi le score global.
Scénario alternatifs Néant.
TABLE 5.3 – Description textuelle du Cas d’utilisation «Consulter skill»
Analyse du cas d’utilisation «Affecter étudiant»

La liste des apprenants que l’administrateur peut accéder lui permet d’affecter les apprenants
à un path ou plusieurs. Par ce scénario 5.4 l’administrateur peut ajouter un apprenant à un path.
Pré-conditions -Lister les apprenants.

-Parcours créé.
Post-conditions Code voucher envoyé.
110
Scénario nominal ➊ L’administrateur choisit un apprenant et clique sur le bou-

ton «Affecter un parcours».
➋ Le système affiche la liste des parcours.
➌ L’administrateur sélectionne un parcours et valide.
➍ Le système vérifie les données.
➎ Le système envoie un mail sur l’adresse e-mail de l’appre-
nant contenant un code voucher.
➏ Le système affiche un message de succés.
scénarios alternatifs A1 : L’apprenant est déjà inscrit au parcours

TABLE 5.4 – Description textuelle du cas d’utilisation « Affecter apprenant »
Analyse de cas d’utilisation «Corriger travaux des étudiants »

On va prendre l’exemple du projet final décrit par ce scénario 5.5 pour détailler la correction
du travail déposé par l’apprenant, par l’intructeur.
Acteur Instructeur
Pré-conditions - L’apprenant dépose un projet final.

- Lister apprenant inscrit dans le même parcours que l’instruc-
teur.
Post-conditions projet final noté.
111
Scénario nominal ➊ L’instructeur choisit un apprenant et clique sur le bouton

«Noter les travaux».
➋ Le système affiche les travaux non corrigés.
➌ L’instructeur choisit un projet final et télécharge le travail de
l’étudiant.
➍ L’instructeur clique sur le bouton «Corriger».
➎ Le système affiche un formulaire.
➏ L’instructeur saisit la note et les remarques et valide.
➏ Le système vérifie les données.
➐ Le système met à jour le score de l’étudiant.
scénarios alternatifs A1 : Le champs du score est vide

➑ Le système affiche un message d’erreur.
➒ Retour à l’étape numéro 6 du scénario nominal.
TABLE 5.5 – Description textuelle du cas d’utilisation «Corriger travaux des étudiants »
3 Conception
Dans cette partie, on élabore la conception du sprint par les diagrammes de séquence dé-
taillés pour modéliser le déroulement des procédures accomplies dans ce sprint.
3.1 Diagrammes de séquences détaillés
Diagramme de séquence détaillé «Passer nœud suivant»

Par ce diagramme 5.5 on présente les étapes de passage d’un nœud à un autre pour un ap-
prenant jusqu’à la fin du path.
112
FIGURE 5.5 – Diagramme de séquence détaillé «Passer nœud suivant»
Diagramme de séquence detaillé «Passer quiz»

Ce diagramme 5.6 décrit les étapes pour passer un quiz.
113
FIGURE 5.6 – Diagramme de séquence détaillé «Passer quiz»
Diagramme de séquence detaillé «Passer special quiz»

Ce diagramme 5.7 décrit les étapes pour passer un special quiz.
FIGURE 5.7 – Diagramme de séquence détaillé «Passer special quiz»
Diagramme de séquence detaillé «Lister special quizzes»
Ce diagramme 5.8 décrit l’accès à la liste des special quizzes .
114
FIGURE 5.8 – Diagramme de séquence détaillé «Passer special quizzes»
Diagramme de séquence détaillé «Affecter étudiant»
Par ce diagramme ?? l’administrateur affecte un apprenant à un path .
FIGURE 5.9 – Diagramme de séquence détaillé «Affecter étudiant»
3.2 Diagramme de classe global du sprint
Le diagramme de classe global 5.10 modélise généralement les attributs, les opérations et les
relations entre les objets utiles dans ce sprint.
115
FIGURE 5.10 – Diagramme de classe global du sprint
4 Réalisation
plémentés.
id identifiant du voucher ObjectID Unique
116
code le code du voucher String unique + Required
path le path pour le quel est crée ce voucher Path Required
student l’apprenant pour le quel est crée ce vou- User Required

cher
expiresIn Date d’expiration de voucher Date Required
createdAt Date de création du document Date -
updatedAt Date de la dernière mise à jour du docu- Date -

ment
TABLE 5.6 – Collection Voucher
id identifiant de l’affectation ObjectID Unique
instructor L’instructeur affecté User Required
path Le path affecté à l’instructeur Path Required

ment
TABLE 5.7 – Collection Affect instructor
id identifiant du document ObjectID Unique
student l’apprenant affecté User Required
path le path affecté à l’apprenant Path Required
progressPointer le dernier noeud consulté par l’appre- Node Required

nant : Indique la progression de l’utili-
sateur dans le path
score Le score que l’apprenant a collecté en Number Default : 0

progressant dans le path
117

ment
TABLE 5.8 – Collection Enrolled path
student L’apprenant qui a completé le noeud User Required
enrolledPath le path affecté à l’apprenant et qui EnrolledPath Required

contient le noeud
node le noeud completé par l’apprenant Node Required
data le travail de l’apprenant dans ce noeud Object(quizResponse : Required

Boolean[], content-
Link : String, instruc-
torFeedbackDocLink :
String)
isRated le noeud est corrigé par l’instructeur ou Node Default : false

non

ment
TABLE 5.9 – Collection Node status
4.2 Implementation
On a utilisé Amazon Simple Storage Service (Amazon S3) pour le sauvegarde des fichiers de
type MD ,Aussi l’intégration de python a servi pour le création d’une commande CLI pour que
l’apprenant dépose son travail en utilisant ARGPARSE : un module qui facilite l’écriture d’inter-
faces de ligne de commande conviviales. Le programme définit les arguments dont il a besoin, et
argparse déterminera comment les analyser à partir de sys.argv. Le module argparse génère au-
118
tomatiquement des messages d’aide et d’utilisation et émet des erreurs lorsque les utilisateurs
donnent au programme des arguments non valides.
FIGURE 5.11 – Suivre path
4.3 Interfaces
Dans cette interface 5.12 l’apprenant peut consulter la liste des paths, il peut choisir le path
qui lui convient. Un code voucher de ce path lui sera envoyé par mail pour pouvoir consulter son
contenu.
119
FIGURE 5.12 – S’inscrire à un path
L’apprenant peut consulter les superskills que contient chaque path dans cette interface 5.13
pour avoir une idée sur le contenu de chacun .
FIGURE 5.13 – Lister superskills
L’apprenant peut consulter la liste des paths 5.13 dont il est inscrit et voir son avancement
dans ce path.
120
FIGURE 5.14 – Parcours de l’étudiant
L’apprenant peut consulter la description de chaque Super-skill 5.15 par cette interface.
FIGURE 5.15 – Interface superskill
Le skill 5.16 est tout une leçon que l’apprenant doit suivre pour avoir 25 points ajoutés à son
score, qui peut contenir du texte, des images et des vidéos.
121
FIGURE 5.16 – Interface skill
Pour passer à un autre skill, l’apprenant doit être testé par un quiz 5.17. Si ce test est validé
alors 50 points sont ajoutés à son score.
FIGURE 5.17 – Interface Quiz
Pour passer à un autre super skill, un checkpoint doit être validé et donc l’apprenant peut
avoir 75 points maximum ajoutés à son score. Mais pour avoir accès au checkpoint, il faut avoir
les points nécessaires. Sinon, l’apprenant doit passer d’autres quiz pour avoir le score demandé
pour passer le checkpoint et accéder à cette interface 5.18 .
122
FIGURE 5.18 – Interface Checkpoint
Dans cette interface 5.19 , l’étudiant peut avoir une liste de quiz qui peut réaliser pour ajouter
des points à son score.
FIGURE 5.19 – Interface des quiz suggérés
A la fin du path dans cette page 5.20 l’apprenant est demandé à réaliser un projet final. Pour
tester tout ce qu’il a appris dans cette formation, afin d’avoir 100 points maximum ajoutés à son
score, son certificat et ainsi clôturer le path.
Remarque :
L’étudiant doit envoyer les travaux des checkpoints et des projets finaux avec cette ligne de com-
123
mande :
«Opus push -p idpath -m idCheckpoint» s’il s’agit d’un checkpoint.
«Opus push -p idpath -m idProjetFinal» s’il s’agit d’un projet final.
FIGURE 5.20 – Interface projet final
L’instructeur peut consulter la liste des apprenants inscrits dans le path dans cette page 5.21
dont il est affecté.
FIGURE 5.21 – Interface liste des étudiants
Dans cette interface 5.22 l’instructeur peut recevoir les checkpoints et les projets finaux de
chaque étudiant inscrit dans le path dont il est affecté. Il est demandé à corriger ces travaux,
124
écrire un feed-back et envoyer la correction dans un fichier de type «md».
FIGURE 5.22 – Interface correction travaux
5 Tests unitaires
Test unitaires du cas d’utilisation « Affecter instructeur »
FIGURE 5.23 – Test unitaire du cas d’utilisation « Affecter instructeur »
Pour ce test nous présentons deux scénarios :
— Cas ou les données sont valides.
125
FIGURE 5.24 – résultat du premier cas de test
— Cas ou l’instructeur n’existe pas.
FIGURE 5.25 – résultat du deuxième cas de test
Test unitaire du cas d’utilisation « Consulter skill »
126
FIGURE 5.26 – Test unitaire du cas d’utilisation « Consulter skill »
Nous présentons ci-dessous deux cas de test :
— Cas ou les données sont valides.
FIGURE 5.27 – Résultat du premier cas de test
— Cas où l’apprenant n’a pas valider les nœuds précédents.
127
FIGURE 5.28 – Résultat du deuxième cas de test
Conclusion
Dans ce sprint, l’apprenant et l’instructeur sont les acteurs principaux. L’apprenant exploite le
parcours qu’il a choisi, s’évalue pour tout ce qu’il a appris et réalise de vrais projets. L’instructeur
est indispensable, il a un rôle très important dans l’avancement de l’apprenant. Il est demandé
pour surveiller son parcours de l’aider à corriger ses travaux pour achever le dernier point de la
formation.
128
CHAPITRE 6
SPRINT 4 - FORUM ET STATISTIQUES
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
129
Chapitre 6 : SPRINT 4 : Statistiques et Forum
Introduction
Dans le chapitre précédent nous avons élaboré comment l’apprenantpeut suivre des paths
et l’instructeur peut lui corriger son travail . Dans ce chapitre nous élaborons notre système de
notification , le forum de communication et les statistiques que les utilisateurs peuvent consulter
pour connaître les détails de tout ce qui se déroule dans la plateforme selon leurs rôles.
1 Backlog du sprint
Le backlog du produit présente un ensemble des fonctionnalités extraites par l’équipe scrum.
A partir du backlog de produit et qui vont être réalisés pendant ce sprint. Les tâches à achever
pendant notre quatrième sprint sont présentées dans le tableau suivant 6.1 .
US[1] En tant qu’instructeur, je peux 5 heures

consulter des statistiques sur
chaque apprenant (courbe de
notes, avancement dans le cours,
avancement dans le niveau, time-
line) afin de suivre l’évolution de
chaque apprenant.
US[2] Consulter statis- En tant qu’apprenant, je peux 3 heures

tiques consulter des statistiques, afin de
suivre mon évolution.
US[3] En tant qu’administrateur, je 3 heures

peux consulter des statistiques
(nombre d’élèves, nombres
d’instructeurs, nombre de créa-
teurs de cours) afin de suivre les
utilisateurs de la plateforme.
130
US[4] En tant qu’administrateur, je peux 3 heures

suivre l’avancement de la courbe
âges des apprenants afin de suivre
la tranche d’âges des apprenants
inscrits dans la plateforme.
US[5] En tant qu’administrateur, je peux 3 heures

suivre des statistiques (tranche
d’âges des apprenants) afin de
suivre la tranche d’âges des ap-
prenants.
US[6] En tant qu’apprenant, je peux par- 3 heures

ticiper à un forum afin d’interagir
avec l’instructeur et les autres ap-
prenants.
US[7] Participer forum En tant qu’instructeur, je peux 3 heures

participer à un forum afin de ré-
pondre aux questions des appre-
nants.
TABLE 6.1 – Backlog du sprint

131
2.1 Diagramme de cas d’utilisation
Avec ce diagramme de cas d’utilisation, 6.1 on décrit précisément les cas d’utilisation du
deuxième sprint. Le créateur de cours peut gérer tous les types de nœuds, de paths ainsi que
déposer des tests et des challenges.
FIGURE 6.1 – Diagramme de cas d’utilisation du sprint 4
2.2 Raffinement des cas d’utilisation du sprint
L’analyse des cas d’utilisation permet de recueillir, et d’organiser les besoins, et de recenser
les grandes fonctionnalités d’un système dans ce sprint .
Raffinement du cas d’utilisation «Consulter les statistiques de la plateforme»
Avec ce cas d’utilisation 6.2 , l’administrateur peut consulter les statistiques de la plateforme :
nombre d’ apprenants (instructeurs, créateurs de cours, apprenants et administrateurs), il peut
aussi suivre les classes d’âges des apprenants qui utilisent la plateforme. Ainsi, le nombre des
apprenants inscrits dans des paths.
132
FIGURE 6.2 – Raffinement de cas d’utilisation «Consulter les statistiques de la plateforme»
Raffinement du cas d’utilisation «Suivre avancement des apprenants»

Dans ce cas utilisation 6.3 , permet à l’instructeur de lister les apprenants inscrits dans un path
et de suivre leurs avancements.
Raffinement du cas d’utilisation «Suivre son avancement»

Ce cas d’utilisation 6.4 , un apprenant peut suivre son avancement dans le path dont il est inscrit.
133
2.3 Description textuelles des cas d’utilisation
Dans cette rubrique on décrit les scénarios de certains cas d’utilisation.

Analyse du cas d’utilisation « Consulter nombre utilisateurs »
l’administrateur peut consulter le nombre des utilisateurs par rôle.
Pré-conditions S’authentifier
Post-conditions Afficher le nombre de chaque utilisateur.
Scénario nominal ➊ L’administrateur accède à son tableau de bord.

➋ Le système affiche le nombre des apprenants, des instruc-
teurs et des créateurs de cours.
scénarios alternatifs Néant
Analyse du cas d’utilisation « Consulter pourcentage des apprenants inscrits »

Ce scénario décrit le nombre des apprenants inscrits dans un path .
Pré-conditions S’authentifier
134
Post-conditions Afficher le pourcentage des apprenants inscrits.
Scénario nominal ➊ L’administrateur accéde à son tableau de bord.

➋ Le système calcule le pourcentage des apprenants inscrit à
un parcours.
➌ Le système affiche le pourcentage des apprenants inscrit à
un parcours.
TABLE 6.3 – Description textuelle du cas d’utilisation « Consulter pourcentage des apprenants
inscrits »
Analyse du cas d’utilisation « Consulter nombre de nœuds visités par jour »

l’apprenant peut savoir le nombre de nœuds visités par jour.
Acteur Apprenant
Pré-conditions - Apprenant a consulté le contenu du parcours choisi.

- S’authentifier.
Post-conditions Apprenant inscrit à un parcours
Scénario nominal ➊ L’apprenant accède à son tableau de bord.

➋ le système affiche une courbe qui représente le nombre de
nœuds visité en fonction de la date du jour.
TABLE 6.4 – Description textuelle du cas d’utilisation « Consulter nombre de nœuds visités par
jour »
3 Conception
Dans cette partie on décrit les processus répondant aux besoins en tenant compte des contraintes
de ce sprint .
135
3.1 Diagrammes de séquence détaillés
Les diagrammes de séquence détaillés se concentrent plus précisément sur les lignes de vie,
les processus et les objets qui vivent simultanément, et les messages qu’ils échangent entre eux
pour exercer une fonction avant la fin de la ligne de vie.
Diagramme de séquence detaillé «Consulter nombre des utilisateurs»
Dans ce diagramme figure 6.5 , l’administrateur peut suivre le nombre des utilisateurs de la
plateforme par rôle .
FIGURE 6.5 – Diagramme de séquence détaillé «Consulter nombre des utilisateurs»
Diagramme de séquence detaillé «Visualiser le pourcentage des nœuds consultés et non

consultés par jour»
Dans ce diagramme figure 6.6 , l’apprenantpeut suivre le pourcentage des nœuds consultés
et non consultés dans son path par jour.
136
FIGURE 6.6 – Diagramme de séquence détaillé «Visualiser le pourcentage des nœuds consultés
et non consultés par jour»
Diagramme de séquence detaillé «Visualiser les classes d’âges des apprenants»

Dans ce diagramme figure 6.7 , l’administrateur peut visualiser les classes d’âges des appre-
nants inscrits sur la plateforme.
FIGURE 6.7 – Diagramme de séquence détaillé «Visualiser les classes d’âges des apprenants»
Diagramme de séquence detaillé «Lister les chat rooms»

Dans ce diagramme figure 6.8 ,l’apprenant peut consulter tous les chat rooms (rooms et joi-
ned rooms).
137
FIGURE 6.8 – Diagramme de séquence detaillé «Lister les chat rooms»
Diagramme de séquence detaillé «Créer chat room»

Dans ce diagramme figure 6.9 ,l’apprenant peut créer un chat room.
FIGURE 6.9 – Diagramme de séquence detaillé «Créer chat room»
138
3.2 Diagramme de classe du sprint
ON présente dans cette rubrique le diagramme de classe du sprint .
FIGURE 6.10 – Diagramme de classe su quatrième sprint
4 Réalisation
On décrit dans la réalisation la démarche de developpement du code backend par les sché-
plémentés
sender celui qui envoie le message User Required
room Le sallon à laquelle appartient le mes- Room Required

sage
message Le message clair String Required
139

ment
TABLE 6.5 – Collection message
creator le créateur du sallon User Required
label Le nom du sallon String Required
roomPictureLink Le message clair String Required
isPublic Indique si le sallon est publique ou non Boolean Default : 1

ment
TABLE 6.6 – Collection sallon de communication
student Le membre qui appartient au sallon User Required
room Le sallon actuel Room Required

ment
TABLE 6.7 – Collection membres du sallon
140
student Le membre actuel User Required
Score Le score que l’apprenanta obtenu en Number Default : 0

progressant dans la plate-forme

ment
TABLE 6.8 – Collection statistiques
4.2 Implémentation
En ce qui concerne le forum, nous avons utilisé la bibliothèque Socket-IO. Elle assure la com-
munication bidirectionnelle entre le client et le serveur en temps réel. En outre, elle utilise un
mécanisme événementiel à la réception des messages et exécute un traitement à leurs réception
que ce soit côté client ou côté serveur.
FIGURE 6.11 – Créer room
Pour la partie statistiques chaque utilisateur peut consulter les statistiques selon son rôle
dans la plateforme dans son interface d’accueil.
141
4.3 Interfaces
Les interfaces présentées dans ce chapitre sont les interfaces des statistiques pour chaque
utilisateur selon son rôle interface statistique 6.12 de l’administrateur :
FIGURE 6.12 – interface statistique de l’administrateur
Interface statistique 6.13 de l’apprenant :
FIGURE 6.13 – interface statistique de l’étudiant
Interface statistique 6.14 du créateur de cours :
142
FIGURE 6.14 – interface statistique du créateur de cours
Interface créer chat room 6.15 de l’instructeur :
FIGURE 6.15 – interface créer chat room
Interface forum 6.16 :
143
FIGURE 6.16 – interface forum
Conclusion
Dans ce sprint chaque utilisateur peut consulter les statistiques adéquates à son rôle. L’ins-
tructeur et l’apprenantpeuvent participer au forum pour échanger les informations concernant
le path. Un système de notification est mis à la disposition des instructeurs et des apprenants
pour suivre les actualités de messagerie.
144
CONCLUSION ET PERSPECTIVES
Durant la période du stage et dans le cadre de notre projet de fin d’étude, qui s’est déroulé
dans la startup Opus Lab, nous avons réalisé une plateforme de e-learning, destinée à l’appren-
tissage en ligne des compétences requises dans le secteur du digital, comme les technologies du
web et le digital marketing.
Cette application permet à un apprenant de choisir un path qui lui convient selon ses ob-
jectifs En plus, des challenges sont offerts pour lui donner la chance pour explorer le monde
professionnel et prendre la résponsabilité d’achever un projet dans les délais . En plus, un tuteur
peut à travers notre système évaluer les apprenants et avoir une idée sur le profil de chacun .
Dans notre système de e-learning, nous avons utilisé le concept des nœuds et de path. Il
consiste à rediriger le concept traditionnel de l’éducation en ligne et le remodeler en rendant
l’apprentissage un exercice amusant, dynamique et créatif.
Pour achever dans les délais l’objectif de notre projet, nous avons utilisé l’approche SCRUM,
qui était la méthode de conduite de projet préconisée dans la société d’accueil. Ainsi, des réunions
régulières ont été menées pour le développement du projet qui s’est étalé sur quatre sprints. Les
daily scrum, les sprints reviews et les sprints rétrospectives ont été pratiqués dans le développe-
ment de notre projet
REACTJS nous a facilité la décomposition puis l’intégration des différentes composantes du
système qui sont réutilisables indépendamment. En plus, nous avons opté pour un système de
gestion de base de données orienté documents MONGODB. Il a la capacité à gérer des systèmes
de données complexes et hétérogènes allant des listes aux d’ objets encapsulés. Ainsi, chaque
document peut avoir son propre ensemble de champs uniques dans une collection.
145
Conclusion et Perspectives
En plus, REACT FLOW est utilisé pour la création des paths et des nœuds dont le contenu est
assuré par S3 CLOUD. Ce qui permet le téléchargement et le téléversement des fichiers de type
MD qui comprennent les travaux des apprenants ou bien leurs corrections.
Pour assurer la communication entre le backend et le frontend, nous avons utilisé l’outil Do-
cker, sur lequel repose la technologie de container pour prendre en charge les tâches de création
d’applications basées container. Le moteur crée un processus daemon server-side, pour ’héber-
ger les images, les containers, les réseaux et les volumes de stockage.
Pour sécuriser notre système d’authentification, nous avons utilisé JWT. Il assure la sécurité
entre les utilisateurs en partageant les informations en tant qu’objet JSON. La sécurité se traduit
par le chiffrement des clés privées utilisées par l’émetteur pour signer le jeton. Le destinataire
vérifie la signature pour s’assurer que la signature du jeton n’a pas été modifiée par l’émetteur
En ce qui concerne le forum, nous avons utilisé la bibliothèque Socket-IO. Elle assure la com-
munication bidirectionnelle entre le client et le serveur en temps réel. En outre, elle utilise un
mécanisme événementiel à la réception des messages et exécute un traitement à leurs réception
que ce soit côté client ou côté serveur.
Enfin le déploiement de ce travail s’est exécuté par AMAZON WEB SERVICE, plus précisé-
ment, Amazon Elastic Compute Cloud ou EC2 qui constitue un service web autorisant les entre-
prises à exécuter leurs applications sur le cloud public Amazon Web Services. Ces applications
sont exécutées par des machines virtuelles sur les serveurs des centres de données AWS.
Les perspectives de développement sont nombreuses. En effet, pour améliorer l’expérience
des usagers, un utilisateur peut consulter son historique et être averti par un système de notifica-
tion en temps réel. En outre, une application mobile facilitera l’accès à la plateforme aux usagers.
Nous pourrons aussi intégrer un système de paiement en ligne facilitant l’inscription aux utilisa-
teurs. D’autres fonctionnalités intelligentes peuvent être aussi envisagées utilisant les données
des utilisateurs pour un système de recommandations.
146
RÉFÉRENCES BIBLIOGRAPHIQUES
[1] CALLIMEDIA e Learning Solutions. Bien choisir sa plateforme e-learning. https://www.

callimedia.fr/bien-choisir-sa-plateforme-e-learning, 2020.
[2] Florent Lothon. Introduction aux méthodes agiles et scrum. https://agiliste.fr/

introduction-methodes-agiles/, 2021.
[3] Julie Gielen. Qu’est-ce que la méthodologie scrum ? https://www.planzone.fr/blog/

quest-ce-que-la-methodologie-scrum, 2017.
[4] Facebook Inc. React. https://fr.reactjs.org/, 2022.
[5] Rayed Benbrahim. Nodejs : le guide complet pour tout comprendre du javascript serveur.
https ://practicalprogramming.fr/, 2022.
[6] CCM Benchmark. Python : définition et utilisation de ce langage informatique.

https ://fr.wikipedia.org/, 2022.
[7] Inc. Wikimedia Foundation. Nosql. https ://fr.wikipedia.org/wiki/NoSQL, 2021.
[8] individual mozilla.org contributors. Express web framework. https ://develo-

per.mozilla.org/, 2022.
[9] Inc. Red Hat. Une api rest. https ://www.redhat.com/fr/topics/api/what-is-a-rest-api, 2022.
[10] NUMENDO. Tailwind css, le framework totalement personnalisable.

https ://www.numendo.com/blog/framework/tailwind-css-framework-totalement-
personnalisable/, 2022.
[11] Inc. Red Hat. Docker, qu’est-ce que c’est ? https ://www.redhat.com/fr/topics/containers/what-
is-docker, 2022.
147
RÉFÉRENCES BIBLIOGRAPHIQUES
[12] Tutorials examples. https ://www.tutorialandexample.com/react-redux, 2022.
[13] Inc. Amazon Web Services. Cloud computing avec aws. https ://aws.amazon.com/fr/what-
is-aws/, 2022.
[14] Redis Ltd. Combiner les avantages d’une technologie de base de données de classe mon-
diale avec l’innovation de l’open source. https ://redis.com/fr/pourquoi-redis/, 2022.
[15] WayToLearnX. . Différence entre mvc et mvvm. https ://waytolearnx.com/2020/06/difference-

entre-mvc-et-mvvm.html, 2022.
[16] Framalibre. . Visual studio code, 2022.
[17] Google chrome, 2022.
[18] IONOS SARL . Qu’est-ce que github ? la gestion de versions en quelques mots, 2022.
[19] GitLab B.V. Plateforme gitlab devops. https ://about.gitlab.com/fr-fr/, 2022.
[20] Geek Flare . 10 meilleurs outils de développement et de test d’api, 2022.
[21] Pourquoi utiliser adobe xd pour le prototypage ?, 2022.
[22] Lucid Software Inc. Lucid chart. https ://www.lucidchart.com/pages/fr/exemple/uml-

online., 2022.
[23] Latex, un langage pour éditer du texte scientifique : Overleaf. https ://paris-
sorbonne.libguides.com/c.php ?g=497641p=4637541 : :text=Overleaf., 2021.
[24] Microsoft. Travail hybride : travaillez à domicile et/ou à distance.

https ://www.microsoft.com/fr-ww/microsoft-teams/hybrid-work-from-home, 2022.
148

Safé Et Zeineb

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Safé Et Zeineb

Transféré par

Droits d'auteur :

Formats disponibles

Ministère de l’enseignement supérieur

RAPPORT DE FIN D’ÉTUDES EN VUE DE L’OBTENTION DU DIPLÔME DE

« LICENCE EN BUSINESS COMPUTING »

Conception et développement d’une

Réalisé par Encadrant :

Organisme d’accueil « Opuskills Lab »

Encadrant professionnel, HAMDI Sayed

Encadrant académique, BOUZIRI Hend

Nous dédions ce modeste travail à :

3 SPRINT 1 - Authentification et gestion des comptes 53

4 SPRINT 2 - Gestion du contenu de la plateforme 76

5 SPRINT 3 - Exploitation du contenu de la plateforme 104

6 SPRINT 4 - Forum et statistiques 129

Conclusion et Perspectives 145

Références bibliographiques 148

1.1 Points forts et points faibles de DataCamp . . . . . . . . . . . . . . . . . . . . . . 22

2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.1 Backlog du produit sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.1 Backlog du produit sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

6.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

1.1 Organigramme d’OpusLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 Diagramme de cas d’utilisation général du sprint 1 . . . . . . . . . . . . . . . . . 56

4.1 Diagramme de cas d’utilisation du sprint 2 . . . . . . . . . . . . . . . . . . . . . 79

6.1 Diagramme de cas d’utilisation du sprint 4 . . . . . . . . . . . . . . . . . . . . . 132

LISTE DES ACRONYMES

LMS : Learning Management System

L’évolution du marché de l’emploi et des compétences nécessaires, ont conduit à la naissance

tournant et surtout avec la pandémie. Le COVID-19 a remis en question le modèle traditionnel

L’éducation doit-elle inventer de nouvelles formes, de nouveaux périmètres dans le paysage

1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . 19

1 Présentation de l’organisme d’accueil

1.1 Organigramme de la startup

FIGURE 1.1 – Organigramme d’OpusLab

La présentation de l’organigramme facilite la compréhension des relations de travail entre les

1.2 Incubateur de la startup : BIATLABS

L’apprentissage en ligne exploite les technologies interactives et les systèmes de communi-

FIGURE 1.2 – Interface de DataCamp

Points forts Points d’efforts

Communauté active. Il n’y a pas de tests formels pour évaluer

TABLE 1.1 – Points forts et points faibles de DataCamp

FIGURE 1.3 – Taki Academy

expose quelques points forts et points faibles de la platforme TakiAcademy

Points forts Points faibles

Possibilité de suivre des cours en direct. Le développement des compétences en com-

TABLE 1.2 – Points forts et points faibles de Taki Academy

FIGURE 1.4 – Khan Academy

toire, la finance, la physique, la chimie, la biologie, l’astronomie, la musique, l’art pictural et

Points forts Points faibles

offre une expérience d’apprentissage Certains chapitres n’ont pas d’exercices et

TABLE 1.3 – Points forts et points d’efforts de Khan Academy

Data Camp Taki Academy Khan Academy

Authentification et autorisation oui oui oui

Gestion de profils oui oui oui

Fonctionnalités intelligentes oui non oui

Gamification oui non oui

Gestion des cours oui non oui

Gestion des communautés non non non

TABLE 1.4 – Analyse générale de l’étude d’exsistant

2.3 Solution proposée

L’objectif d’OpusLab est d’enseigner et de partager des connaissances et de l’expertise en dé-

3.1 Cycle de vie de SCRUM

FIGURE 1.5 – Cycle de vie de SCRUM