Esprit

École Supérieure Privée
d’Ingénierie et de Technologie
Rapport de stage ingénieur
Mention : Informatique
Conception et Réalisation d’une Plateforme

Web pour la Gestion Interactive des
Formations en E-learning
Préparé par
Ameni HAJRI
Réalisé au sein de la Société Nationale des Télécommunications « Tunisie Telecom »
Encadrant professionnel : Mme Ahlem Aissa
Année Universitaire : 2022-2023

École Supérieure Privée
d’Ingénierie et de Technologie
Rapport de stage ingénieur
Mention : Informatique
Conception et Réalisation d’une Plateforme

Web pour la Gestion Interactive des
Formations en E-learning
Par
Ameni HAJRI
Réalisé au sein de la Société Nationale des Télécommunications « Tunisie Telecom »
Autorisation de dépôt du rapport de stage ingénieur :
Encadrant professionnel :
Le :
Signature :
Remerciements
Tout d’abord, je remercie Allah le tout puissant de m’avoir donné le courage et la

patience nécessaire à mener ce travail à son terme.
Je tiens à remercier tout particulièrement mon encadrante professionnelle

Mme. Ahlem Aissa, pour l’aide qu’elle m’a apportée, pour sa patience et son encoura-
gement. Son œil critique m’a été très précieux pour structurer le travail et pour améliorer
la qualité des différentes sections.
Je remercie également tout particulièrement et à temoigner toute ma reconnaissance à

mes enseignants à Esprit pour la qualité de leurs formations et leurs remarques construc-
tives pour mener ce travail dans les meilleures conditions.
Pour finir, je souhaite remercier toute personne ayant contribuée de prés ou de loin à
la réalisation de ce travail.
i
Table des matières
Remerciements i
Introduction Générale 1
1 Cadre général et méthodologie adoptée 2

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Présenation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . 2
1.1.2 Organigramme de Tunisie Telecom . . . . . . . . . . . . . . . . . . 3
1.1.3 Les missions de Tunisie Telecom . . . . . . . . . . . . . . . . . . . . 3
1.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Définition d’une méthode agile . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Analyse et Spécificiations des Besoins 8

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Pilotage du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Diagramme de cas d’utilisation globale . . . . . . . . . . . . . . . . 10
2.3.2 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3 Planification des Releases . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Architecture proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Présentation de Release 1 15
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Planification de Release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Sprint 1 :Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.1 Diagramme de cas d’utilisation «Authentification» . . . . . . . . . . 15
3.3.2 Description textuelle . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
ii
Table des matières Table des matières
3.4 Sprint 2 : Gestion des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . 18

3.4.1 Planification de sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.2 Diagramme de cas d’utilisation «Gestion des utilisateurs» . . . . . . 19
3.4.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5 Sprint 3 : Gestion des modules . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.2 Diagramme de cas d’utilisation «Gestion des modules» . . . . . . . 23
3.5.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6 Sprint 4 : Gestion des populations cibles . . . . . . . . . . . . . . . . . . . 32
3.6.2 Diagramme de cas d’utilisation «Gestion des populations cibles» . . 32
3.6.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.6.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.7 Sprint 5 : Gestion des formations . . . . . . . . . . . . . . . . . . . . . . . 40
3.7.2 Diagramme de cas d’utilisation «Gestion des formations» . . . . . . 41
3.7.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.7.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.7.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3 Sprint 1 :Inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.1 diagramme de cas d’utilisation «Inscription» . . . . . . . . . . . . . 50
4.3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4 Sprint 2 : Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.5.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.5.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
iii
Table des matières Table des matières
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3 Sprint 1 :Inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3.1 Diagramme de cas d’utilisation «Inscription» . . . . . . . . . . . . . 66
5.3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.4 Sprint 2 : Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.4.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.5.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.5.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6 Réalisation 75
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2 Technologie de développement . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2.1 Langage de modélisation . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2.2 Outil de développement . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2.3 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2.4 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2.5 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Conclusion Générale 81
Bibliographie 82
iv
Table des figures
1.1 Logo de la société Tunisie Telecom . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Organigramme de la société. . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Vue générale de Tunisie Telecom. . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Cycle de vie de la méthode SCRUM. . . . . . . . . . . . . . . . . . . . . . 6
2.1 Diagramme de cas d’utilisation. . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Tableau Backlog produit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Liste des releases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Logo React JS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Logo Node JS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6 Logo Express JS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.7 Logo MongoDb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.8 Architecture MERN stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 Diagramme de cas d’utilisation «S’authentifier». . . . . . . . . . . . . . . . 16

3.2 Diagramme de classe «S’authentifier». . . . . . . . . . . . . . . . . . . . . . 17
3.3 Diagramme de séquence «S’authentifier». . . . . . . . . . . . . . . . . . . . 17
3.4 Interface d’authentification. . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5 Diagramme de cas d’utilisation «Gestion des utilisateurs». . . . . . . . . . 19
3.6 Diagramme de classe «Gestion des utilisateurs». . . . . . . . . . . . . . . . 20
3.7 Diagramme de séquence «Afficher la liste des utilisateurs». . . . . . . . . . 21
3.8 Diagramme de séquence «Supprimer un utilisateur». . . . . . . . . . . . . . 21
3.9 Interface de la liste des formateurs. . . . . . . . . . . . . . . . . . . . . . . 22
3.10 Interface de la liste des agents. . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.11 Diagramme de cas d’utilisation «Gestion des modules». . . . . . . . . . . . 23
3.12 Diagramme de classes «Gestion des modules». . . . . . . . . . . . . . . . . 26
3.13 Diagramme de séquence «Afficher un module». . . . . . . . . . . . . . . . . 27
3.14 Diagramme de séquence «Ajouter un module». . . . . . . . . . . . . . . . . 27
3.15 Diagramme de séquence «Modifier un module». . . . . . . . . . . . . . . . 28
3.16 Diagramme de séquence «Supprimer un module». . . . . . . . . . . . . . . 28
3.17 Diagramme de séquence «Chercher un module». . . . . . . . . . . . . . . . 29
3.18 Interface de la liste des modules. . . . . . . . . . . . . . . . . . . . . . . . . 29
3.19 Interface d’ajout d’un module. . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.20 Interface de modification d’un module. . . . . . . . . . . . . . . . . . . . . 30
3.21 Interface de recherche d’un module. . . . . . . . . . . . . . . . . . . . . . . 31
3.22 Interface de suppression d’un module. . . . . . . . . . . . . . . . . . . . . . 31
3.23 Diagramme de cas d’utilisation «Gestion des populations cibles». . . . . . . 32
3.24 Diagramme de classes «Gestion des popualtions cibles». . . . . . . . . . . . 35
3.25 Diagramme de séquence «Afficher une popualtion cible». . . . . . . . . . . 35
v
Table des figures Table des figures
3.26 Diagramme de séquence «Ajouter une population cible». . . . . . . . . . . 36

3.27 Diagramme de séquence «Modifier une population cible». . . . . . . . . . . 36
3.28 Diagramme de séquence «Supprimer une population cible». . . . . . . . . . 37
3.29 Diagramme de séquence «Chercher une population cible». . . . . . . . . . . 37
3.30 Interface de la liste des populations cibles. . . . . . . . . . . . . . . . . . . 38
3.31 Interface d’ajout d’une population cible. . . . . . . . . . . . . . . . . . . . 38
3.32 Interface de modification d’une population cible. . . . . . . . . . . . . . . . 39
3.33 Interface de recherche d’une population cible. . . . . . . . . . . . . . . . . 39
3.34 Interface de suppression d’une population cible. . . . . . . . . . . . . . . . 40
3.35 Diagramme de cas d’utilisation «Gestion des formations». . . . . . . . . . . 41
3.36 Diagramme de classes «Gestion des formations». . . . . . . . . . . . . . . . 43
3.37 Diagramme de séquence «Afficher une formation». . . . . . . . . . . . . . . 44
3.38 Diagramme de séquence «Ajouter une formation». . . . . . . . . . . . . . . 44
3.39 Diagramme de séquence «Modifier une formation». . . . . . . . . . . . . . 45
3.40 Diagramme de séquence «Supprimer une formation». . . . . . . . . . . . . 45
3.41 Diagramme de séquence «Voir détails formation». . . . . . . . . . . . . . . 46
3.42 Interface de la liste des formations. . . . . . . . . . . . . . . . . . . . . . . 46
3.43 Interface d’ajout d’une formation. . . . . . . . . . . . . . . . . . . . . . . . 47
3.44 Interface d’ajout d’une formation. . . . . . . . . . . . . . . . . . . . . . . . 47
3.45 Interface de modification d’une formation. . . . . . . . . . . . . . . . . . . 48
3.46 Interface pour voir les détails d’une formation. . . . . . . . . . . . . . . . . 48
3.47 Interface de suppression d’une formation. . . . . . . . . . . . . . . . . . . . 49
4.1 Diagramme de cas d’utilisation «Inscription». . . . . . . . . . . . . . . . . 51

4.2 Diagramme de classe «S’inscrire». . . . . . . . . . . . . . . . . . . . . . . . 52
4.3 Diagramme de séquence «S’inscrire». . . . . . . . . . . . . . . . . . . . . . 52
4.4 Interface d’inscription. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.5 Interface de vérification d’email. . . . . . . . . . . . . . . . . . . . . . . . . 53
4.6 Interface de mot de passe oublié. . . . . . . . . . . . . . . . . . . . . . . . 54
4.7 Interface de réinitialisation de mot de passe. . . . . . . . . . . . . . . . . . 54
4.11 Interface de connexion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.13 Diagramme de classe «Gestion des formations». . . . . . . . . . . . . . . . 59
4.14 Diagramme de séquence «Afficher un formulaire». . . . . . . . . . . . . . . 60
4.15 Diagramme de séquence «Accepter/Refuser une formation». . . . . . . . . 60
4.16 Diagramme de séquence «Modifier une formation». . . . . . . . . . . . . . 61
4.18 Interface d’acceptation d’une formation. . . . . . . . . . . . . . . . . . . . 62
4.19 Interface de visiconférence 1. . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.1 Diagramme de cas d’utilisation «Inscription». . . . . . . . . . . . . . . . . 66

