Université de Tunis
Institut Supérieur de Gestion de Tunis
RAPPORT DE STAGE DE FIN D’ÉTUDES
En vue de l’obtention du diplôme de
La licence fondamentale en informatique de gestion
Développement de l’application mobile du portail "MyU"
Organisme d’accueil :
Honoris United Universities
Réalisé par :
Kamoun Hédi
Sallem Marwen
Encadrant pédagogique
Encadrante professionnelle
Mr. Katar Chaker
Mme. Bsila Wafa
Année universitaire
2020/2021
Dédicace
Je dédie ce travail,
A ma grand-mère Hayet Badri Attia. Merci mamy pour ton infinie tendresse et ton amour
inconditionnel. J’ai beaucoup de chance de t’avoir.
A mon grand-père Mohamed Attia. Tu aurais été fier de moi. Tu me manques.
A mes parents. Vous illuminez mes jours par votre présence, vos conseils et par la fierté que
je vois dans vos yeux.
A mon grand frère Selim, mon compagnon et mon meilleur ami. Merci d’être toujours la
pour moi et de m’administrer des doses de confiance en moi chaque fois qu’il le faut.
A mon oncles et mes tantes. Je vous dois beaucoup.
A Marwen. Pour touts les belles choses qu’on a partagé tout au long de ces deux dernières
années, nos veillées jusqu’au lever du jour et notre complicité.
Au très cher comité du club Rotaract ISG Tunis ainsi qu’à tous les membres de cette
merveilleuse famille, merci d’avoir toujours été là pour moi.
-Hedi.
1
Dédicace
A mes chers parents,
Merci pour vos sacrifices innombrables et votre soutien tout au long ma vie,je dois tout mon
succès à vous.
A la plus belle femme au monde, ma grand-mère Chrifa Nefzi,
Je t’aime plus que les mots ne peuvent le dire.
A mes petites soeurs et petits frères,
Merci d’avoir été le Jerry pendant les 17 dernières années de ma vie.
A ma grande Soeur Jamila,
Mon amie d’enfance et partenaire dans le crime qui gère toujours à s’échapper je t’aime
beaucoup, Je te souhaite tout le succès.
A ma famille du Croissant Rouge Hammam Lif,
Votre soutien vaut le monde pour moi, que Dieu vous protège.
A mes amis proches
Que votre vie soit remplie de bonheur et de réussite.
-Marwen
2
Remerciement
C’est avec un grand plaisir et beaucoup de gratitude que nous présentons nos remercie-
ments et notre profonde reconnaissance à tous ceux qui, de prés ou de loin, ont contribué à
l’aboutissement de ce travail.
Nos remerciements s’adressent à notre encadrant pédagogique Mr Katar Chaker et notre
encadrante professionnelle Mme Bsila Wafa pour leur disponibilité et leurs précieuses recom-
mandations.
Nous remercions également les membres du jury pour avoir bien voulu donner de leur temps
pour lire et évaluer ce travail.
Nos remerciements vont également à Mme la directrice IT Somai Meriem.
Enfin, nous tenons à exprimer notre gratitude envers tous les enseignants de l’ISG Tunis.
3
Table des matières
Table des figures
Liste des tableaux
Introduction
1 Contexte général du projet
1.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Présentation de l’organisme d’accueil
. . . . . . . . . . . . . . . . . . . . . .
1.3 Contexte et cadre du projet
. . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.3
Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1 L’approche agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.2 La méthode SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.3 Principe de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Sprint 0: Planification et architecture
2.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
12
13
14
16
16
17
17
18
18
19
19
19
20
20
22
23
23
24
TABLE DES MATIÈRES
2.3
Identification des besoins fonctionnels et non fonctionnels . . . . . . . . . . .
2.3.1
Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Les besoins fonctionnels
. . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . .
2.4 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 Découpage du projet en sprints
. . . . . . . . . . . . . . . . . . . . . . . . .
2.6 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . .
2.7 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.7.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.7.2 Avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Sprint 1: Gestion des comptes
3.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Sprint Backlog
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Analyse du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Diagramme de cas d’utilisation global du Sprint 1 . . . . . . . . . . .
3.3.2 Raffinement du cas d’utilisation "S’Authentifier" . . . . . . . . . . . .
3.3.3 Description textuelle du cas d’utilisation "s’authentifier" . . . . . . .
3.3.4 Raffinement du cas d’utilisation "Gérer etudiants" . . . . . . . . . . .
3.3.5 Raffinement du cas d’utilisation "Gérer comptes" . . . . . . . . . . .
3.3.6 Raffinement cas d’utilisation "Gérer profil" . . . . . . . . . . . . . . .
3.3.7 Raffinement du cas d’utilisation "Gérer groupes"
. . . . . . . . . . .
3.3.8 Raffinement du cas d’utilisation "Gérer formations" . . . . . . . . . .
3.3.9 Prototype d’interfaces
. . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Conception du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
24
24
24
27
29
31
32
33
33
34
34
35
35
36
37
37
38
39
40
40
41
43
43
44
45
3.4.1 Diagramme de classe de conception du cas d’utilisation "S’Authentifier" 45
3.4.2 Diagramme de séquence détaillé du cas d’utilisation "S’Authentifier"
46
TABLE DES MATIÈRES
6
3.4.3 Diagramme de classe de conception "Gérer etudiants" . . . . . . . . .
47
3.4.4 Diagramme de séquence détaillé du cas d’utilisation "Ajouter etudiant" 48
3.4.5 Diagramme de classe de conception "Gérer comptes" . . . . . . . . .
3.4.6 Diagramme de séquence détaillé du cas d’utilisation "Créer compte" .
49
50
3.4.7 Diagramme de séquence détaillé du cas d’utilisation "Consulter compte" 51
3.4.8 Diagramme de classe de conception "Gérer profil" . . . . . . . . . . .
3.4.9 Diagramme de séquence détaillé du cas d’utilisation "Consulter profil"
3.4.10 Diagramme de classe de conception "Gérer groupes"
. . . . . . . . .
3.4.11 Diagramme de séquence détaillé du cas d’utilisation "Créer groupe" .
3.4.12 Diagramme de classe de conception "Gérer formations" . . . . . . . .
52
52
54
55
56
3.4.13 Diagramme de séquence détaillé du cas d’utilisation "Créer formation" 57
3.4.14 Diagramme de classe sprint 1 . . . . . . . . . . . . . . . . . . . . . .
3.5
Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Publicité
3.5.1
Schéma de la base de données du sprint 1
. . . . . . . . . . . . . . .
3.5.2 Authentification et sécurité
. . . . . . . . . . . . . . . . . . . . . . .
3.5.3 Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.4 Présentation des interfaces utilisateur . . . . . . . . . . . . . . . . . .
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Sprint 2: Gestion du E-Learning
4.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Sprint Backlog
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Analyse du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Diagramme de cas d’utilisation du Sprint 2 . . . . . . . . . . . . . . .
4.3.2 Raffinement du cas d’utilisation "Gérer plan d’étude" . . . . . . . . .
4.3.3 Raffinement du cas d’utilisation "Gérer enseignants" . . . . . . . . .
4.3.4 Description textuelle du cas d’utilisation "Consulter enseignants" . .
4.3.5 Raffinement du cas d’utilisation "Gérer emploi du temps"
. . . . . .
58
59
59
60
61
62
63
64
64
65
66
66
67
68
69
70
TABLE DES MATIÈRES
4.3.6 Description textuelle du cas d’utilisation "Consulter emploi du temps"
4.3.7 Raffinement du cas d’utilisation "Gérer cours en ligne" . . . . . . . .
4.3.8 Description textuelle du cas d’utilisation "Consulter cours en ligne" .
4.3.9 Prototype d’interfaces
. . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 Conception du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1 Diagramme de classe de conception "Gérer cours en ligne" . . . . . .
4.4.2 Diagramme de séquence détaillé du cas "Lister fichiers" . . . . . . . .
4.4.3 Diagramme de séquence détaillé du cas "consulter cours en ligne" . .
4.4.4 Diagramme de classe de conception "Gérer emploi du temps" . . . . .
4.4.5 Diagramme de séquence détaillé du cas "Créer seance" . . . . . . . .
4.4.6 Diagramme de séquence détaillé du cas "Consulter emploi du temps"
4.4.7 Diagramme de classe du Sprint 2 . . . . . . . . . . . . . . . . . . . .
4.5
Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.1
Schéma de la base de données du sprint 2
. . . . . . . . . . . . . . .
4.5.2 Présentation des interfaces utilisateurs
. . . . . . . . . . . . . . . . .
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Sprint 3: Gestion des affaires éstudiantines
5.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Sprint Backlog
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Analyse du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Diagramme de cas d’utilisation du sprint 3 . . . . . . . . . . . . . . .
5.3.2 Raffinement du cas d’utilisation "Gérer tickets" . . . . . . . . . . . .
5.3.3 Description textuelle du cas d’utilisation "Enregistrer ticket" . . . . .
5.3.4 Raffinement du cas d’utilisation "Gérer examens" . . . . . . . . . . .
7
71
72
73
74
75
75
76
78
80
81
82
84
85
85
87
88
89
89
90
91
91
92
93
94
5.3.5 Description textuelle de cas d’utilisation "Consulter planning examens" 95
5.3.6 Raffinement du cas d’utilisation "Gérer absences" . . . . . . . . . . .
5.3.7 Raffinement du cas d’utilisation "Gérer notes et résultats" . . . . . .
96
97
TABLE DES MATIÈRES
5.3.8 Raffinement du cas d’utilisation "Gérer actualites" . . . . . . . . . .
5.3.9 Prototype d’interfaces
. . . . . . . . . . . . . . . . . . . . . . . . . .
8
98
99
5.4 Conception du Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4.1 Diagramme de classe de conception "Gérer tickets" . . . . . . . . . . 100
5.4.2 Diagramme de séquence détaille du cas "Lister tickets" . . . . . . . . 101
5.4.3 Diagramme de séquence détaillé du cas "Enregistrer ticket" . . . . . . 102
5.4.4 Diagramme de classe de conception "Gerer examens" . . . . . . . . . 103
5.4.5 Diagramme de séquence détaillé du cas "Consulter planning examens" 104
5.4.6 Diagramme de classe sprint 3 . . . . . . . . . . . . . . . . . . . . . . 105
5.5
Implémention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.5.1
Schéma de la base de données du sprint 3
. . . . . . . . . . . . . . . 107
5.5.2 Présentations des interfaces utilisateurs . . . . . . . . . . . . . . . . . 109
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6 Sprint 4: Dockerisation
111
6.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.2 Technologie Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.3 Comparaison VM et Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6.4 Déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.4.1 Architecture docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.4.2 Codage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
7 Environnement de développement
117
7.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.2.1 Environnement matériel
. . . . . . . . . . . . . . . . . . . . . . . . . 118
7.2.2 Environnement logiciel
. . . . . . . . . . . . . . . . . . . . . . . . . . 119
TABLE DES MATIÈRES
9
7.2.3 Technologie utilisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Conclusion générale et perspective
Webographie
122
123
Table des figures
1.1 Logo de Honoris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
cycle de vie de la méthode SCRUM[5] . . . . . . . . . . . . . . . . . . . . . .
2.1 UI et UX[6]
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Découpage des Sprints
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . .
2.4 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 Diagramme de cas d’utilisation Sprint 1 . . . . . . . . . . . . . . . . . . . . .
3.2 Diagramme de cas d’utilisation du cas "s’Authentifier" . . . . . . . . . . . .
3.3 Diagramme de cas d’utilisation raffiné "Gérer etudiants" . . . . . . . . . . .
3.4 Diagramme de cas d’utilisation raffiné "Gérer comptes" . . . . . . . . . . . .
3.5 Diagramme de cas d’utilisation Raffiné "Gérer profil" . . . . . . . . . . . . .
3.6 Diagramme de cas d’utilisation raffiné "Gérer groupes" . . . . . . . . . . . .
3.7 Diagramme de cas d’utilisation raffiné "Gérer formations" . . . . . . . . . .
3.8 Maquettes d’interfaces du Sprint 1
. . . . . . . . . . . . . . . . . . . . . . .
3.9 Diagramme de classe de conception "s’Authentifier" . . . . . . . . . . . . . .
3.10 Diagramme de séquence détaillé "s’Authentifier" . . . . . . . . . . . . . . . .
3.11 Diagramme de classe de conception "Gérer etudiants" . . . . . . . . . . . . .
3.12 Diagramme de séquence détaillé "Créer etudiant" . . . . . . . . . . . . . . .
3.13 Diagramme de classe de conception "Gérer comptes" . . . . . . . . . . . . .
17
20
28
31
32
33
37
38
40
40
41
43
43
44
45
46
47
48
49
10
TABLE DES FIGURES
3.14 Diagramme de séquence détaillé "Créer compte" . . . . . . . . . . . . . . . .
3.15 Diagramme de séquence détaillé "Consulter compte" . . . . . . . . . . . . .
3.16 Diagramme de séquence détaillé "Gérer profil" . . . . . . . . . . . . . . . . .
3.17 Diagramme de séquence détaillé "Consulter profil
Publicité
. . . . . . . . . . . . . . .
3.18 Diagramme de classe de conception "Gérer groupes" . . . . . . . . . . . . . .
3.19 Diagramme de séquence détaillé "Créer groupe . . . . . . . . . . . . . . . . .
3.20 Diagramme de classe de conception "Gérer formations" . . . . . . . . . . . .
3.21 Diagramme de séquence détaillé "Créer formation . . . . . . . . . . . . . . .
3.22 Diagramme de classe Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . .
3.23 Schéma de la base de données sprint 1 . . . . . . . . . . . . . . . . . . . . .
3.24 Création du Token lors de l’authentification par le serveur
. . . . . . . . . .
3.25 Réception des notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.26 Interface utilisateur du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . .
4.1 Diagramme de cas d’utilisation du Sprint 2 . . . . . . . . . . . . . . . . . . .
4.2 Diagramme de cas d’utilisation raffiné "Gérer plan d’étude" . . . . . . . . .
4.3 Diagramme de cas d’utilisation raffiné "Gérer enseignants" . . . . . . . . . .
4.4 Diagramme de cas d’utilisation raffiné "Gérer emploi du temps" . . . . . . .
4.5 Diagramme de cas d’utilisation raffiné "Gérer cours" . . . . . . . . . . . . .
4.6 Maquettes interfaces du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . .
4.7 Diagramme de classe de conception "Gérer cours en ligne" . . . . . . . . . .
4.8 Diagramme de séquence détaillé du cas d’utilisation "Lister fichiers" . . . . .
4.9 Diagramme de séquence détaillé du cas d’utilisation "Consulter cours" . . . .
4.10 Diagramme de classe de conception "Gérer emploi du temps" . . . . . . . . .
4.11 Diagramme de séquence détaillé du cas d’utilisation "Créer séance" . . . . .
4.12 Diagramme de séquence détaillé du CU "Consulter emploi du temps" . . . .
4.13 Diagramme de classe du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . .
4.14 Schéma de la base de donnée sprint 2 . . . . . . . . . . . . . . . . . . . . . .
11
50
51
52
53
54
55
56
57
58
59
60
61
62
66
67
68
70
72
74
75
77
79
80
81
83
84
86
TABLE DES FIGURES
12
4.15 Présentation des interfaces du Sprint 2 . . . . . . . . . . . . . . . . . . . . .
87
5.1 Diagramme de cas d’utilisation du Sprint 3 . . . . . . . . . . . . . . . . . . .
5.2 Diagramme de cas d’utilisation "Gérer tickets" . . . . . . . . . . . . . . . . .
5.3 Diagramme de cas d’utilisation "Gérer examens" . . . . . . . . . . . . . . . .
5.4 Diagramme de cas d’utilisation "Gérer absences"
. . . . . . . . . . . . . . .
5.5 Diagramme de cas d’utilisation "Gérer les notes et résultats" . . . . . . . . .
5.6 Diagramme de cas d’utilisation "Gérer actualites" . . . . . . . . . . . . . . .
5.7 Maquettes d’interfaces du Sprint 3
. . . . . . . . . . . . . . . . . . . . . . .
91
92
94
96
97
98
99
5.8 Diagramme de classe de conception "Gérer tickets" . . . . . . . . . . . . . . 100
5.9 Diagramme de séquence détaillé du cas d’utilisation "Lister tickets" . . . . . 101
5.10 Diagramme de séquence détaillé du cas d’utilisation "Enregistrer ticket" . . . 102
5.11 Diagramme de classe de conception "Gerer examens" . . . . . . . . . . . . . 103
5.12 Diagramme de séquence détaillé du CU "Consulter planning examens" . . . 104
5.13 Diagramme de classe du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.14 Schéma de la base de donnée sprint 3 . . . . . . . . . . . . . . . . . . . . . . 108
5.15 Présentation des interfaces du Sprint 3 . . . . . . . . . . . . . . . . . . . . . 109
6.1 Virutalisation et conteneurisation[9] . . . . . . . . . . . . . . . . . . . . . . . 113
6.2 Architecture docker[9]
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.3 Conteneur Back-End et base de données
. . . . . . . . . . . . . . . . . . . . 115
6.4 DockerFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Liste des tableaux
2.1 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.1 Sprint Backlog 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Description textuelle du cas "S’authentifier" . . . . . . . . . . . . . . . . . .
3.3 Description textuelle du cas "Consulter profil" . . . . . . . . . . . . . . . . .
3.4 Description textuelle du cas "Modifier profil" . . . . . . . . . . . . . . . . . .
4.1 Sprint Backlog 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Description textuelle du cas "Consulter enseignants" . . . . . . . . . . . . .
4.3 Description textuelle du cas "Consulter emploi du temps" . . . . . . . . . . .
4.4 Description textuelle du cas "Consulter mes cours" . . . . . . . . . . . . . .
5.1 Sprint Backlog 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Description textuelle du cas "Enregistrer ticket" . . . . . . . . . . . . . . . .
5.3 Description textuelle du cas "Consulter ticket" . . . . . . . . . . . . . . . . .
5.4 Description textuelle du cas "Consulter planning examens" . . . . . . . . . .
36
39
41
42
65
69
71
73
90
93
93
95
6.1 Tableau comparatif entre Les VMs et Conteneurs[10]
. . . . . . . . . . . . . 113
7.1 Caractéristiques du 1er ordinateur . . . . . . . . . . . . . . . . . . . . . . . . 118
7.2 Caractéristiques du 2ème ordinateur
. . . . . . . . . . . . . . . . . . . . . . 118
13
Introduction
Il est vrai que le développement mobile augmente de plus en plus en notoriété surtout
ces dernières années avec la popularisation des smartphones et de la micro technologie.
Cette augmentation est due à la fiabilité, l’évolution et la portabilité qui permettent aux
grandes entreprises d’interagir avec les clients, partenaires et salariés ainsi qu’à la facilité
d’accéder à l’information depuis sa poche. Il est alors totalement logique d’estimer que les
applications mobiles sont un enjeu vital. Leur importance ne fait que grandir avec le temps,
et pour rester pertinent, il est de plus en plus important que votre organisation dispose
de sa propre application dédiée. De ce fait de plus en plus d’entreprises optent aujourd’hui
pour une stratégie de développement basée sur des services avec des fonctionnalités mobiles
intégrées. L’intégration du développement d’applications mobiles à une stratégie plus large
basée sur des micros services cloud-native offre de nombreux avantages : augmentation de
la productivité, réduction des coûts, renforcement de la sécurité, amélioration du niveau
de visibilité et de contrôle. C’est dans ce domaine que s’intègre notre projet de fin d’étude
qui est le «développent d’une application mobile» qui consiste à développer une application
mobile native qui aura pour but de permettre aux étudiants des établissements d’Honoris
United Universities d’accèder à leurs informations scolaires.
Ce rapport est reparti en 7 chapitres :
— Le premier chapitre sera consacré à une introduction générale de l’organisme d’ac-
cueil ainsi que du cadre et contexte du projet ainsi que la méthodologie de développe-
ment.
14
LISTE DES TABLEAUX
15
— Le second chapitre présentera l’analyse des besoins, Identification des besoins fonc-
tionnels et non fonctionnels, la mise en place du Backlog produit et le découpage des
Sprints.
— Les trois chapitres qui suivent seront consacrés aux 3 premiers Sprint, nous trai-
terons leurs analyse,conception et implementation.
— Le sixième chapitre montrera le déploiement de notre projet dans des conteneurs
Docker.
— Le dernier chapitre fera office de présentation de l’environnement de développement
de notre application.
Et enfin, nous terminerons par clôturer notre rapport avec une conclusion générale et une
perspective.
Chapitre 1
Contexte général du projet
1.1 Introduction
Ce chapitre sera représenté sous la forme d’un aperçu
du projet. Il englobera une présentation de l’orga-
nisme d’accueil ainsi que le cadre général de notre
projet. Ensuite nous passerons à l’étude de l’existant
suivi de sa critique, puis nous finirons par proposer
notre solution.
16
CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET
17
1.2 Présentation de l’organisme d’accueil
Figure 1.1 – Logo de Honoris
Honoris United Universities est le premier réseau panafricain d’enseignement supérieur
privé engagé dans la formation des nouvelles générations de leaders et de professionnels du
continent africain capables d’avoir un impact sur leurs sociétés et leurs économies.
Avec plus de 32 000 étudiants, répartis sur 58 campus, centres d’apprentissage ou en ligne,
dans 9 pays et 30 villes en Afrique, Honoris délivre plus de 150 diplômes dans les domaines
de la Science, de la Santé, de l’Ingénierie, du Business, du Droit, de l’Architecture, des Arts
et du Design, des Médias et des Sciences Politiques.[1]
Mission et valeurs
Les fondateurs de "Honoris united universities" partagent la vision de pouvoir préparer
et former des leaders et des professionnels axés sur les solutions capables d’opérer avec succès
sur le continent le plus jeune et à la croissance la plus rapide du monde, des individus capables
d’influencer les économies et les communautés de demain.[2]
1.3 Contexte et cadre du projet
Ce projet s’inscrit dans le cadre de notre projet de fin d’études pour l’obtention du di-
plôme de la licence fondamentale en informatique de gestion de l’institut supérieur de gestion
de Tunis.
CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET
18
Nous vivons désormais dans une ère où règne la portabilité notamment à travers les smart-
phones, en effet ces petits appareils font désormais partie de notre quotidien, tant sur le plan
personnel que dans le domaine professionnel ou éducatif. C’est pour cela qu’une entreprise
telle que "Honoris United Universities" leader panafricain de l’enseignement supérieur privé
se doit d’avoir une application mobile pour leurs instituts afin de se renforcer au niveau du
secteur mobile, une évolution qui est devenue nécessaire.
Publicité
C’est dans ce cadre que s’effectue notre projet qui consiste à développer une application
mobile native du portail étudiant "Myu".
1.3.1 Étude de l’existant
Avec la croissance exponentielle de la digitalisation et l’enseignement en ligne surtout
ces deux dernières années à cause de la soudaine crise du covid-19, nous réalisons qu’il est
important qu’un institut possède les bons outils pour bien mener une année universitaire
quelques soient les conditions.
Il existe plusieurs outils qui répondent à ce besoin, chaque institut disposant de son propre
portail étudiant comme par exemple le site "MYU" du groupe "Honoris United Universities"
ou encore "Environnement numérique de travail" de l’UVT.
1.3.2 Critique de l’existant
Lors de notre étude menée sur les deux platformes mentionnées précédemment, nous
avons constaté qu’il y a un manque de flexibilité notamment des interfaces qui se répètent
avec les mêmes couleurs et mêmes structures, une prise en charge seulement par navigateur
web et un manque total d’une application mobile. Ceci implique un manque d’intérêt envers
ces platformes.
CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET
19
1.3.3 Solution proposée
Le but de ce projet est de proposer une solution consistante sous forme d’une application
mobile native qui permettera aux étudiants des instituts d’enseignement supérieur du groupe
"Honoris United Universities" de bénéficier des avantages tels que :
— Une performance appropriée (optimisation du contenu et du temps de chargement)
— Un design moderne avec un "look and feel" adapté
— Un accès rapide et instantané aux fonctionnalités du portail.
— Utilisation des fonctionnalités du smartphone : photo, vidéo, GPS, push notifications,
stockage.
1.4 Méthodologie de développement
Pour assurer la bonne gestion d’un projet, il est indispensable de choisir une méthodologie
de gestion qui doit être d’une part, adaptée aux besoins évolutifs des utilisateurs et d’autre
part, adaptée à la vitesse d’évolution des priorités ainsi que des besoins.
1.4.1 L’approche agile
La méthode agile caractérise un mode de gestion des projets informatiques privilégiant
le dialogue entre toutes les parties prenantes, clients, utilisateurs, développeurs et autres
professionnels du projet, la souplesse en cours de réalisation, la capacité à modifier les plans
et la rapidité de livraison. Il s’agit de rompre avec les pratiques plus traditionnelles bien
trop rigides et trop exigeantes en matière de spécifications (contractuelles). Pour cela il
est important d’accorder la priorité au relationnel et à la communication étendue sur les
processus de développement.[3]
CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET
20
1.4.2 La méthode SCRUM
Scrum est la méthodologie la plus utilisée parmi les méthodes Agiles existantes. Le terme
Scrum (qui signifie mêlée) décrit une nouvelle approche plus rapide et flexible pour le dé-
veloppement de nouveaux produits. Cette méthode est comparée au rugby, du fait que
l’équipe avance ensemble et soit toujours prête à réorienter le projet au fur-et-à mesure
de sa progression.[4]
Figure 1.2 – cycle de vie de la méthode SCRUM[5]
1.4.3 Principe de SCRUM
Évidemment, l’approche SCRUM suit les principes de la méthodologie Agile, c’est-à-dire
l’implication et la participation active du client tout au long du projet. SCRUM se compose
de plusieurs éléments fondamentaux :[4]
— Rôles
— évènements
— artefacts
CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET
21
Répartition des rôles
— Scrum Master :
Il est responsable de la compréhension, de l’adhésion et de la mise en œuvre de la
méthode SCRUM qu’il maîtrise parfaitement. Il veille à ce que les principes et les
valeurs de la méthodologie soient respectés.
— Product owner :
Il porte la vision du produit à réaliser. Il travaille en interaction avec l’équipe de
développement qui doit suivre ses instructions. C’est lui qui établit la priorité des
fonctionnalités à développer ou à corriger, et qui valide les fonctionnalités terminées.
Il est responsable de la gestion du Backlog produit.
— L’équipe de développement :
est chargée de transformer les besoins définis par le Product Owner en fonctionnalités
utilisables.
Les différents événements
— Le Sprint :
Un Sprint est une itération. Il s’agit d’une période de 2 à 4 semaines maximum pen-
dant 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 a un objectif et une liste de
fonctionnalités à réaliser.
— Planification d’un Sprint : d’un Sprint :
Les tâches à accomplir pendant le Sprint sont déterminées par l’ensemble de l’équipe
Scrum lors de la réunion de planification de Sprint.
— Revue du Sprint :
Il s’agit du bilan du Sprint réalisé une fois le Sprint terminé.
CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET
22
Les artefacts
— Le Backlog produit :
Liste hiérarchisée des exigences initiales du client concernant le produit à réaliser. Ce
document évolue sans cesse durant le projet, en fonction des besoins du client.
— Le Sprint backlog :
C’est le plan détaillé de la réalisation de l’objectif du Sprint, défini lors de la réunion
de planification du Sprint.
— L’incrément :
Il s’agit de l’ensemble des éléments terminés du product backlog pour le Sprint en cours,
ainsi que ceux des Sprints précédents. L’incrément doit fonctionner et être utilisable.
1.5 Conclusion
Ce chapitre était une introduction générale de notre projet avec la présentation de l’or-
ganisme d’accueil, le cadre général et la méthodologie de développement adaptée.
Chapitre 2
Sprint 0 : Planification et architecture
2.1 Introduction
Ce chapitre sera basé sur les aspects techniques et
fonctionnels de notre projet. En effet cette partie aura
pour but de nous initier afin de comprendre l’architec-
ture, cerner les besoins fonctionnels et non fonction-
nels, identifier les acteurs principaux et secondaires et
enfin alimenter notre Backlog produit pour découper
notre projet en sprints.
23
CHAPITRE 2. SPRINT 0 : PLANIFICATION ET ARCHITECTURE
24
2.2 Analyse des besoins
Durant cette section, nous allons comprendre et identifier les besoins à satisfaire du client
tout en représentant les fonctionnalités à intégrer dans notre application.
Dans le cadre de ses activités estudiantines "Honoris United Universities" souhaite produire
une application mobile native intitulée MyU qui fera office d’un portail étudiant, cette der-
nière offrira alors aux étudiants un accès plus facile et plus rapide aux ressources de leur
université.
2.3 Identification des besoins fonctionnels et non fonc-
tionnels
Durant ce segment, nous allons identifier les acteurs de notre application et cerner les
besoins fonctionnels et non fonctionnels.
2.3.1
Identification des acteurs
Acteurs principaux :
Administrateur L’administrateur a pour mission de gérer toutes les fonctionnalités de
l’application. Il est aussi chargé d’intervenir lors de l’apparition de problèmes avec le compte
ou les informations d’un étudiant.
L’étudiant C’est l’utilisateur principal de notre application, celui autour duquel gravitent
toutes les fonctionnalités. En effet il peut consulter et télécharger les ressources qu’offre
l’application et profiter des services "Help desk".
2.3.2 Les besoins fonctionnels
Maintenant que nous avons identifié les acteurs, il est temps de passer à l’étape suivante
qui consiste à cerner les besoins fonctionnels.
CHAPITRE 2. SPRINT 0 : PLANIFICATION ET ARCHITECTURE
25
Les fonctionnalités de l’administrateur :
Gestion des étudiants
— L’administrateur peut consulter, créer, modifier ou supprimer le profil d’un étudiant.
Gestion des comptes utilisateur de l’application MyU
— L’administrateur peut consulter, créer, modifier ou supprimer le compte d’un étudiant.
Gestion des services proposés par l’application Myu
— L’administrateur peut consulter ou modifier un ticket enregistré par un étudiant.
Gestion des formations des étudiants inscrits à l’application MyU
— L’administrateur peut consulter, ajouter, modifier ou supprimer une formation.
Gestion des groupes des étudiants inscrits à l’application MyU
— L’administrateur peut consulter, ajouter, modifier ou supprimer un groupe.
Gestion des enseignants de l’application Myu
— L’administrateur peut consulter, ajouter, modifier ou supprimer un enseignant.
Gestion de l’emploi du temps des étudiant inscrits à l’application MyU
— L’administrateur peut consulter, ajouter, modifier ou supprimer une séance.
Gestion des épreuves des étudiants inscrits à l’application MyU
— L’administrateur peut consulter, ajouter, modifier ou supprimer un examen.
Gestion des notes et résultats des étudiants inscrits à l’application Myu
— L’administrateur peut consulter, ajouter, modifier ou supprimer une note.
— L’administrateur peut consulter, ajouter, modifier ou supprimer un résultat.
Gestion des absences des étudiants inscrits à l’application Myu
— L’administrateur peut consulter, ajouter, modifier, supprimer l’absence d’un étudiant.
Gestion du plan d’étude des étudiant inscrits à l’application Myu
CHAPITRE 2. SPRINT 0 : PLANIFICATION ET ARCHITECTURE
26
— L’administrateur peut consulter, ajouter, modifier ou supprimer un module selon la
formation.
— L’administrateur peut consulter, ajouter, modifier ou supprimer une matière selon le
module.
Gestion des cours en ligne des étudiants inscrits à l’application Myu
— L’administrateur peut consulter, ajouter, modifier ou supprimer un cours.
Gestion des actualités de l’application Myu
— L’administrateur peut consulter, ajouter, modifier ou supprimer une actualité.
Les besoins fonctionnels de l’étudiant :
Authentification à l’application Myu
— Le système doit permettre à l’étudiant de s’authentifier, tout en gardant ses données
sécurisées.
Gestion des profils Myu
— Le système doit permettre à l’étudiant de consulter son profil et modifier ses para-
mètres.
— Le système doit permettre à l’étudiant de modifier son mot de passe en cas d’oubli.
Consultation de l’emploi du temps
— Le système doit permettre à l’étudiant de consulter et télécharger son emploi du temps
en format PDF.
Consultation des enseignants
— Le système doit permettre à l’étudiant de consulter la liste de ses enseignants.
CHAPITRE 2. SPRINT 0 : PLANIFICATION ET ARCHITECTURE
27
Consultation des épreuves
— Le système doit permettre à l’étudiant de consulter et télécharger son planning d’exa-
mens.
— Le système doit permettre à l’étudiant de consulter et télécharger ses convocations
d’examens.
Consultation des absences
— Le système doit permettre à l’étudiant de consulter et télécharger la liste des absences.
Consultation des cours en ligne
— Le système doit permettre à l’étudiant de consulter et télécharger ses cours.
Gestion des services Myu
— Le système doit permettre à l’é