5.2 Diagramme de classe «S’inscrire». . . . . . . . . . . . . . . . . . . . . . . . 67
5.3 Diagramme de séquence «S’inscrire». . . . . . . . . . . . . . . . . . . . . . 67
vi
Table des figures Table des figures
5.4 Interface d’inscription. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.5 Interface de vérification d’email. . . . . . . . . . . . . . . . . . . . . . . . . 68
5.6 Interface de mot de passe oublié. . . . . . . . . . . . . . . . . . . . . . . . 69
5.7 Interface de réinitialisation de mot de passe. . . . . . . . . . . . . . . . . . 69
5.11 Interface de connexion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.13 Diagramme de classe «Gestion des formations». . . . . . . . . . . . . . . . 73
5.14 Diagramme de séquence «Afficher une formation». . . . . . . . . . . . . . . 74
6.1 Logo UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.2 Logo StarUML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.3 Ordinateur portable utilisé. . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.4 Environnement matériel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.5 Visual Studio Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.6 Logo Postman. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.7 Logo GitHub. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.8 Logo React JS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.9 Logo Node JS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.10 Logo Express JS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.11 Logo MongoDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.12 L’architecture MERN stack. . . . . . . . . . . . . . . . . . . . . . . . . . . 80
vii
Liste des tableaux
2.1 Tableau des acteurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Tableau de Release 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Description textuelle de cas d’utilisation «S’authentifier». . . . . . . . . . . 16
3.3 Sprint 3 : Backlog gestion des utilisateurs. . . . . . . . . . . . . . . . . . . 18
3.4 Description textuelle de cas d’utilisation «Afficher la liste des utilisateurs». 19
3.5 Description textuelle de cas d’utilisation «Supprimer un utilisateur». . . . . 19
3.6 Sprint 3 : Backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.7 Description textuelle de cas d’utilisation «Afficher un module». . . . . . . . 24
3.8 Description textuelle de cas d’utilisation «Ajouter un module». . . . . . . . 24
3.9 Description textuelle de cas d’utilisation «Modifier un module». . . . . . . 25
3.10 Description textuelle de cas d’utilisation «Chercher un module». . . . . . . 25
3.11 Description textuelle de cas d’utilisation «Supprimer un module». . . . . . 26
3.12 Sprint 4 : Backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.13 Description textuelle de cas d’utilisation «Afficher une population cible». . 33
3.14 Description textuelle de cas d’utilisation «Ajouter une population cible». . 33
3.15 Description textuelle de cas d’utilisation «Modifier une popualtion cible». . 34
3.16 Description textuelle de cas d’utilisation «Supprimer une popualtion cible». 34
3.17 Description textuelle de cas d’utilisation «Chercher une popualtion cible ». 34
3.18 Sprint 5 : Backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.19 Description textuelle de cas d’utilisation «Afficher une formation». . . . . . 41
3.20 Description textuelle de cas d’utilisation «Ajouter une formation». . . . . . 42
3.21 Description textuelle de cas d’utilisation «Modifier une formation». . . . . 42
3.22 Description textuelle de cas d’utilisation «Supprimer une formation». . . . 43
3.23 Description textuelle de cas d’utilisation «Voir détails formation». . . . . . 43

4.2 Description textuelle de cas d’utilisation «S’inscrire». . . . . . . . . . . . . 51
4.4 Sprint 3 : Backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.5 Description textuelle de cas d’utilisation «Afficher la liste des formations». 58
4.6 Description textuelle de cas d’utilisation «Accepter/Refuser une formation». 58
4.7 Description textuelle de cas d’utilisation «Modifier une formation». . . . . 59

5.2 Description textuelle de cas d’utilisation «S’inscrire». . . . . . . . . . . . . 66
5.4 Sprint 3 : Backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.5 Description textuelle de cas d’utilisation «Afficher la liste des formations». 73
viii
Introduction Générale
Le monde connaît actuellement des avancées technologiques importantes grâce à l’in-

formatique qui se présente dans tous les recherches et les différentes spécialités tels que
la gestion des formations qui se profile une priorité primordiale pour les sociétés .
En fait, toutes les sociétés donnent une importance à mettre des solutions adaptatives
pour répondre aux besoins de ses acteurs.
Les agents, qui sont les acteurs clés du succès d’une société, cherchent continuellement à
perfectionner leurs compétences pour rester compétitifs sur le marché en constante mu-
tation.
Au même temps, les administrateurs, en tant que gardiens de la stratégie d’entreprise,
s’efforcent de fournir des opportunités de développement qui alignent les objectifs orga-
nisationnels sur les aspirations individuelles.
Et finalement, les formateurs, en tant que facilitateurs du savoir, portent la responsabilité
de transmettre des connaissances pertinentes et actualisées aux agents.
Au cœur de cet écosystème, émerge une application de gestion de formations qui vise
à harmoniser les besoins de ces trois rôles essentiels.
En permettant aux administrateurs de proposer des formations aux formateurs, qui à leur
tour, évaluent et transmettent ces formations aux agents, l’application devient le cataly-
seur d’un processus continu d’apprentissage et d’amélioration.
La synergie entre ces acteurs transforme cette application en une plateforme holistique où
les connaissances se transmettent de manière fluide, et où les compétences sont constam-
ment renforcées pour une performance optimale.
Le présent rapport est organisé en cinque chapitres comme suit :
Dans un premier chapitre, nous présonterons le cadre général du projet ainsi que la
problématique,la solution proposée et la méthodologie adéquate.
Le deuxième chapitre exposera la phase de spécification des besoins qui contient le dia-
gramme de cas d’utilisation, ensuite nous attaquerons une conception détaillée et architec-
turale ainsi que les étapes suivies à fin que le système soit adaptable et bien fonctionnel.
Quant’aux troisième ,le quatrième et le cinquième chapitres seront consacrés pour les tris
releases qu’on va les détaillés plus tard pour bien structurer nos diagrammes de classes et
nos diagrammes de séquences, mais aussi mettre des captures d’écran de chaque interface
de notre plateforme web.
Finalement, le dernier chapitre sera consacré pour la réalisation dont on va présenter
les environnements matériels et logiciels et les technologies utilisées.
1
Chapitre 1
Cadre général et méthodologie

adoptée
1.1 Introduction
L’étude de ce projet est une démarche stratégique qui va nous permettre d’avoir une
vision globale de ce dernier, visant ainsi à organiser le bon déroulement du projet.
Cette étude sera donc l’objet du premier chapitre qui sera consacré en premier lieu à
la présentation de l’organisme d’accueil en parlant de son importance en Tunisie, ses
missions, et sa structure organisationnel. En deuxième lieu, nous traiterons l’étude de
l’existant en analysant ses critiques et en proposant notre solution.
Et finalement, nous allons présenter la méthodologie adoptée et nous expliquerons notre
choix de langage de modélisation.
1.1.1 Présenation de l’organisme d’accueil

Tunisie Telecom est le nom commercial du premier opérateur téléphonique en Tunisie.
Son capital est de 875 millions d’euros et son chiffre d’affaires en 2004 était de 750 millions
d’euros.
Cette société ayant le statut de société anonyme est chargée d’assurer les communications,
l’exploitation et la maintenance du réseau de télécommunications ainsi que la transmission
des données en Tunisie. C’est le leader du marché des télécommunications en Tunisie. Elle
a été créée par la loi n° 36 du 17 avril 1995 et mise en place le 1er janvier 1996. Elle a
un caractère industriel et commercial ainsi qu’elle est placée sous la tutelle du Ministère
des Technologies de la Communication. Elle a fait l’objet d’une privatisation partielle en
juillet 2006 avec l’entrée dans son capital, de l’émirat TeCom-DIG. Depuis 5 ans, elle
a fait l’objet d’une mise à niveau visant à améliorer les services et les profils. Tunisie
Telecom est composé de 24 directions régionales des télécommunications correspondant
aux 24 gouvernorats en Tunisie.
2
Chapitre 1. Cadre général et méthodologie adoptée 1.1. Introduction
Figure 1.1 – Logo de la société Tunisie Telecom
1.1.2 Organigramme de Tunisie Telecom

La structure organisationnelle de l’entreprise revêt un caractère fonctionnel classique.
Elle présente un découpage horizontal des responsabilités qui permet de respecter les
compétences et le savoir-faire spécifique. La ci-dessous illustre l’organigramme de Tunisie
Telecom.
Figure 1.2 – Organigramme de la société.
1.1.3 Les missions de Tunisie Telecom

Depuis sa création, Tunisie Telecom œuvre à assurer la télécommunication en Tunisie,
elle a connue une mise à niveau qui vise à améliorer les services et maximiser les profits
dont ses missions sont :
– L’installation, l’entretien et l’exploitation des réseaux publics de télécommunica-
tion.
– La contribution à l’effort national d’enseignement supérieur en matière de télécom-
munications.
– L’offre de tous les services publics ou privés de télécommunication correspondants
aux divers besoins à caractères social et économique.
3
Chapitre 1. Cadre général et méthodologie adoptée 1.2. Etude de l’existant
– La contribution à l’effort national d’enseignement supérieur en matière de télécom-

munications.
– La promotion de la coopération à tous les niveaux dans le domaine des télécom-
munications.
Figure 1.3 – Vue générale de Tunisie Telecom.
1.2 Etude de l’existant

L’étude de l’existant permet de comprendre le fonctionnement du système existant et
de définir ses limites afin de proposer les solutions adoptées.
1.2.1 Analyse de l’existant

Au premier volet, nous commençons par l’analyse de l’existant, qui permet de déter-
miner les points faibles du système actuel pour pouvoir déterminer les besoins du client.
Actuellement, la société «Tunisie Telecom » ne dispose d’aucun système structuré de
gestion des formations en e-learning qui soulève des défis significatifs en termes de dé-
veloppement professionnel, suivi des compétences et d’efficacité opérationnelle. En fait,
ce problème peut entraîner des limitations qui bloquent la croissance de la société et
l’épanouissement de ses employés.
1.2.2 Critique de l’existant

L’étude de l’existant nous a permis de dégager plusieurs lacunes, d’où on peut constater
que le processus de gestion des formations en ligne est absent et ça peut avoir un impact
négatif sur la croissance et la compétivité de Tunisie Telecom ,on peut citer quelques
lacunes existantes :
•Limitation des opportunités d’apprentissage.
•Manque de suivi personnalisé.
•désengagement des employés.
1.2.3 Solution proposée

Pour éviter ces critiques, il est nécessaire d’identifier et mettre en œuvre une solution
adéquate qui va mettre fin aux défis actuels et à l’absence d’un système structuré de
gestion des formations en ligne, nous proposons la mise en place d’une plateforme web
innovante basée sur le MERN stack (MongoDB, Express js, React js, Node js).
Cette solution permet de créer un environnement collaboratif favorable et organisé pour
4
Chapitre 1. Cadre général et méthodologie adoptée1.3. Méthodologie de développement
la gestion des formations au sein de Tunisie Telecom, en réunissant les intervenants qui
sont les administrateurs, les formateurs et les agents autour d’une plateforme centralisée
et conviviale.
1.3 Méthodologie de développement

Le choix de la méthode de travail est une étape essentielle du travail pendant toute la
durée de le stage. Parmi ces méthodes, nous citons deux grandes familles du processus de
développement logiciel : les méthodes classiques (cycle en V, cascades) et les méthodes
agiles (SCRUM, Crystal, XP, etc.). Dans le paragraphe suivant, nous détaillerons les
différences entre les deux méthodes.
1.3.1 Définition d’une méthode agile

Une méthode agile est une approche itérative et incrémentale, qui est menée dans un
esprit collaboratif avec juste ce qu’il faut de formalisme. Elle génère de haute qualité tout
en prenant en compte l’évolution des besoins des clients.[1]
Elles permettent bien évidement d’impliquer l’ensemble des collaborateurs ainsi que le
client dans le développement du projet. Elle prévient donc mieux de répondre aux at-
tentes du client dans temps limité grâce à son implication tout en faisant monter les
collaborateurs en compétences.
On peut citer quelques exemples des méthodes de développement Agile :
•XP :Extreme Programming
•SCRUM
•PU : Processus Unifié
•Lean
•Crystal
1.3.2 SCRUM
Définition
Parmi les méthodes agiles, basées sur le Manifeste Agile rédigé en 2001 par des experts
en développement d’application, la méthode Scrum est la plus utilisée elle repose sur une
gestion de projet collaborative et un cycle de développement :[2]
•itératif (répété plusieurs fois, de l’idée initiale à une version de plus en plus
aboutie),
•incrémental (progressif, tâches après tâches).
•adaptatif.
Ainsi, les 3 piliers Scrum sont :
•La transparence, dans la communication et le suivi.
•L’inspection régulière pour détecter les écarts entre les objectifs et le travail
réalisé.
•L’adaptation, pour un ajustement en permanence face aux contraintes.[3]
Avantages
Le point fort de la méthode SCRUM c’est qu’elle dépends des cycles de développements
adaptés en permanence, courts, sans jamais perdre de vue l’expérience utilisateur «UX».
5
Chapitre 1. Cadre général et méthodologie adoptée1.3. Méthodologie de développement
Parmi ses avantages on cite :

•Une gestion plus intelligente et souple du travail, qui améliore l’efficacité des
équipes.
•Une meilleure visibilité sur l’évolution du projet.
•La communication interne renforcée, d’ou une meilleure cohésion d’équipe.
•Un gain au niveau du temps ainsi qu’une meilleure réactivité grâce aux réunions
fréquentes. D’après ces bénifices nous nous sommes interessés par la méthode
SCRUM dont on a pu travailler avec.
Figure 1.4 – Cycle de vie de la méthode SCRUM.
Les rôles
Les rôles d’une équipe Scrum se définissent en 3 parties :
•Le Product Owner «Le propriétaire du produit» :
Il a la vision du produit et il s’assure de la bonne traduction des attentes du client
à l’équipe projet, en définissant toutes les spécifications fonctionnelles et les prio-
rités.
•Le SCRUM Master «Le maître de mêlée» :
Il est le chef d’orchestre, le coordinateur de l’équipe agile, dont il fait partie inté-
grante.
•Le SCRUM Team «L’équipe SCRUM» :
Elle est composé par des développeurs, architectes, designers, testeurs, sa respon-
sabilité est de livrer à la fin de chaque sprint les éléments qu’ont été marqués.
Les réunions
Il existe quatre réunions qui définissent la méthode SCRUM
•Le sprint meeting planning «planification du sprint» :
C’est une réunion qui se déroule le 1er jour du sprint. Les participants, qui vont
faire en sorte d’échanger et de se mettre d’accord sur les fonctionnalités qu’ils s’en-
gagent à livrer à la fin du sprint.
•Le daily Scrum «mêlée quotidienne» :
C’est une réunion très rapide qui aura lieu chaque jour du sprint. Chaque partici-
pant prend la parole afin de communiquer au reste de l’équipe et cette réunion est
6
Chapitre 1. Cadre général et méthodologie adoptée 1.4. Conclusion
limitée par 15 minutes.

•Le Sprint review «revue de sprint» :
C’est une réunion où l’équipe SCRUM présente aux intervenants les différents li-
vrables terminés.Il s’agit d’une démonstration en conditions réelles afin de s’assurer
que le produit réponde aux besoins exprimés par le client.
•Le sprint retrospective :
C’est la réunion qui vient clôturer le sprint. C’est une réunion limitée à 1 heure et
30 minutes.
Les user stories

Le product owner définit toutes les demandes fonctionnelles, basées sur les attentes
d’un ou plusieurs types d’utilisateurs, pour ajouter de la valeur au produit.
Le Artefacts
Un artefact consiste à définir les outils spécifiques au SCRUM management.
•Le Backlog du Produit :
C’est une liste de fonctionnalités à réaliser. Généralement, cette liste de fonction-
nalités est classée par ordre d’importance.
•Le Backlog du Sprint :
Au début du sprint, un but est décidé. Pour atteindre cet objectif, l’équipe choisit
quels éléments du carnet de produit seront réalisés. Chaque développeur s’engage
sur un temps de travail pour chaque tâche établie.
1.4 Conclusion
Dans ce premier chapitre, nous avons présenté le cadre général du projet ainsi que
l’organisme d’accueil, par la suite on a présenté la problématique, les critiques et la solution
proposée ,ainsi que la méthodologie adéquate pour notre projet.
Une étude d’analyse et spécification des besoins sera donc le sujet de notre prochain
chapitre.
7
Chapitre 2
Analyse et Spécificiations des

Besoins
2.1 Introduction
L’analyse et la spécification des besoins est une étape primordiale pour procéder à la
création de notre projet.
Ce chapitre sera consacré à l’identification des acteurs de notre système, ainsi que
les besoins fonctionnels et non fonctionnels. Ensuite, nous montrerons notre «Product
Backlog». En fin, nous décrirons l’architecture adoptée pour le développement de notre
projet.
2.2 Identification des besoins

Dans cette partie nous présenterons les différents acteurs de notre application ainsi
que leurs fonctionnalités.
2.2.1 Identification des acteurs

Les acteurs d’un système sont les entités externes à ce système qui interagissent avec
lui. Les acteurs sont donc à l’extérieur du système et dialoguent avec lui.[4]
Dans cette application nous avons recours à trois acteurs principaux présentés dans ce
tableau ci-dessous.
8
Chapitre 2. Analyse et Spécificiations des Besoins 2.2. Identification des besoins
Acteurs Rôle
Authentification
Gestion des utilisateurs
Administrateur Gestion des formations
Gestion des modules
Gestion des populations cibles
Authentification
Formateur
Gestion des formations
Authentification
Agent
Gestion des formations
Table 2.1 – Tableau des acteurs.
2.2.2 Les besoins fonctionnels

Les besoins fonctionnels expriment une action que le système doit effectuer en réponse
à une demande. Dans cette section nous allons aussi classer les besoins par acteur :
•Authentification : Chaque utilisateur (Administrateur ,formateur ou agent) dis-
pose d’une matricule qui est un clé primaire ,d’un email et d’un mot de passe
qui leurs permettent d’accéder à la plateforme, afin d’autoriser l’accès dans cette
dérniere en toute sécurité.
Côté Administrateur
•Gestion des utilisateurs : l’administrateur a le droit de voir, chercher, ou de sup-
primer un utilisateur que ce soit un formateur ou bien un agent.
•Gestion des formations : l’administrateur a l’accès de voir, ajouter, modifier, cher-
cher, ou de supprimer une formation.
•Gestion des modules : l’administrateur a le droit de voir, ajouter, modifier,chercher
ou de supprimer un module spécifique (secourisme au travails,le dépouillement des
offres, etc)
•Gestion des populations cibles : l’administrateur a le droit de voir, ajouter ,mo-
difier, chercher et de supprimer une popualtion cible.
Côté Formateur
•Gestion des formations : le formateur reçoit la formation qui le correspond ,il
peut l’accepter ou la refuser , s’il l’accepte il peut ajouter une description et un
lien de visioconférence.
Côté Agent
•Gestion des formations : l’agent reçoit les formations qui correspondent à la
population cible qui lui appartient ,il peut rejoindre la formation qu’il veut.
9
Chapitre 2. Analyse et Spécificiations des Besoins 2.3. Pilotage du projet
2.2.3 Les besoins non fonctionnels

Les besoins non fonctionnels du système sont les exigences implicites auxquels le sys-
tème doit répondre, ils peuvent être des besoins ou des contraintes. La majorité des besoins
non-fonctionnels qui doivent être présents sont les suivants :
1. La sécurité : L’application doit garantir la sécurité des données et en protégeant
l’accés à cette dérniere.
2. La rapidité : L’application doit offrir une interface rapide pour que l’utilisateur
intéragit avec un temps d’exécution optimal.
3. La fiabilité : l’application doit permettre le stockage des informations des utilisa-
teurs et des formations, ainsi qu’assurer une bonne gestion des erreurs
4. La disponibilité : Cette application doit être fonctionnelle au besoin.
2.3 Pilotage du projet

Dans cette partie nous montrerons le diagramme de cas d’utilisation permettant d’ex-
primer les besoins des utilisateurs du système ainsi que le tableau du Backlog produit.
2.3.1 Diagramme de cas d’utilisation globale

Le cas d’utilisation est consacré pour décrire le comportement d’une application du
point de vue de l’utilisateur. Selon les besoins de notre système, nous pouvons présenter
trois types d’acteurs qui sont l’administrateur, le formateur et l’agent.
La figure ci-dessous représente les différentes fonctionnalités de notre système à travers le
diagramme de cas d’uilisation.
10
Figure 2.1 – Diagramme de cas d’utilisation.
2.3.2 Backlog produit

Le Backlog produit est l’un des éléments fondamentaux de la méthodologie Scrum. Il
met en vigueur la liste des tâches priorisées qui constituent le produit attendu.
Le Backlog produit est constitué par :
•ID : C’est un nombre unique et auto-incrémenté pour chaque «user story».
•Feature : C’est une description de la fonctionnalité souhaitée par le client.
•Range : Il est assigné à chaque user story pour indiquer l’ordre de l’implémenta-
tion.
•Priority : Le product Owner classe les user stories par ordre de priorité dans le
backlog produit en discutant avec le client pour savoir ses souhaits.
•User story : Une fonctionnalité court (entre 2 et 10 mots), décrit la fonctionnalité
attendue par le client. Par la suite le nom doit être suffisamment clair pour que les
membres de l’équipe et le Product Owner comprennent les fonctions nécessaire.
11
Figure 2.2 – Tableau Backlog produit.
2.3.3 Planification des Releases

La réunion de planification des sprints est une étape primordiale dans SCRUM.
Un release est une série de sprints qui se termine quand les incréments successifs consti-
tuent un produit présentant suffisamment des valeurs à ses utilisateurs.
Au niveau de notre projet, on a décidée de découper ce dérnier en trois releases,le premier
est consacré pour l’administrateur quant’au deuxième il est consacré pour le formateur et
le dernier est déstiné à l’agent.
12
Chapitre 2. Analyse et Spécificiations des Besoins 2.4. Architecture proposée
Figure 2.3 – Liste des releases.
2.4 Architecture proposée

Pour satisfaire nos besoins au niveau de notre projet, on a opté pour le MERN stack
(MongoDB, Express.js, React.js, Node.js) qui adopte l’architecture 3-Tiers en effet elle est
une combinaison de composants frontend et backend qui travaillent ensemble pour créer
une application web. Donc le modèle de cette architecture se compose par :
— Frontend (Côté client) :

•React : La bibliothèque JavaScript pour construire des interfaces utilisateur
interactives et réutilisables, grâce à son approche basée sur les composants et
son Virtual DOM pour des performances optimisées.
Figure 2.4 – Logo React JS.
— Backend (Côté serveur) :

•Node.js : L’environnement d’exécution côté serveur Node.js est un environne-
ment d’exécution permet une programmation non bloquante, efficace pour les
applications à forte concurrence et les tâches en temps réel.
Figure 2.5 – Logo Node JS.
13
Chapitre 2. Analyse et Spécificiations des Besoins 2.5. Conclusion
•Express.js : Le framework backend pour créer des routes, middleware et même

il permet la gestion des requêtes, accélérant ainsi le développement backend.
Figure 2.6 – Logo Express JS.
— Base de données :
•MongoDB : La base de données NoSQL flexible et évolutive qui stocke les
données sous forme de documents JSON, offrant une adaptabilité aux schémas
changeants et des performances de requêtes avancées.
Figure 2.7 – Logo MongoDb.
Et finalement l’architecture de notre application web se modélise par ce schéma :
Figure 2.8 – Architecture MERN stack.
2.5 Conclusion
Dans ce chapitre, nous avons élaborés les différentes fonctionnalités de notre système
et les acteurs y impliqués. Ensuite, nous avons définit le pilotage de notre application. Et
finalement, nous avons expliqué l’architecture utilisée pour la réalisation de notre projet.
14
Chapitre 3
Présentation de Release 1
3.1 Introduction
Au cours de ce chapitre, nous allons définir le premier release qui sera composée d’une
série des sprints consacrés à l’administrateur. Dans chaqu’un d’eux, nous allons élaboré
une étude fonctionnelle à travers les diagrammes de cas d’utilisation détaillés. Ensuite,
nous décrirons les diagrammes de séquences .Finalemenet nous montrerons les interfaces
réalisées.
3.2 Planification de Release 1

Au niveau de Release 1 nous allons indiqués 5 sprints qui sont :
Sprint Nom du sprint

Sprint 1 Authentification
Sprint 2 Gestion des utilisateurs
Sprint 3 Gestion des modules
Sprint 4 Gestion des populations cibles
Sprint 5 Gestion des formations
Table 3.1 – Tableau de Release 1.
3.3 Sprint 1 :Authentification

Nous allons commencer dans cette section d’introduire le développement du backlog
produit du sprint 1 qui a pour rôle de permettre à un administrateur de s’authentifier
afin qu’il accéde à l’interface admin qui lui correspond.
3.3.1 Diagramme de cas d’utilisation «Authentification»

Ce diagramme de cas d’utilisation montre que l’admin doit s’authentifier pour accéder
à l’application.
15
Chapitre 3. Présentation de Release 1 3.3. Sprint 1 :Authentification
Figure 3.1 – Diagramme de cas d’utilisation «S’authentifier».
3.3.2 Description textuelle

Le tableau ci-dessous décrit textuellement le cas d’utilisation «S’authentifier» de Sprint
1.
Cas d’utilisation S’authentifier

Acteur Administrateur
Précondition Administrateur veut se connecter
Postcondition Administrateur est connecté
1-Le système affiche l’interface de connexion.
2-L’admin remplit les champs par les
informations nécessaires et clique sur
Description du scénario principal
le bouton «Connexion»
3-Le système vérifie les informations
saisies et affiche l’interface suivante qui correspond à l’admin.
1- Si l’un des champs est vide ou invalide,
le système affiche un message d’erreur.
Exception
2-Si l’un des champs est incorrecte ,le système affiche
un message d’erreur.
Table 3.2 – Description textuelle de cas d’utilisation «S’authentifier».
3.3.3 Conception
Dans cette partie on va s’intéresser a présenter le passage de diagramme de cas d’uti-
lisation au diagramme de classe afin de présenter la vue statique ainsi que le diagramme
de séquence en tant que vue dynamique de notre premier sprint.
Vue statique : Diagramme de classe

Le diagramme de classe «S’authentifier» se traduit par les différentes éléments parti-
cipantes à la réalisation de ce dernier.
16
Chapitre 3. Présentation de Release 1 3.3. Sprint 1 :Authentification
Figure 3.2 – Diagramme de classe «S’authentifier».
Comme on a mentionner que l’architecture adoptée pour développer notre application

est l’architecture 3-Tiers c’est pourquoi on a mis en évidence les 3 couches au niveau de
la figure 3.2 ci-dessus.
•La couche «UI :Authentification» montre l’interface graphique qui a pour objectif
d’assurer le dialogue avec l’administrateur.
•La couche service nommé «C Authentification », elle permet la création des trai-
tements de l’application.
•Finissant par le couche accès aux données qui définit l’entité « Administrateur »,
elle s’occupe de l’accès aux données qui sont destinées à être conserver de manière
persistante dans de la base de données.
Vue dynamique : Diagramme de séquence

A travers le diagramme de séquence, nous allons décrire le scénario du même cas
d’utilisation.
Figure 3.3 – Diagramme de séquence «S’authentifier».
17
Chapitre 3. Présentation de Release 1 3.4. Sprint 2 : Gestion des utilisateurs
3.3.4 Réalisation
Pour y accéder à l’interface administrative, l’admin doit s’authentifier en remplissant
les champs nécessaires.
Figure 3.4 – Interface d’authentification.
3.4 Sprint 2 : Gestion des utilisateurs

A travers ce sprint, l’administrateur est capable de gérer la liste des formateurs et des
agents qui viennent de faire une inscription. Il peut voir les informations d’un utilisateur
et le supprimer.
3.4.1 Planification de sprint 2

Le tableau ci-dessous résume le Backlog du deuxième sprint.
ID Tâche Description
-L’administrateur est capable de voir la liste
1 Afficher la liste des utilisateurs
des utilisateurs(formateurs et agents).
2 Supprimer un utilisateur -L’administrateur peut supprimer un utilisateur.
Table 3.3 – Sprint 3 : Backlog gestion des utilisateurs.
18
3.4.2 Diagramme de cas d’utilisation «Gestion des utilisateurs»
Figure 3.5 – Diagramme de cas d’utilisation «Gestion des utilisateurs».

Nous avons illustré dans ces tableaux ci-dessous les descriptions textuelles concernant
le scénario du cas d’utilisation sprint 2 « Gestion des utilisateurs » :
Description textuelle du cas d’utilisation « Afficher la liste des utilisateurs »
Cas d’utilisation Afficher la liste des utilisateurs

Précondition Une authentification préalable
Postcondition Interface administrative est affichée
1–L’administrateur demande l’affichage de l’interface
des agents ou des formateurs.
2-Le système récupère les données.
3-Le système affiche la liste des agents ou formateurs.
1-Le système affiche un message de type
Exception
« Aucune donnée n’est disponible ».
Table 3.4 – Description textuelle de cas d’utilisation «Afficher la liste des utilisateurs».
Description textuelle du cas d’utilisation « Supprimer un utilisateur »
Cas d’utilisation Supprimer un utilisateur

Une authentification préalable
Précondition
L’utilisateur existe
Postcondition Un utilisateur est supprimé
1-L’admin choisit un utilisateur à supprimer.
2-Le système supprime l’utilisateur choisi par l’admin.
Table 3.5 – Description textuelle de cas d’utilisation «Supprimer un utilisateur».
19
3.4.4 Conception
Dans cette partie nous allons présenté le passage de diagramme de cas d’utilisation à
un diagramme de classes afin de présenter la vue statique et la vue dynamique de notre
deuxième sprint.
Vue Statique : Diagramme de classe

Les trois couches de notre architecture 3-Tiers se manifestent comme suit selon le
diagramme de classe dans la figure ci-dessous.
Figure 3.6 – Diagramme de classe «Gestion des utilisateurs».
Vue Dynamique : Diagramme de séquence

Dans cette section, nous allons exposer les diagrammes de séquence qui concerne l’en-
semble des fonctionnalités appliquées au niveau de la gestion des utilisateurs.
20
•Diagramme de séquence «Afficher la liste des utilisateurs»
Figure 3.7 – Diagramme de séquence «Afficher la liste des utilisateurs».
•Diagramme de séquence «Supprimer un utilisateur»
Figure 3.8 – Diagramme de séquence «Supprimer un utilisateur».
3.4.5 Réalisation
Les interfaces suivantes exposent la liste des formateurs et des agents. A travers elles,
l’administrateur est capable de consulter la liste des utilisateurs et les supprimer.
21
Chapitre 3. Présentation de Release 1 3.5. Sprint 3 : Gestion des modules
Interface de la liste des formateurs
Figure 3.9 – Interface de la liste des formateurs.
Interface de la liste des formateurs
Figure 3.10 – Interface de la liste des agents.
3.5 Sprint 3 : Gestion des modules

A travers ce sprint, l’administrateur est capable de gérer les modules, c’est à dire,il
peut ajouter, modifier,chercher et supprimer un module.
22

Le tableau ci-dessous résume le Backlog du troisième sprint.
1 Afficher la liste des modules -L’admin est capable de voir la liste des modules
2 Ajouter un module -L’admin peut ajouter un module
3 Modifier un module -L’admin est capable de modifier un module
4 Supprimer un module -L’admin peut supprimer un module
5 chercher un module -L’admin peut chercher un module
Table 3.6 – Sprint 3 : Backlog.
3.5.2 Diagramme de cas d’utilisation «Gestion des modules»

Ce diagramme de cas d’utilisation ci-dessous montre les tâches de la gestion des mo-
dules faites par l’admin.
Figure 3.11 – Diagramme de cas d’utilisation «Gestion des modules».

le scénario du cas d’utilisation sprint 3 « Gestion des modules » :
23
Description textuelle du cas d’utilisation « Afficher la liste des modules »
Cas d’utilisation Afficher un module

Postcondition La liste des modules est affichée sur l’écran
1-L’admin demande l’affichage de l’interface des
modules.
3-Le système affiche la liste des modules.
Exception
« Aucune donnée n’est disponible».
Table 3.7 – Description textuelle de cas d’utilisation «Afficher un module».
Description textuelle du cas d’utilisation « Ajouter un module »
Cas d’utilisation Ajouter un module

Postcondition Un module est ajouté
1-L’admin demande l’affichage de l’interface d’ajout
d’un module.
2-Le système prend en charge de la demande et affiche
l’interface souhaitée.
3-L’admin remplit le formulaire d’ajout et clique sur
le bouton« Ajouter».
4-Le système vérifie le remplissage des champs et
ajoute le module.
1-Si l’un des champs est vide ou invalide, le système
Exception
affiche un message d’erreur.
Table 3.8 – Description textuelle de cas d’utilisation «Ajouter un module».
24
Description textuelle du cas d’utilisation « Modifier un module »
Cas d’utilisation Modifier un module

Précondition
Le module existe
Postcondition Un module est modifié
1-L’admin choisit un module à modifier.
2-Le système affiche le module à modifier.
3-L’admin modifie les informations choisis et clique sur
le bouton «Modifier».
4-Le système vérifie les données saisies et
modifie le module.
1-Si l’un des champs est vide ou invalide, le système
Exception
Table 3.9 – Description textuelle de cas d’utilisation «Modifier un module».
Description textuelle du cas d’utilisation « Chercher un module »
Cas d’utilisation Chercher un module

Précondition
Le module existe
Postcondition Un module est trouvé
1-L’admin tape le nom de module voulu.
2-Le système afficher le module choisi.
1-Si l’un des module cherché n’est pas trouvé, le système
Exception
n’affiche aucun module.
Table 3.10 – Description textuelle de cas d’utilisation «Chercher un module».
25
Description textuelle du cas d’utilisation « Supprimer un module »
Cas d’utilisation Supprimer un module

Précondition
Le module existe
Postcondition Un module est supprimé
1-L’admin choisit un module à supprimer.
2-Le système supprime le module choisi.
Table 3.11 – Description textuelle de cas d’utilisation «Supprimer un module».
3.5.4 Conception
troisième sprint.

Les trois couches de notre architecture 3-Tiers se définissent comme suit selon le dia-
gramme de classe dans la figure ci-dessous.
Figure 3.12 – Diagramme de classes «Gestion des modules».

semble des fonctionnalités appliqués au niveau de la gestion des modules.
•Diagramme de séquence «Afficher un module»
26
Figure 3.13 – Diagramme de séquence «Afficher un module».
•Diagramme de séquence «Ajouter un module»
Figure 3.14 – Diagramme de séquence «Ajouter un module».
•Diagramme de séquence «Modifier un module»
27
Figure 3.15 – Diagramme de séquence «Modifier un module».
•Diagramme de séquence «Supprimer un module»
Figure 3.16 – Diagramme de séquence «Supprimer un module».
28
•Diagramme de séquence «Chercher un module»
Figure 3.17 – Diagramme de séquence «Chercher un module».
3.5.5 Réalisation
Interface de la liste des modules
Cette interface montre la liste des modules que l’admin peut consulter.
Figure 3.18 – Interface de la liste des modules.
29
Interface d’ajout d’un module

L’interface suivante expose un formulaire qui permet à l’admin d’ajouter un module.
Figure 3.19 – Interface d’ajout d’un module.
Interface de modification d’un module

Cette interface permet à l’admin de faire une modification à un certain module.
Figure 3.20 – Interface de modification d’un module.
30
Interface de recherche d’un module

L’interface suivante expose que l’admin permet de chercher un certain module en
tapant son nom au niveau de la barre de recherche.
Figure 3.21 – Interface de recherche d’un module.
Interface de suppression d’un module

L’interface suivante expose que l’admin a le droit de supprimer le module qu’il veut.
Figure 3.22 – Interface de suppression d’un module.
31
Chapitre 3. Présentation de Release 1 3.6. Sprint 4 : Gestion des populations cibles
3.6 Sprint 4 : Gestion des populations cibles

A travers ce sprint, l’administrateur est capable de gérer les populations cibles, c’est
à dire il peut ajouter, modifier,chercher et supprimer une population cible.

Le tableau ci-dessous résume le Backlog du quatrième sprint.
-L’admin est capable de voir la liste
1 Afficher liste des populations cibles
des populations cibles
2 Ajouter une population cible -L’admin peut ajouter une population cible
3 Modifier une population cible -L’admin est capable de modifier une population cible
4 Supprimer une population cible -L’admin peut supprimer une popualtion cible
5 chercher une population cible -L’admin peut chercher une population cible
3.6.2 Diagramme de cas d’utilisation «Gestion des populations

cibles»
Ce diagramme de cas d’utilisation ci-dessous montre les tâches de la gestion des po-
pulations cibles faites par l’admin.
Figure 3.23 – Diagramme de cas d’utilisation «Gestion des populations cibles».

le scénario du cas d’utilisation sprint 4 « Gestion des populations cibles » :
32
Description textuelle du cas d’utilisation « Afficher la liste des populations

cibles »
Cas d’utilisation Afficher une populations cible

Postcondition La liste des populations cibles est affichée sur l’écran
1-L’admin demande l’affichage de l’interface des
populations cibles.
3-Le système affiche la liste des populations cibles.
Exception
Table 3.13 – Description textuelle de cas d’utilisation «Afficher une population cible».
Description textuelle du cas d’utilisation « Ajouter une population cible »
Cas d’utilisation Ajouter une population cible

Postcondition Une population cible est ajoutée
d’une population cible.
3-L’admin remplit le formulaire d’ajout et clique sur
le bouton« Ajouter».
ajoute la population cible.
1-Si le champs est vide ou invalide, le système
Exception
Table 3.14 – Description textuelle de cas d’utilisation «Ajouter une population cible».
33
Description textuelle du cas d’utilisation « Modifier une population cible »
Cas d’utilisation Modifier une popualtion cible

Précondition
La population cible existe
Postcondition Une population cible est modifiée
1-L’admin choisit une population cible à modifier.
2-Le système affiche la population cible à modifier.
Description du scénario principal 3-L’admin modifie les informations choisis et clique sur
4-Le système vérifie les données saisies et modifie.
Exception
Table 3.15 – Description textuelle de cas d’utilisation «Modifier une popualtion cible».
Description textuelle du cas d’utilisation « Supprimer une popualtion cible »
Cas d’utilisation Supprimer une popualtion cible

Précondition
La popualtion cible existe
Postcondition Une popualtion cible est supprimée
1-L’admin choisit une popualtion cible à supprimer.
2-Le système supprime la population cible choisie.
Table 3.16 – Description textuelle de cas d’utilisation «Supprimer une popualtion cible».
Description textuelle du cas d’utilisation « Chercher des popualtions cibles »
Cas d’utilisation Chercher une popualtion cible

Précondition
Postcondition Une popualtion cible est trouvée
1-L’admin tape le nom de popualtion cible voulu.
3-Le système affiche la popualtion cible choisie.
1-Si l’une des popualtions cibles cherchée n’est pas trouvé,
Exception
le système n’affiche aucune donnée.
Table 3.17 – Description textuelle de cas d’utilisation «Chercher une popualtion cible
».
34
3.6.4 Conception
quatrième sprint.

Figure 3.24 – Diagramme de classes «Gestion des popualtions cibles».

semble des fonctionnalités appliqués au niveau de la gestion des popualtions cibles .
•Diagramme de séquence «Afficher une popualtion cible»
Figure 3.25 – Diagramme de séquence «Afficher une popualtion cible».
35
•Diagramme de séquence «Ajouter une population cible»
Figure 3.26 – Diagramme de séquence «Ajouter une population cible».
•Diagramme de séquence «Modifier une population cible»
Figure 3.27 – Diagramme de séquence «Modifier une population cible».
36
•Diagramme de séquence «Supprimer une population cible»
Figure 3.28 – Diagramme de séquence «Supprimer une population cible».
•Diagramme de séquence «Chercher une population cible»
Figure 3.29 – Diagramme de séquence «Chercher une population cible».
3.6.5 Réalisation
Interface de la liste des populations cibles
Cette interface montre la liste des populations cibles que l’admin peut consulter.
37
Figure 3.30 – Interface de la liste des populations cibles.
Interface d’ajout d’une population cible

L’interface suivante expose un formulaire qui permet à l’admin d’ajouter une popula-
tion cible.
Figure 3.31 – Interface d’ajout d’une population cible.
Interface de modification d’une population cible

Cette interface permet à l’admin de faire une modification à une certaine population
cible.
38
Figure 3.32 – Interface de modification d’une population cible.
Interface de recherche d’ une population cible

L’interface suivante expose que l’admin permet de chercher un certaine population
cible en tapant son nom au niveau de la barre de recherche.
Figure 3.33 – Interface de recherche d’une population cible.
Interface de suppression d’une population cible

L’interface suivante expose que l’admin a le droit de supprimer la population cible
qu’il veut.
39
Chapitre 3. Présentation de Release 1 3.7. Sprint 5 : Gestion des formations
Figure 3.34 – Interface de suppression d’une population cible.
3.7 Sprint 5 : Gestion des formations

A travers ce sprint, l’administrateur est capable de gérer les formations, c’est à dire il
peut ajouter, modifier et supprimer une formation.

Le tableau ci-dessous résume le Backlog du cinquième sprint.
-L’admin est capable de voir la liste
1 Afficher liste des formations
des formations.
2 Ajouter une formation -L’admin peut ajouter une formation
3 Modifier une formation -L’admin est capable de modifier une formations
4 Supprimer une formation -L’admin peut supprimer une formation
40
3.7.2 Diagramme de cas d’utilisation «Gestion des formations»

Ce diagramme de cas d’utilisation ci-dessous montre les tâches de la gestion des for-
mations faites par l’admin.
Figure 3.35 – Diagramme de cas d’utilisation «Gestion des formations».

le scénario du cas d’utilisation Sprint 5 « Gestion des formations » :
Description textuelle du cas d’utilisation « Afficher la liste des formations »
Cas d’utilisation Afficher une formation

Postcondition La liste des formation est affichée sur l’écran
1-L’admin demande l’affichage de l’interface des formations.
Description du scénario principal 2-Le système récupère les données.
3-Le système affiche la liste des formations.
Exception
Table 3.19 – Description textuelle de cas d’utilisation «Afficher une formation».
41
Description textuelle du cas d’utilisation « Ajouter une formation»
Cas d’utilisation Ajouter une formation

Postcondition Une formation ajoutée
d’une formation.
Description du scénario principal 3-L’admin remplit le formulaire d’ajout et associe un ou
plusieurs emails des formateurs ,modules et populations cibles
à la formation. et clique sur le bouton« Ajouter».
retourne le résultat.
Exception
Table 3.20 – Description textuelle de cas d’utilisation «Ajouter une formation».
Description textuelle du cas d’utilisation « Modifier une formation »
Cas d’utilisation Modifier une formation

Précondition
La formation existe
Postcondition Une formation est modifiée
1-L’admin choisit une formation à modifier.
2-Le système affiche la formation à modifier.
3-L’admin modifie les informations choisis et clique sur
4-Le système vérifie les données saisies et modifie
la formation.
Exception
Table 3.21 – Description textuelle de cas d’utilisation «Modifier une formation».
42
Description textuelle du cas d’utilisation « Supprimer une formation »
Cas d’utilisation Supprimer une formation

Précondition
Postcondition Une formation est supprimée
1-L’admin choisit une popualtion cible à supprimer.
2-Le système supprime la formation choisie.
Table 3.22 – Description textuelle de cas d’utilisation «Supprimer une formation».
Description textuelle du cas d’utilisation « Voir les détails d’une formation »
Cas d’utilisation Voir les détails d’une formation

Précondition
Postcondition Les détails d’une formation sont affichés
1-L’admin choisit une formation pour voir ces détails.
2-Le système affiche les détails la formation choisie.
Table 3.23 – Description textuelle de cas d’utilisation «Voir détails formation».
3.7.4 Conception
cinquième sprint.

Figure 3.36 – Diagramme de classes «Gestion des formations».
43

semble des fonctionnalités appliqués au niveau de la gestion des formations.
•Diagramme de séquence «Afficher une formation»
Figure 3.37 – Diagramme de séquence «Afficher une formation».
•Diagramme de séquence «Ajouter une formation»
Figure 3.38 – Diagramme de séquence «Ajouter une formation».
44
•Diagramme de séquence «Modifier une formation»
Figure 3.39 – Diagramme de séquence «Modifier une formation».
•Diagramme de séquence «Supprimer une formation»
Figure 3.40 – Diagramme de séquence «Supprimer une formation».
45
•Diagramme de séquence «Voir détails formation»
Figure 3.41 – Diagramme de séquence «Voir détails formation».
3.7.5 Réalisation
Interface de la liste des formations
Cette interface montre la liste des formations que l’admin peut consulter.
Figure 3.42 – Interface de la liste des formations.
46
Interface d’ajout d’une formation

L’interface suivante expose un formulaire qui permet à l’admin d’ajouter une forma-
tion.
Figure 3.43 – Interface d’ajout d’une formation.
Figure 3.44 – Interface d’ajout d’une formation.
47
Interface de modification d’une formation

Cette interface permet à l’admin de faire une modification à une certaine formation.
Figure 3.45 – Interface de modification d’une formation.
Interface pour voir les détails d’une formation

L’interface suivante expose que l’admin permet de voir les détails d’une certaine for-
mation en cliquant sur le bouton voir détails.
Figure 3.46 – Interface pour voir les détails d’une formation.
48
Interface de suppression d’une formation

L’interface suivante expose que l’admin a le droit de supprimer la formation qu’il veut.
Figure 3.47 – Interface de suppression d’une formation.
3.7.6 Conclusion
Ce chapitre a donné une vision sur notre travail, et a donné l’aspect conceptuel concer-
nant les tâches de l’administrateur à travers les différents schémas décrits en UML, et on
a montré aussi la réalisation de chaque interface.
49
Chapitre 4
4.1 Introduction
Ce chapitre expose le deuxième Release lié au formateur ,qui sera divisé en une série des
sprints. C’est pourquoi nous allons élaboré une étude fonctionnel à travers des diagrammes
de cas d’utilisation précis. Par la suite, nous décrirons les diagrammes de séquences.
Finalemenet nous montrerons les interfaces réalisées.

Dans cette section nous allons indiqués 3 Sprints qui sont :

Sprint 1 Inscription
4.3 Sprint 1 :Inscription

Au niveau de cette section on va montrer le développement du backlog produit du
sprint 1 qui a pour rôle de permettre à un formateur de s’inscrire pour qu’il puisse accéder
à l’application pour donner des formations.
4.3.1 diagramme de cas d’utilisation «Inscription»

Ce diagramme de cas d’utilisation montre que le formateur doit s’inscrire pour être
membre de l’application.
50
Chapitre 4. Présentation de Release 2 4.3. Sprint 1 :Inscription
Figure 4.1 – Diagramme de cas d’utilisation «Inscription».

Le tableau ci-dessous décrit textuellement le cas d’utilisation «S’inscrire».
Cas d’utilisation S’inscrire

Acteur Formateur
Précondition Formateur veut s’inscrire
Postcondition Formateur est inscrit
1-Le système affiche la page d’inscription.
2-Le formateur remplit les champs par les informations
Description du scénario principal nécessaires et clique sur le bouton «S’inscrire».
3-Le système vérifie les informations saisies et les stockent
dans la base de données et envoie un email de vérification.
1- Le formateur est déjà inscrit
Exception 2-Si l’un des champs est vide ou invalide, le système affiche
Table 4.2 – Description textuelle de cas d’utilisation «S’inscrire».
4.3.3 Conception
Dans cette partie on va présenté le passage de diagramme de cas d’utilisation au
diagramme de classe afin de présenter la vue statique ainsi que le diagramme de séquence
en tant que vue dynamique de notre premier sprint.

Le diagramme de classe «S’inscrire» se traduit par les différentes éléments participantes
à la réalisation de ce dernier.
51
Figure 4.2 – Diagramme de classe «S’inscrire».

est l’architecture 3-Tiers c’est pour ça on a mis en évidence les 3 couches au niveau de la
figure ci-dessus. Comme on a mentionner que l’architecture adoptée pour développer notre
application est l’architecture 3-Tiers c’est pourquoi on a mis en évidence les 3 couches au
niveau de la figure 3.2 ci-dessus.
•La couche «UI :Inscription» montre l’interface graphique qu’elle a pour objectif
d’assurer le dialogue avec l’utilisateur.
•La couche service nommé «C :Inscription », elle réalise les traitements de l’ap-
plication.
•Finissant par le couche accès aux données qui définit l’entité « Utilisateur », elle
s’occupe de l’accès aux données qui sont destinées à être conserver de manière

d’utilisation.
Figure 4.3 – Diagramme de séquence «S’inscrire».
52
4.3.4 Réalisation
Pour y accéder à l’interface d’inscription, le formateur doit s’incrire en remplissant les
champs nécessaires, un lien qui va s’envoyer automatiquement à l’adresse qui l’a insérée ,
il peut copier ce lien dans une onglet pour qu’il soit vérifié.
Figure 4.4 – Interface d’inscription.
Figure 4.5 – Interface de vérification d’email.
Si le formateur a oublié son mot de passe, il peut cliquer sur le bouton Mot de passe
oublié, un email contenant un lien va s’envoyer à lui , à l’aide de ce dernier il peut accéder
à l’interface de réinitialisation de son mot de passe.
53
Chapitre 4. Présentation de Release 2 4.4. Sprint 2 : Authentification
Figure 4.6 – Interface de mot de passe oublié.
Figure 4.7 – Interface de réinitialisation de mot de passe.
4.4 Sprint 2 : Authentification

Pour accéder à sa propre interface, le formateur doit s’authentifier en tapant sa ma-
tricule,son email et son mot de passe.
54

Le tableau ci-dessous décrit textuellement le cas d’utilisation «S’authentifier».

Acteur Formateur
Précondition Formateur veut se connecter
Postcondition Formateur est connecté
1-Le système affiche l’interface de connexion..
2-Le Formateur remplit les champs par les informations
Description du scénario principal nécessaires et clique sur le bouton «Connexion».
3-Le système vérifie les informations saisies
et affiche l’interface suivante.
1-Si l’un des champs est vide ou invalide, le système affiche
Exception
4.4.3 Conception
Au niveau de la phase de conception on va présenter la vue statique ainsi que la vue
dynamique de notre deuxième sprint.

55

d’utilisation.
4.4.4 Réalisation
Pour y accéder à sa propre interface, le formateur doit se connecter en remplissant les
champs nécessaires qui sont la matricule, l’email et le mot de passe.
56
Figure 4.11 – Interface de connexion.

A travers ce sprint, le formateur est capable de gérer les formations qui le corres-
pondent, il peut accepter ou refuser une formation, en cas d’acceptation il peut modifier
la description, et le lien de visioconférence.

-Le formateur peut voir la liste
1 Afficher la liste des formations
des formations qui lui correspondent.
-Le formateur est capable d’accepter ou
2 Accepter ou refuser une formation
refuser une formation.
Modifier la description et le -Le formateur est capable de modifier la
3
lien de visioconférence description et le lien de visioconférence .

mations faites par le formateur.
57

le scénario du cas d’utilisation Sprint 3 « Gestion des formations » :
Cas d’utilisation Afficher la liste des formations

Acteur Formateur
Précondition Une authentification prélable
La liste des formations qui correspond au formateur indiqué
Postcondition
est affichée sur l’écran
1–Le formateur demande l’affichage de l’interface.
Exception
Table 4.5 – Description textuelle de cas d’utilisation «Afficher la liste des formations».
Description textuelle du cas d’utilisation « Accepter/Refuser une formation»
Cas d’utilisation Accepter/Refuser une formation

Acteur Formateur
Une authentification prélable
Précondition
La formation existe
Postcondition Une formation est acceptée ou refusée.
Description du scénario principal 1-Le formateur est capable d’accepter ou refuser une formation.
Table 4.6 – Description textuelle de cas d’utilisation «Accepter/Refuser une formation».
58
Description textuelle du cas d’utilisation « Modifier une formation»
Cas d’utilisation Modifier une formatioion

Acteur Formateur
Une authentification prélable
Précondition
La formation existe
Une formation est modifiée en ajoutant
Postcondition
une description et un lien de visioconférence
1-Le formateur choisit la formation à modifier
et modifie la description et le lien de visioconférencet
et clique sur le bouton «modifier».
4-Le système vérifie les données saisies.
Table 4.7 – Description textuelle de cas d’utilisation «Modifier une formation».
4.5.4 Conception
deuxième sprint.

Les trois couches de notre architecture 3-Tiers se définis comme suit selon le diagramme
de classe dans la figure ci-dessous.
Figure 4.13 – Diagramme de classe «Gestion des formations».

semble des fonctionnalités appliqué au niveau de la gestion des formations.
•Diagramme de séquence «Afficher la liste des formations»
59
Figure 4.14 – Diagramme de séquence «Afficher un formulaire».
•Diagramme de séquence «Accepter/Refuser une formation»
Figure 4.15 – Diagramme de séquence «Accepter/Refuser une formation».
60
•Diagramme de séquence «Modifier une formation»
Figure 4.16 – Diagramme de séquence «Modifier une formation».
4.5.5 Réalisation
L’interface suivante expose la liste des formations. A travers cette derniére, le forma-
teur est capable de consulter la liste des formations qui lui correspondent, accpeter la
formation ou la refuser, en cas d’acceptation il peut passer à l’étape de modification dont
il peut ajouter une description et un lien de visiconférence.
61
Interface d’acceptation d’une formation.

L’interface suivante montre qu’un formateur peut accepter une formation.
Figure 4.18 – Interface d’acceptation d’une formation.
Interface de visioconférence.
L’interface suivante contient un API de visioconférence, qui permet au formateur de
copier un lien de visioconférence en l’ajoutant à la formation , et dans le future il aura le
droit d’accéder à cette interface pour donner des cours aux agents sous forme de formation
en e-learning.
Figure 4.19 – Interface de visiconférence 1.
62
63
Interface de modifcation d’une formation.

L’interface suivante expose que le formateur peut modifier une formation après accep-
tation en ajoutant une description et un lien de visioconférence qui l’a copié précédement.
4.5.6 Conclusion
Dans ce chapitre on a exposé l’aspect conceptuel concernant les tâches du formateur
à travers plusieurs diagrammes ,mis à part la réalisation de chaqu’un d’eux qui permet.
64
Chapitre 5
5.1 Introduction
Ce chapitre expose le troisième Release qui sera divisé en une série des sprints. C’est
pourquoi nous allons élaboré une étude fonctionnelle a travers des diagrammes de cas
d’utilisation précis. Par la suite, nous décrirons les diagrammes de séquences .Finalemenet
nous montrerons les interfaces réalisées.

Dans cette section nous allons indiqués 3 sprints qui sont :

Sprint 1 Inscription
5.3 Sprint 1 :Inscription

Au niveau de cette section on va montrer le développement du backlog produit du
sprint 1 qui a pour rôle de permettre l’agent de s’inscrire pour qu’il puisse accéder à
l’application pour voir les formations qui correspondent à sa population cible.
65
5.3.1 Diagramme de cas d’utilisation «Inscription»

Ce diagramme de cas d’utilisation montre que l’agent doit s’inscrire pour être membre
de l’application.
Figure 5.1 – Diagramme de cas d’utilisation «Inscription».

Le tableau ci-dessous décrit textuellement le cas d’utilisation «S’inscrire».
Cas d’utilisation S’inscrire

Acteur Agent
précondition Agent veut s’inscrire
postcondition Agent est inscrit
1-Le système affiche la page d’inscription.
2-L’agent remplit les champs par les informations
Description du scénario principal nécessaires et clique sur le bouton «S’inscrire».
3-Le système vérifie les informations saisies et les stocke
dans la base de données et affiche l’interface suivante.
1-L’agent est déjà inscrit
Exception 2-Si l’un des champs est vide ou invalide, le système affiche
Table 5.2 – Description textuelle de cas d’utilisation «S’inscrire».
5.3.3 Conception
Dans cette partie on va présenté le passage de diagramme de cas d’utilisation au
diagramme de classe afin de présenter la vue statique ainsi que le diagramme de séquence
en tant que vue dynamique de notre premier sprint.

Le diagramme de classe «S’inscrire» se traduit par les différentes éléments participantes
à la réalisation de ce dernier.
66
Figure 5.2 – Diagramme de classe «S’inscrire».

est l’architecture 3-Tiers c’est pour ça on a mis en évidence les 3 couches au niveau de la
figure ci-dessus. Comme on a mentionner que l’architecture adoptée pour développer notre
application est l’architecture 3-Tiers c’est pourquoi on a mis en évidence les 3 couches au
niveau de la figure 3.2 ci-dessus.
•La couche «UI :Inscription» montre l’interface graphique qu’elle a pour objectif
d’assurer le dialogue avec l’utilisateur.
•La couche service nommé «C :Inscription », elle réalise les traitements de l’ap-
plication.
•Finissant par le couche accès aux données qui définit l’entité « Utilisateur », elle
s’occupe de l’accès aux données qui sont destinées à être conserver de manière

d’utilisation.
Figure 5.3 – Diagramme de séquence «S’inscrire».
67
5.3.4 Réalisation
Pour y accéder à l’interface d’inscription, l’agent doit s’inscrire en remplissant les
champs nécessaires, un lien qui va s’envoyer automatiquement à l’adresse qui l’a insérée,
il peut copier ce lien dans une onglet pour qu’il soit vérifié.
Figure 5.4 – Interface d’inscription.
Figure 5.5 – Interface de vérification d’email.
68
Si l’agent a oublié son mot de passe, il peut cliquer sur le bouton Mot de passe oublié,
un email contenant un lien va s’envoyer à lui , à l’aide de ce dernier il peut accéder à
l’interface de réinitialisation de son mot de passe.
Figure 5.6 – Interface de mot de passe oublié.
Figure 5.7 – Interface de réinitialisation de mot de passe.
5.4 Sprint 2 : Authentification

Pour accéder à sa propre interface, l’agent doit s’authentifier en tapant sa matricule,son
email et son mot de passe.
69

Le tableau ci-dessous décrit textuellement le cas d’utilisation «S’authentifier».

Acteur Agent
précondition Agent veut se connecter
postcondition Agent est connecté
1-Le système affiche l’interface de connexion..
2-L’agent remplit les champs par les informations
Description du scénario principal nécessaires et clique sur le bouton «Connexion».
3-Le système vérifie les informations saisies
et affiche l’interface suivante.
1-Si l’un des champs est vide ou invalide, le système affiche
Exception
5.4.3 Conception
Au niveau de la phase de conception on va présenter la vue statique ainsi que la vue
dynamique de notre deuxième sprint.

L’architecture adoptée pour développer notre application est l’architecture 3-Tiers
c’est pourquoi on a mis en évidence les 3 couches.
•La couche «UI :Authentification» montre l’interface graphique qu’elle a pour ob-
jectif d’assurer le dialogue avec l’utilisateur.
•La couche service nommé «C :Authentification », elle réalise les traitements de
l’application.
•Finissant par le couche accès aux données qui définit l’entité « User », elle s’oc-
cupe de l’accès aux données qui sont destinées à être conserver de manière persis-
tante dans de la base de données.
70

d’utilisation.
5.4.4 Réalisation
Pour y accéder à sa propre interface, le formateur doit se connecter en remplissant les
champs nécessaires.
71
Figure 5.11 – Interface de connexion.

A travers ce sprint, l’agent est capable de gérer les formations qui le correspondent, il
peut voir la liste des formations qui lui correspondent et accéder au lien de visioconférence
lié à la chaque formation pour la suivre.

-L’agent peut voir la liste
1 Afficher la liste des formations
des formations qui lui correspondent.

mations faites par le formateur.
72

Nous avons illustré dans ce tableau ci-dessous les descriptions textuelles concernant le
scénario du cas d’utilisation Sprint 3 « Gestion des formations » :
Cas d’utilisation Afficher la liste des formations

Acteur Agent
précondition Une authentification prélable
La liste des formations qui correspond à l’agent indiqué
postcondition
est affichée sur l’écran
1-L’agent demande l’affichage de l’interface.
Exception
Table 5.5 – Description textuelle de cas d’utilisation «Afficher la liste des formations».
5.5.4 Conception
troisième sprint.

Les trois couches de notre architecture 3-Tiers se définis comme suit selon le diagramme
de classe dans la figure ci-dessous.
Figure 5.13 – Diagramme de classe «Gestion des formations».

semble des fonctionnalités appliqués au niveau de la gestion des formations.
•Diagramme de séquence «Afficher la liste des formations»
73
Figure 5.14 – Diagramme de séquence «Afficher une formation».
5.5.5 Réalisation
L’interface suivante expose la liste des formations. A travers cette derniére, l’agent est
capable de consulter la liste des formations qui lui correspondent dont il peut accéder au
lien de visioconférence lié à chaque formation.
5.5.6 Conclusion
Dans ce chapitre on a exposé l’aspect conceptuel concernant les tâches de l’agent à
travers plusieurs diagrammes ,mis à part la réalisation de chaqu’un d’eux.
74
Chapitre 6
Réalisation
6.1 Introduction
Nous avons développé notre application après la détermination de notre environnement
de travail qui contient nos outils ainsi que le langage à utiliser pour le développement ,et
ça on va l’exposer dans ce chapitre.
6.2 Technologie de développement

Pour réaliser notre application, nous avons utilisé plusieurs ressources matérielles et
logicielles que nous présentons ci-dessous.
6.2.1 Langage de modélisation

UML «Unified Modeling Language»
Est un langage de modélisation unifié qui fournit une méthode standardisée. Il permet
la représentation visuelle d’un aspect ou d’un comportement spécifique d’un système.
Figure 6.1 – Logo UML.
StarUML
StarUML est un logiciel de modélisation UML, open source. Étant simple d’utilisation,
nécessitant peu de ressources système, ce logiciel constitue une excellente option pour une
familiarisation à la modélisation.[?]
75
Chapitre 6. Réalisation 6.2. Technologie de développement
Figure 6.2 – Logo StarUML.
6.2.2 Outil de développement

L’analyse des besoins techniques couvre la spécification des technologies à utiliser ainsi
que la structure de l’application pour donner une vision globale de l’architecture de notre
projet. Avant de traduire le design et ses règles dans un langage de programmation, et afin
de parvenir à une automatisation de ses besoins tels qu’ils ont été définis lors de la phase
de spécification des besoins, nous présenterons l’environnement et les outils de travail.
6.2.3 Environnement matériel

Notre application a été développée à l’aide d’un ordinateur portable avec les caracté-
ristiques suivantes :
Figure 6.3 – Ordinateur portable utilisé.
Figure 6.4 – Environnement matériel.
6.2.4 Environnement logiciel

Pour réaliser notre site, nous avons eu recours aux logiciels suivants :
76
Visual Studio Code

Est un éditeur de code source créé par Microsoft pour Windows, Linux et macOS.
Les fonctionnalités incluent la prise en charge du débogage, la coloration syntaxique, la
complétion de code intelligente, les extraits de code, la refactorisation de code et Git inté-
gré. Il prend en charge presque tous les principaux langages de programmation. Plusieurs
d’entre eux sont inclus par défaut, par exemple JavaScript, TypeScript, CSS et HTML.
Figure 6.5 – Visual Studio Code.
Postman
Postman est un outil populaire utilisé par les développeurs pour tester et déboguer
les API. Il fournit une interface conviviale qui permet de créer, envoyer et analyser des
requêtes HTTP vers différentes API. Postman facilite également l’automatisation des tests
et la documentation des API en générant des collections de requêtes organisées.
Figure 6.6 – Logo Postman.
GitHub
GitHub est une plateforme en ligne où les développeurs stockent et gèrent leur code
source. Cela permet la collaboration, le suivi des modifications et la gestion des projets
de développement. En tant qu’ingénieur et développeur full stack, GitHub vous aide à
travailler efficacement avec d’autres développeurs et à suivre l’évolution de vos projets.
Figure 6.7 – Logo GitHub.
77
6.2.5 Technologies utilisées

Après avoir présenté l’environnement logiciel et matériel, nous passons à la présenta-
tion des langages :
Front End
•React JS :
React.js est une bibliothèque JavaScript open source utilisée pour la création d’in-
terfaces utilisateur interactives et dynamiques. Elle est principalement utilisée pour
la construction d’applications web à page unique (SPA) et permet de diviser l’in-
terface utilisateur en composants réutilisables. React permet de créer des vues
réactives qui se mettent à jour automatiquement lorsque les données sous-jacentes
changent, ce qui permet de construire des applications à la fois efficaces et perfor-
mantes.
Figure 6.8 – Logo React JS.
Voici les avantages du React JS pour lesquelles nous avons choisi ce framework pour
développer notre application web au niveau du front end :
•Composants Réutilisables : Création de morceaux de code réutilisables.

•Virtual DOM : Optimisation des performances via un Virtual DOM.
•Réactivité : Mise à jour automatique des vues lors des changements.
•Communauté Étendue : Grande communauté de développeurs et d’outils.
•Réutilisation pour Mobile : Utilisation de React Native pour le développement
mobile.
Back End
•Node Js :
Node.js est un environnement d’exécution open source qui permet d’utiliser Ja-
vaScript pour créer des applications et des services côté serveur. Il repose sur le
moteur JavaScript V8 de Google, qui est rapide et performant, et offre un modèle
asynchrone et non bloquant. Cela signifie que Node.js peut gérer de nombreuses
connexions simultanées sans ralentir l’exécution du programme.
Figure 6.9 – Logo Node JS.
Voici les avantages du Node JS pour lesquelles nous avons choisi ce framework pour dé-
velopper notre application web au niveau du back end :
78
Performance : Basé sur le moteur V8 de Google pour une exécution rapide.

•Haute Évolutivité : Gère efficacement de nombreuses connexions simultanées.
•Haute Écosystème NPM : Vaste bibliothèque de modules prêts à l’emploi.
•Haute Langage Uniforme : Utilisation cohérente de JavaScript côté client et ser-
veur.
•Haute Applications Temps Réel : Idéal pour les applications nécessitant des mises
à jour instantanées.
•Express Js :
Express.js, est un framework web minimaliste et flexible pour Node.js. Il simplifie la
création d’applications web et d’API en fournissant des fonctionnalités essentielles
pour gérer les routes, les requêtes, les réponses et les middleware. Express permet
de structurer facilement les applications, de gérer les routes de manière élégante et
de créer des serveurs web rapidement en utilisant JavaScript. En tant qu’ingénieur
et développeur full stack, vous trouverez Express.js extrêmement utile pour créer
des applications backend efficaces et modulaires.
Figure 6.10 – Logo Express JS.
Voici les avantages du Express JS pour lesquelles nous avons choisi ce framework pour
développer notre application web au niveau du back end :
•Minimaliste et Flexible : Approche légère et adaptable pour le développement

backend.
•Gestion des Routes : Simplifie la définition et la gestion des chemins d’accès.
•Middleware Puissant : Permet le traitement modulaire des requêtes et des actions
intermédiaires.
•Large Adoption : Grande communauté et abondance de ressources en ligne.
•Intégration Facilitée : S’intègre aisément à d’autres modules et bibliothèques de
l’écosystème Node.js.
Base de données
•MongoDB :
MongoDB est une base de données NoSQL orientée documents, open source. Elle
stocke les données sous forme de documents JSON flexibles dans des collections, of-
frant ainsi une grande adaptabilité aux données non structurées ou semi-structurées.
Cette technologie est pertinente pour votre rôle d’ingénieur et de développeur full
stack car elle permet une gestion efficace des données dans vos applications.
79
Chapitre 6. Réalisation 6.3. Conclusion
Figure 6.11 – Logo MongoDB.
Voici les avantages du MongoDB pour lesquelles nous avons choisi d’utiliser cette base
de données pour développer notre application web :
•Flexibilité de Schéma : MongoDB permet de stocker des données avec des struc-
tures variables, offrant une flexibilité adaptée aux applications en évolution constante.
•Évolutivité Horizontale : La conception de MongoDB supporte l’évolutivité ho-
rizontale, permettant de gérer efficacement de larges volumes de données et de
trafic.
•Requêtes Puissantes : MongoDB offre des capacités de requête avancées et un
langage de requête flexible, simplifiant l’extraction et la manipulation des données.
En combinant ces technologies, l’architecture MERN offre une stack complèt pour
le développement d’applications web. MongoDB stocke les données, Express.js gère les
routes et les requêtes côté serveur, React construit l’interface utilisateur réactive côté
client, et Node.js exécute le code backend. Cette architecture est particulièrement adaptée
aux applications à page unique (SPA) et aux applications en temps réel comme notre
application web.
Figure 6.12 – L’architecture MERN stack.
6.3 Conclusion
Au niveau de ce dernier chapitre, nous avons montré qu’on a réussi à développer
la plateforme web requise de Tunisie Telecom, en utilisant le MERN stack comme une
technologie avancée, on a eu recours à des outils et des logiciels qu’on a utilisé pour
développer cette application web.
80
Conclusion Générale
Notre projet intitulé « Conception et Réalisation d’une Plateforme Web pour la Ges-
tion Interactive des Formations en E-learning » consiste a une solution destinée pour la
société Tunisie Telecom. Les problématiques étaient au niveau de l’absence totale d’une
procédure claire pour la gestion des formations en ligne, qui enfaite permet aux agents de
Tunisie Telecom d’apprendre d’améliorer professionnellement.
Pour atteindre notre objectif,le cadre général, la problématique et la méthodologie

ont été évoqués dans le premier chapitre, suivi par la spécification des besoins et une
conception détaillée dans le deuxième chapitre. Les trois chapitres suivants ont détaillé les
trois releases successifs, mettant en évidence la progression des diagrammes et les captures
d’écran de notre plateforme web. Finalement, le dernier chapitre a mis en lumière les
environnements matériels et logiciels ainsi que les technologies qui ont permis la réalisation
de ce projet.
Ce projet était une réelle occasion pour apprendre des nouvelles technologies. Les
situations de blocage, les problèmes techniques et la pression du temps nous ont appris à
mieux le gérer, à adopter une méthodologie de travail et à respecter les spécifications.
L’ensemble de ce rapport reflète la pertinence et l’efficacité de l’application de gestion
de formations dans un environnement en perpétuelle transformation, où l’apprentissage
continu et la collaboration entre les parties prenantes sont devenus essentiels pour le succès
d’une entreprise.
Finalement, nous tenons à noter que notre plateforme est évolutive, extensible et peut
être toujours enrichie selon les besoins par exemple nous pouvons ajouter un module de
gestion de messagerie entre les acteurs.
81
Bibliographie
[1] https ://nicolas-vidal.com. Consulté le : 01/07/2023.

[2] https ://www.appvizer.fr/magazine/operations/gestion-de-projet/scrum. Consulté
le : 01/07/2023.
[3] https ://www.appvizer.fr/magazine/operations/gestion-de-projet/scrum. Consulté
le : 01/07/2023.
[4] https ://fmi.univ-bba.dz. Consulté le : 02/07/2022.
82

Esprit

Transféré par

Informations du document

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

Esprit

Transféré par

Droits d'auteur :

Formats disponibles

École Supérieure Privée

Rapport de stage ingénieur

Conception et Réalisation d’une Plateforme

Réalisé au sein de la Société Nationale des Télécommunications « Tunisie Telecom »

Encadrant professionnel : Mme Ahlem Aissa

Année Universitaire : 2022-2023

Rapport de stage ingénieur

Conception et Réalisation d’une Plateforme

Réalisé au sein de la Société Nationale des Télécommunications « Tunisie Telecom »

Autorisation de dépôt du rapport de stage ingénieur :

Tout d’abord, je remercie Allah le tout puissant de m’avoir donné le courage et la

Je tiens à remercier tout particulièrement mon encadrante professionnelle

Je remercie également tout particulièrement et à temoigner toute ma reconnaissance à

1 Cadre général et méthodologie adoptée 2

2 Analyse et Spécificiations des Besoins 8

3.4 Sprint 2 : Gestion des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . 18

1.1 Logo de la société Tunisie Telecom . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Diagramme de cas d’utilisation. . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 Diagramme de cas d’utilisation «S’authentifier». . . . . . . . . . . . . . . . 16

3.26 Diagramme de séquence «Ajouter une population cible». . . . . . . . . . . 36

4.1 Diagramme de cas d’utilisation «Inscription». . . . . . . . . . . . . . . . . 51

5.1 Diagramme de cas d’utilisation «Inscription». . . . . . . . . . . . . . . . . 66

5.4 Interface d’inscription. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.1 Logo UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

2.1 Tableau des acteurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 Tableau de Release 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1 Tableau de Release 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.1 Tableau de Release 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Le monde connaît actuellement des avancées technologiques importantes grâce à l’in-

Le présent rapport est organisé en cinque chapitres comme suit :

Cadre général et méthodologie

1.1.1 Présenation de l’organisme d’accueil

Figure 1.1 – Logo de la société Tunisie Telecom

1.1.2 Organigramme de Tunisie Telecom

Figure 1.2 – Organigramme de la société.

1.1.3 Les missions de Tunisie Telecom

– La contribution à l’effort national d’enseignement supérieur en matière de télécom-

Figure 1.3 – Vue générale de Tunisie Telecom.

1.2 Etude de l’existant

1.2.1 Analyse de l’existant

1.2.2 Critique de l’existant

1.2.3 Solution proposée

1.3 Méthodologie de développement

1.3.1 Définition d’une méthode agile

Parmi ses avantages on cite :

Figure 1.4 – Cycle de vie de la méthode SCRUM.

limitée par 15 minutes.

Les user stories

Analyse et Spécificiations des

2.2 Identification des besoins

2.2.1 Identification des acteurs

Table 2.1 – Tableau des acteurs.

2.2.2 Les besoins fonctionnels

2.2.3 Les besoins non fonctionnels

2.3 Pilotage du projet

2.3.1 Diagramme de cas d’utilisation globale

Figure 2.1 – Diagramme de cas d’utilisation.

2.3.2 Backlog produit

Figure 2.2 – Tableau Backlog produit.

2.3.3 Planification des Releases

Figure 2.3 – Liste des releases.

2.4 Architecture proposée

— Frontend (Côté client) :

Figure 2.4 – Logo React JS.