République Tunisienne

Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique

Université de Tunis El Manar

Institut Supérieur d’Informatique d’El Manar

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du

Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques

Spécialité : Ingénierie du Développement du Logiciel

Par

Malak BEN DALLA

Conception et développement des modules de

gestion des cours et de forum pour la plateforme
E-learning 9antra.tn

Encadrant professionnel : Monsieur Ahmed NEFFATI

Encadrant académique : Madame Olfa LIMAM

Réalisé au sein de Bee Coders

Année Universitaire 2021 - 20222

 République Tunisienne

Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique

Université de Tunis El Manar

Institut Supérieur d’Informatique d’El Manar

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du

Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques

Spécialité : Ingénierie du Développement du Logiciel

Par

Malak BEN DALLA

Conception et développement des modules de

gestion des cours et de forum pour la plateforme
E-learning 9antra.tn

Encadrant professionnel : Monsieur Ahmed NEFFATI

Encadrant académique : Madame Olfa LIMAM

Réalisé au sein de Bee Coders

Année Universitaire 2021 - 20222

Dédicaces

C’est grâce à Allah que j’ai élaboré ce modeste travail que je dédie :

À la mémoire et à la l’âme de mon père « Mohammed »,

l’être le plus cher du monde,

que je désire témoigner mon respect, mon amour et mon rattachement.

À ma chère mère « Nessria », source de tendresse et d’amour

et symbole du sacrifice et de bonté.

À mes chers, ma soeur « Mayssa et à mon frère « Aladin »,

qui m’ont supporté à chaque moment de ma vie.

À « Bochra »,« Hayfa » et « Ghofrane », pour leurs moments d’amitié sincère

partagés et leur aide pendant ce long parcours.

À tous mes amis, en souvenir de tout moment qu’on s’est partagé

et qui ne cessent pas de m’encourager et d’apprécier mon effort.

Merci infiniment d’être à côté de moi..

ii
Remerciements

C’est avec plaisir, que nous dédions ces lignes afin d’exprimer notre profonde

gratitude et notre grande reconnaissance à toute personne qui a apporté leur

soutien et contribué à l’aboutissement de ce travail.

Nous tenons à remercier vivement Monsieur Ahmed NEFFATI et Monsieur

Jihed BEN GHARBIA, de nous avoir accueillis au sein de Bee Coders, pour

leurs disponibilités et pour les directives qu’il nous a fournies pendant la durée
de stage.

Nous adressons aussi nos remerciements à Madame Olfa LIMAM pour sa

disponibilité et sa patience, notre encadrante qui ne cesse pas de nous

prodiguer de ses critiques constructives et ses conseils précieux tout au long de

ce projet.

Nos sincères remerciements et profond respect à tous nos professeurs et aux

personnels travaillant à l’Institut Supérieur d’Informatique ”ISI” et à toute

personne qui nous a aidé à élaborer ce travail.

Enfin, nous saisissons cette occasion pour remercier les membres de jury qui

ont accepté de juger notre travail, tout en espérant qu’ils trouvent dans ce
rapport les qualités de clarté et de motivation qu’ils attendent.

iii
Table des matières

Introduction générale 1

1 Contexte général 3
1.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Bee Coders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Étude de l’ éxistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.3 Critique de l’éxistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Solution envisagée et objectifs gloabaux . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.1 Solution envisagée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.2 Objectifs globaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Méthodologie de gestion du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.1 Choix méthodologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.2 Pourquoi Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Langage de Modélisation UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Analyse et planification du projet 13

2.1 Identification des acteurs du système . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Identification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5 Diagramme des cas d’ utilisation globale . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6 Diagramme des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.7 Architecture du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7.1 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

iv
 2.7.2 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.8 Environnement du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.8.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.8.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Sprint 1 30
3.1 Spécification et analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.2 Diagramme de cas d’ utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Description détaillée des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.1 Description du cas d’utilisation "S’ authentifier" . . . . . . . . . . . . . . . . 33
3.2.2 Description du cas d’utilisation " Activer un compte utilisateur" . . . . . . . 34
3.3 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.1 Diagramme de séquences " S’ authentifier " . . . . . . . . . . . . . . . . . . . 36
3.3.2 Diagramme de séquences « Activer compte utilisateur » . . . . . . . . . . . . 37
3.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4 Sprint 2 40
4.1 Spécification et analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.2 Diagramme de cas d’ utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Description détaillée des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.1 Description du cas d’utilisation " Poser une question " . . . . . . . . . . . . . 43
4.2.2 Description du cas d’utilisation " Répondre à une question " . . . . . . . . . 44
4.3 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.1 Diagramme de séquences " Poser une question " . . . . . . . . . . . . . . . . 46
4.3.2 Diagramme de séquences « Répondre à une question » . . . . . . . . . . . . . 47
4.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5 Sprint 3 51
5.1 Spécification et analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1.2 Diagrammes de cas d’ utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 55

v
 5.2 Description détaillée des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Conclusion générale 64

Bibliographie 65

vi
Table des figures

1.1 Logo de bee Coders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Interface d’ accueil Coursera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Interface d’ accueil Studytn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Cycle de vie de la méthode SCRUM. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Diagramme de cas d’ utilisation globale . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2 Diagramme des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 Architecture 3-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1 Diagramme de cas d’ utilisation raffiné du sprint 1 . . . . . . . . . . . . . . . . . . . 32

3.2 Diagramme de séquences « S’ authentifier » . . . . . . . . . . . . . . . . . . . . . . . 36
3.3 Diagramme de séquences « Activer compte utilisateur » . . . . . . . . . . . . . . . . 37
3.4 « Interface d’ authentification » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5 « Interface de modification password» . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6 « Interface d’activation des comptes utilisateurs » . . . . . . . . . . . . . . . . . . . . 39
3.7 « Notification d’ activation du compte » . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1 Diagramme de cas d’ utilisation raffiné du sprint 2 . . . . . . . . . . . . . . . . . . . 42

4.2 Diagramme de séquences « Poser une question » . . . . . . . . . . . . . . . . . . . . 46
4.3 Diagramme de séquences « Répondre à une question » . . . . . . . . . . . . . . . . . 47
4.4 « Interface Forum » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5 « Interface d’ ajout d’ une question » . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6 « Interface de répondre à une question » . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.1 Diagramme de cas d’ utilisation raffiné du sprint 3 de l’ étudiant . . . . . . . . . . . 55

5.2 Diagramme de cas d’ utilisation raffiné du sprint 3 de l’ administrateur . . . . . . . . 56
5.3 Diagramme de séquence de l’inscription à un cours . . . . . . . . . . . . . . . . . . . 58
5.4 Interface ajouter un lesson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.5 Interface de la liste des sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.6 Interface de la liste des cours de l’ étudiant . . . . . . . . . . . . . . . . . . . . . . . 60

vii
5.7 Interface des lessons du cours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.8 Interface des notes de l’ étudiant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.9 Interface d’ évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.10 Interface du choix du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.11 Interface du choix du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.12 Interface du choix du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

viii
Liste des tableaux

1.1 Étude comparative entre les différentes solutions . . . . . . . . . . . . . . . . . . . . 7

2.1 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Partitionnement des user stories par sprint . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2 Description textuelle du cas d’utilisation " S’ authentifier " . . . . . . . . . . . . . . 33
3.3 Description textuelle du cas d’utilisation "Activer compte utilisateur" . . . . . . . . . 34

4.1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2 Description textuelle du cas d’utilisation " Poser une question " . . . . . . . . . . . . 43
4.3 Description textuelle du cas d’utilisation " Répondre à une question " . . . . . . . . 44

5.1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.2 Description textuelle du cas d’utilisation " S’ inscrire à un cours " . . . . . . . . . . . 57
5.3 Description textuelle du cas d’utilisation " Ajouter une lesson " . . . . . . . . . . . . 57

ix
Liste des abréviations

— API = Application Programming Interface

— IHM = Interface Homme Machine

— JPA = Java Persistence API

— MOOC = Massive Open Online Course

— MVC = Model View Controller

— REST = Representational State Transfer

— UML = Unified Modeling Language

— XP = EXtreme Programming

x
Introduction générale

En faisant de la matière grise l’un des principaux déterminants de notre croissance future et
en particulier la plus grande richesse d’un pays, l’économie de l’immatériel impose de disposer des
meilleures institutions permettant de la valoriser.

Après décembre 2019, la nature mondiale de la pandémie de COVID-19 a accéléré la numérisation

à un rythme sans précédent, le progrès des technologies, l’ évolution des métiers, le changement
d’ organisation et la transformation des méthodes d’enseignement. Ainsi, les besoins de faire une
formation augmentent. les internautes sont de plus en plus curieux surtout en ce qui concerne les
technologies informatiques.

L’ école n’est plus suffisante pour acquérir toutes les connaissances désirées tandis que le
monde est maintenant plus que jamais, concernés par les effets de la mondialisation dont les nouvelles
technologies de l’information et de la communication, alors nous devons penser à un « apprentissage
efficace, rapide et flexible », avec un minimum de problèmes d’organisation, de logistique et surtout
de perte de temps, puisque la distanciation sociale oblige nombre d’entre nous à passer beaucoup
plus de temps en ligne . De ce fait, l’apprentissage en ligne est la solution.

À cet égard, notre projet de fin d’études consiste à concevoir et développer des modules pour
9antra.tn pour passer d’ un site vitrine à une plateforme e-learning. L’ objectif est de réaliser une
application d’ apprentissage tunisienne 100% en ligne qui aide les étudiants et les apprenants en
technologie de l’informatique à enrichir leurs connaissances et acquérir de nouvelles compétences
afin de décrocher rapidement le métier de leurs rêves.

Le présent rapport montre en détail la progression de notre travail. Il s’articule alors, autour
de cinq chapitres : Le premier chapitre, intitulé « Contexte général », comporte une présentation de
l’organisme d’accueil.Il expose aussi une critique de l’ existant, et l’ étude des applications similaires
que nous avons fait. Ensuite, il démontre la solution proposée et ses objectifs. Enfin, nous présentons
la méthodologie de développement à suivre pour mettre en œuvre le travail.
Le deuxième chapitre, intitulé « Analyse et planification du projet », présente notre sprint de

1
Introduction générale

démarrage. Il montre en premier lieu, les acteurs ainsi que les besoins fonctionnels et non fonctionnels
de notre solution, il expose aussi le backlog du produit et l’identification des sprints Ensuite, il
montre le diagramme de cas d’utilisation et des classe générals. Enfin, il décrit l’architecture globale
à implémenter, l’environnement matériel et logiciel à adopter au cours du développement.
Les trois chapitres qui suivent font l’objet des sprints à réaliser pour atteindre les objectifs
de notre solution. Dans chaque sprint, nous allons débuter avec la partie analyse puis le diagramme
de séquence, ainsi la réalisation.
Enfin, nous clôturons ce rapport par une conclusion générale dans laquelle nous évaluons le
travail travaillé et nous proposons de nouvelles perspectives dans le main d’améliorer notre projet.

2
 Chapitre 1

Contexte général

Plan
1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Solution envisagée et objectifs gloabaux . . . . . . . . . . . . . . . . . . . 8

4 Méthodologie de gestion du projet . . . . . . . . . . . . . . . . . . . . . . 9

5 Langage de Modélisation UML . . . . . . . . . . . . . . . . . . . . . . . . 11

Chapitre 1. Contexte général

Introduction

Ce chapitre a pour objectif de situer notre sujet dans son contexte général. Nous commençons
par une présentation de l’ organisme d’ accueil Bee Coders. Ensuite, nous décrivons le cadre de
notre projet, critiquant l’ existant pour proposer notre solution. Nous terminons ce chapitre par une
présentation de la méthodologie de travail.

1.1 Organisme d’accueil [1]

Dans cette section, nous présentons l’organisme d’accueil dans lequel s’est déroulé notre stage
de fin d’études et ses services.

1.1.1 Bee Coders

bee Coders est une société tunisienne née en 2018, spécialisée en développement web et
mobile, composée d’un groupe jeune, dynamique et expérimenté combinant différentes compétences.
Elle met en disposition la compétence de ses experts pour développer le produit digital qui
peut correspondre à : un site internet, une application mobile, un logiciel, etc.

Figure 1.1: Logo de bee Coders

1.1.2 Services

Pour les entreprises : Bee Coders garantit le développement des projets en web design,
développement web et en Graphic design dans les meilleures conditions en facteur d’une puissante
capacité d’adaptation et d’intégration. Elle offre aussi des services de consulting pour booster les
performances des employés dans le secteur des technologies de l’ information.
Pour les apprenants/ étudiants : Bee coders offre des modalités d’apprentissage en ligne
souples, assistées par un coach compétent, dans le but d’obtenir votre certificat et avec un acquis
pratique considérable et un accès gratuit.

4
Chapitre 1. Contexte général

1.2 Présentation du projet

Notre projet, intitulé « Conception et développement des modules pour la plateforme E-learning
9antra.tn » s’inscrit dans le cadre du stage de fin d’études de la troisième année cycle ingénieur de
l’ISI (Institut Supérieur de l’Informatique de Ariana). Il a pour but d’approfondir les connaissances
en matière de conception, du langages de programmation et du travail collaboratif qui prépare les
apprenants et lés étudiants davantage pour le monde professionnel.

1.2.1 Problématique

À l’ère de l’ultra-digitalisation, de la plupart des objets de la vie courante, nous constatons

une évolution accélérée surtout après le premier « confinement » du COVID-19.
En effet, dans l’éducation formelle, les méthodes d’enseignement et d’apprentissage sont
limitées, d’où la nécessité d’ un passage rapide aux technologies numériques et à l’apprentissage
en ligne qui élimine les problèmes tel que les contraintes géographiques, etc.
Par conséquent, Bee Coders vise à concevoir une plateforme e-learning adaptée aux enjeux
pédagogiques.

1.2.2 Étude de l’ éxistant

La formation continue se fait actuellement de façon traditionnelle : cours, apprenants et

formateurs sur place. Ce type de formation présente beaucoup d’inconvénients tels que :

8 contraintes géographiques

8 contraintes du nombre de places limitées

8 contraintes du nombre de salles réduites

8 contraintes pour les apprenants qui ont une handicape physique ou un problème de communication

8 coûts du loyer, du transport, du nettoyage

Afin de résoudre ces inconvénients, plusieurs outils ont été créés à base des nouvelles technologies.
Donc, pour approfondir notre compréhension du sujet et avoir une idée plus claire sur les objectifs
de notre projet et ses fonctionnalités attendues, une étude de ces outils existants est nécessaire.

5
Chapitre 1. Contexte général

Parmi les applications qui répondent aux problèmes cités précédemment, nous avons choisi
d’ étudier deux plateformes l ’une mondiale et l’autre tunisienne :

l Coursera

C’ est une plate-forme mondiale d’ apprentissage en ligne. Elle offre à tous, où qu’ils se
trouvent, un accès à des cours et à des diplômes en ligne en collaboration avec certaines meilleures
universités et entreprises du monde entier [2].

Figure 1.2: Interface d’ accueil Coursera

l Studytn

C’ est une plateforme e-learning tunisienne destinée à tout le monde. Elle a différentes
formations programmées en ligne de divers contenus et d’activités. Les cours sont publiés à travers
des instructeurs qui veulent partager leurs connaissances [3].

Figure 1.3: Interface d’ accueil Studytn

6
Chapitre 1. Contexte général

1.2.3 Critique de l’éxistant

Le tableau 1.1 présente une étude comparative entre les différentes solutions.

Tableau 1.1: Étude comparative entre les différentes solutions

Plateforme Avantages Inconvénients

Coursera

• En partenariat avec • Manque d’interaction :

des établissements Ne pas pouvoir poser une
d’enseignement prestigieuses question s’ il y a besoin de

• Large catalogue de cours clarification.

• Accès à des cours en ligne • Absence d’ attestation de

ouverts et massifs (MOOC) réussite gratuite : Il faut

payer le cours pour avoir une
• Cursus riche qui pertmettre
certification
d’ apprendre un sujet
particulier d’ un niveau • Accès limité : Après la

débutant jusqu’ à devenir un finalisation du cours, l’accès

expert. sera expiré, et la révision du

cours sera impossible.

Studytn

• Variété des thèmes • Coûts élevés des cours

• Cours déclinés en chapitres • Pas de cible spécifique

chacun contenant un • Non stabilité de système :
ensemble de vidéos de Avoir des anomalies même
haute qualité au niveau de l’accès à la
plateforme.

7
Chapitre 1. Contexte général

Faisant référence aux sections précédentes, nous identifions l’ensemble des limites suivantes :

• Absence de certification gratuite

• Cours avec accès limité

• Non stabilité du système

• Manque d’ interaction : l’ apprenant ne peut pas poser une question qu’ il a besoin de
clarifications.

1.3 Solution envisagée et objectifs gloabaux

Afin de remédier aux limites des applications citées précédemment, l’équipe développement
au sein de Bee Coders a décidé de réaliser une solution qui répond aux objectifs et qui pallie aux
lacunes constatées.

1.3.1 Solution envisagée

Dans ce cadre, notre projet sert à la mise en place d’ une application web, plateforme
e-learning 9antra.tn qui apporte :

• Différentes formations programmées en ligne de divers contenus du domaine informatique (

développement web et mobile, design web, sécurité informatique, .. ). Les cours sont déclinés
en chapitres, chacun contenant un ensemble de vidéos de haute qualité. Toutes les formations
seront proposées avec une évaluation avant et après la formation et seront également certifiantes.

• Forum pour faciliter l’interaction et poser des questions en cas de besoin de clarification pour
les apprenants

Notre projet se décline principalement en deux parties :

— Une partie Back-End : pour la gestion des utilisateurs, sécurisation des information personnelles,
gestion des cours, gestion du forum

— Une partie Front-End : c’est un ensemble des composants graphiques joue le rôle de l’IHM
pour faciliter les fonctionnalités de l’administrateur et l’ accès aux cours et au forum aux
utilisateurs.

8
Chapitre 1. Contexte général

1.3.2 Objectifs globaux

Les objectifs principaux de notre solution sont les suivants :

ã Assurer les différents services de gestion .

ã Optimiser au maximum le temps d’accès et de manipulation des données.

ã Concevoir des cours à partir des principes pédagogiques.

ã Fiabilité et facilité d’interaction en cas de besoin de poser des questions.

1.4 Méthodologie de gestion du projet

L’ une des étapes les plus importantes pour mener à bien un travail est de choisir la bonne
façon de procéder. C’est pourquoi nous considérons le choix de la méthodologie de travail la mieux
adaptée à notre travail comme une étape importante pour assurer une bonne organisation des tâches.

1.4.1 Choix méthodologique

La sélection de la méthodologie diffère d’un projet à l’autre selon des critères spécifiques
parmi lesquels on mentionne la nature et la taille du projet. Les objectifs de la gestion de projet
sont d’augmenter le niveau de satisfaction des clients et de diminuer la complexité du travail de
développement.
Il existe principalement deux méthodes de gestion de projet :

1.4.1.1 Méthodes classiques

Ces méthodes sont prévisibles, elles se caractérisent par des étapes préorganisées du cycle de
vie du développement logiciel, une planification rigide et une documentation lourde telle que le cycle
vie en cascade. Ces méthodes se caractérisent par l’absence de communication avec le client et la
difficulté de prendre en compte les nouveaux besoins lorsque le projet est en cours.

1.4.1.2 Méthodes agiles

Elles peuvent être définies comme une variété de bonnes pratiques en développement logiciel
et contrairement aux approches traditionnelles, elles sont précises et conviviales. Les méthodes agiles
telles que SCRUM et XP encouragent la collaboration avec le client qui a l’opportunité d’apporter
des modifications tout au long des phases de développement du projet, et c’est ce qui fait que ces

9
Chapitre 1. Contexte général

méthodes se caractérisent par une meilleure visibilité puisque le client connaît très bien ses besoins
et la priorité des tâches à accomplir et ils assurent l’acceptation du changement.
Pour notre projet, nous avons choisi une méthode du type AGILE, plus particulièrement
SCRUM.

1.4.2 Pourquoi Scrum

Scrum est l’une des approches les plus utilisées en Agile. Au contraire de la méthode XP où
le délai de livraison du produit souhaité par le client est incertain, la méthode Scrum propose une
approche temporelle du développement où le délai de livraison du produit souhaité par le client est
certain et bien déterminé.

1.4.2.1 Définition

Scrum est un framework qui est utilisé pour implémenter la méthode agile. Il définit les tâches
comme des user stories qui décrivent quelles fonctionnalités sont nécessaires et à quel point elles sont
importantes, puis passe par une série de sprints basée sur des courtes itérations incrémentales qui
visent à fournir un logiciel fonctionnel livrable et testable. Le principe de Scrum est de maximiser
la productivité et d’assurer en même temps la satisfaction du client. Scrum repose aussi sur trois
grands principes : la transparence, l’inspection et l’adaptation.

1.4.2.2 Les rôles dans Scrum

L’équipe Scrum est auto-organisée et prend les décisions sur la manière dont le travail sera
réalisé pour atteindre l’objectif du sprint, elle est composée d’ un propriétaire de produit„d’un Scrum
Master et d’ une équipe de développement :
Product Owner : qui a la vision du produit, la connaissance de toutes les exigences et la
valeur commerciale de chacun pour le client. Il peut s’agir du client ou d’une autre personne qui a
la vision du client sur le produit.
Scrum Master : son objectif est d’aider et de soutenir l’équipe et le product owner dans
l’application de Scrum. Cela inclut d’ éliminer les obstacles et d’isoler l’équipe Scrum des autres
problèmes externes.
Equipe Scrum : ou équipe de développement a pour mission de délivrer le produit. C’est une
équipe interfonctionnelle qui s’ organise elle-meme avec toutes les compétences et les connaissances
nécessaires pour développer le produit.

10
Chapitre 1. Contexte général

Dans notre cas, les rôles sont répartis comme suit :

• Product Owner : Ahmed NEFFATI.

• Scrum Master : Ahmed NEFFATI.

• Equipe Scrum : Malak BEN DALLA

La figure 1.4 représente le processus Scrum et ses principales phases.

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

Outils de SCRUM
Google Meet : Pour la communication et les réunions.
Jira : Pour la gestion du projet.
GIT/GITLAB : Pour la gestion des travaux.
LaTex : Outils de rédaction du rapport.

1.5 Langage de Modélisation UML

Afin de modéliser nos idées, nous avons choisi UML comme un langage de modélisation. En
effet, UML est un langage standard pour spécifier, visualiser, construire et documenter les artefacts
des systèmes logiciels.
Dans notre projet, nous avons modélisé notre solution au moyen de [4] :
-Diagrammes de cas d’utilisation : il donne un aperçu sur les fonctionnalités du système
sans entrer dans les détails de mise en œuvre. Il illustre les exigences fonctionnelle du système et
son interaction avec les acteurs externes. Un diagramme de cas d’utilisation représente différents
scénarios dans lesquels le système peut être utilisé.

11
Chapitre 1. Contexte général

-Diagrammes de classes : il est utilisé pour décrire la structure statique d’un système en
montrant les classes du système, leurs méthodes et leurs attributs. Le diagramme de classes aide
également à identifier la relation entre ces classes ou objets.
-Diagramme de séquence : Il est également connu sous le nom de diagramme d’événements,
il vise à représenter l’interaction entre les objets dans un ordre séquentiel. Les diagrammes de
séquence décrivant comment et dans quel ordre les objets d’un système fonctionnent.

Conclusion

Le premier chapitre est une étape essentielle pour donner une vision sur le projet. Après
avoir présenté l’organisme d’accueil et identifié les objectifs du projet, nous avons déterminé le
cadre de travail utilisé pour réaliser la solution. Dans le chapitre suivant, nous allons présenter les
spécifications des besoins, le backlog du produit, l’architecture et l’environnement du travail.

12
 Chapitre 2

Analyse et planification du projet

Plan
1 Identification des acteurs du système . . . . . . . . . . . . . . . . . . . . 14

2 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Identification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 Diagramme des cas d’ utilisation globale . . . . . . . . . . . . . . . . . . 23

6 Diagramme des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7 Architecture du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

8 Environnement du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Chapitre 2. Analyse et planification du projet

Introduction

Pour une meilleure conception du projet, l’étude des besoins est une étape primordiale. Dans
ce chapitre, nous nous intéressons à l’identification des différents acteurs du projet et les besoins
fonctionnels et non fonctionnels demandés par la société, par la suite, nous exposerons notre backlog
du produit, l’architecture du projet et l’environnement du travail.

2.1 Identification des acteurs du système

Un acteur [5] est un rôle joué par une entité extérieure représentant une personne ou un
système informatique qui attend un ou plusieurs services à offrir par l’application. Il interagit avec
le système en consultant ou en modifiant son état par l’envoi ou par la réception des messages .
Par conséquent, nous identifions trois acteurs principaux :

• Visiteur : C’est l’acteur qui a pour rôle la consultation des cours et du forum et de s’ inscrire.

• Étudiant : C’est un utilisateur de l’application qui a la possibilité de s’ inscrire aux cours et

d’interragir dans le forum.

• Administrateur : C’est un responsable qui dispose de tous les privilèges. Il gére les cours et le
forum, il a aussi la possibilité de gérer les utilisateurs.

2.2 Identification des besoins

Lors de l’analyse des besoins, nous devons faire la distinction entre les besoins fonctionnels
et non fonctionnels. En effet, les besoins fonctionnels sont l’expression de ce que le produit ou le
service délivré par le projet devrait être ou faire, et les besoins non fonctionnels sont les contraintes
liées à l’implémentation et la mise en œuvre de produit.

2.2.1 Besoins fonctionnels

l’ application à réaliser doit offrir un ensemble de fonctionnalités qui doivent être mises
en relation avec un ensemble de besoins utilisateur. Ces derniers définissent les services que les
utilisateurs s’attendent à voir fournis par cette application. Les principales exigences métiers de
notre application se résument dans les fonctionnalités suivantes :

• Inscription à la plateforme.

• Authentification par un login et un mot de passe pour accéder aux différentes fonctionnalités.

14
Chapitre 2. Analyse et planification du projet

• Gestion des utilisateurs.

• Contrôle d’accès aux différentes fonctionnalités.

• Gestion des catégories des cours

— Consulter la liste des catégories.

— Ajouter des nouveaux catégories.

— Modifier et supprimer catégories.

• Gestion des cours

— Consulter la liste des cours.

— Ajouter des nouveaux cours par catégorie.

— Modifier et supprimer des cours.

• Gestion des sections

— Consulter la liste des sections.

— Ajouter des nouveaux sections par cours.

— Modifier et supprimer des sections.

• Gestion des Lessons

— Consulter la liste des lesson.

— Ajouter des nouveaux lessons par cours.

— Modifier et supprimer des lessons.

• Gestion des "assessments"

— Consulter la liste des "assessments".

— Ajouter des nouveaux "assessments" par section.

— Modifier et supprimer des "assessments".

• Gestion des "optionAssessments"

— Consulter la liste des "optionAssessments".

— Ajouter des nouveaux "optionAssessments" par "assessment".

— Modifier et supprimer des "optionAssessments".

15
Chapitre 2. Analyse et planification du projet

• Gestion des projets

— Consulter la liste des projets.

— Ajouter des nouveaux projets par cours.

— Modifier et supprimer des projets.

• Gestion des cours inscrits par étudiant

— Consulter la liste des cours inscrits par étudiant.

— S’ inscrire à un cours.

— Supprimer des cours inscrits par étudiant.

— Affecter un score et une certification à un étudiant.

• Gestion des projets des étudiants

— Consulter la liste des projets des étudiants.

— Supprimer des projets des étudiant.

• Gestion des Notes

— Consulter la liste des notes.

— créer une nouvelle note dans le cours inscrit

• Gestion des questions

— Consulter la liste des questions.

— Demander une question dans le forum.

— Modifier et supprimer des questions.

• Gestion des réponses

— Consulter la liste des réponsess.

— Répondre à une question.

— Modifier et supprimer des réponses.

2.2.2 Besoins non fonctionnels

Dans l’intention de réussir notre solution, l’application doit vérifier quelques propriétés et
doit tenir compte de certaines contraintes et exigences.

— Confidentialité : Toutes les informations sont partagées uniquement avec les membres qui
ont un besoin de savoir.

16
Chapitre 2. Analyse et planification du projet

— Sécurité :

• Les informations personnelles ainsi que les transactions sont protégées et ne risquent pas
d’être mutables.

• L’accès aux informations n’est possible qu’après vérification des privilèges et des droits
d’accès. Tous les services web développés nécessitent une phase d’autorisation avec les
jetons avant les utiliser grâce à l’authentification et le cryptage des mots de passe.

— Fiabilité : Les résultats apportés par l’application doivent être fiables et reflètent effectivement
l’état de la base au moment de son interrogation, c’est-à-dire lors de la mises à jour des données.

— Robustesse : En présence de données invalides, le système doit gérer les exceptions pour
garantir un fonctionnement stable.

— Maintenabilité : Nous allons travailler avec une architecture modulaire pour bien séparer et
organiser le code, ainsi l’utilisation d’un outil de versioning "Gitlab" pour garder toutes les
traces de changement.

— Ergonomie : Nous allons suivre les maquettes faites par un spécialiste en design graphique
afin de garantir une navigation aisée et intuitive pour les étudiants.

2.3 Backlog du produit

Après avoir présenté les besoins de notre solution, nous allons détailler dans cette section le
backlog du produit,qui décrit la liste des besoins sous forme des users stories.
Nous présontons le tableau 2.1, qui résume le Backlog du produit relatif à notre solution et
qui énumère les champs suivants :

— ID : C’est un nombre unique et auto-incrémenté pour chaque User Story.

— Titre : C’est le résumé du User Story.

— User Story : C’est une description courte de la tâche à réaliser et qui se définit de la manière
suivante : En tant que "acteur" , je souhaite ...

— E : Evaluation initiale de la charge de travail nécessaire pour l’implémentation de cette tâche.

L’unité est en jours.

— P : Priorité

Pour prioriser nos besoins, nous avons opté pour la méthode «MoSCoW» qui se base sur les
acronymes suivants :

17
Chapitre 2. Analyse et planification du projet

• M signifie «Must Have» : la tâche doit être faite, elle est très prioritaire.

• S signifie «Should Have » : la tâche devrait être faite, elle est essentielle dans la mesure du
possible.

• C signifie «Could Have» : la tâche pourrait être faite, à condition qu’elle n’affecte pas le bon
avancement des autres tâches et elle permet de donner de la valeur ajoutée au projet.

• W signifie «Won’t Have» : l’exigence est classée comme étant un «Luxe», elle ne sera pas faite
durant cette version mais pourra être ajoutée dans d’autres versions plus élaborées.

Tableau 2.1: Backlog de produit

Id Titre En tant que je souhaite P E

1 Authentification Administrateur M 7j
et Gestion des — S’ authentifier
utilisateurs
— Consulter et activer les
comptes utilisateurs.

2 Gestion des Administrateur M 4j

catégories — Créer une nouvelle catégorie.

— Consulter la liste des

catégories.

— Modifier une catégorie.

— Supprimer une catégorie.

3 Gestion des Administrateur M 7j

cours — Créer un nouveau cours.

— Consulter la liste des cours.

— Modifier une cours.

— Supprimer une cours.

18
Chapitre 2. Analyse et planification du projet

4 Gestion des Administrateur M 5j

sections — Créer une nouvelle section
par cours.

— Consulter la liste des

sections.

— Modifier une section.

— Supprimer une section.

5 Gestion des Administrateur S 7j

lessons — Créer une nouvelle lesson par
section.

— Consulter la liste des lessons.

— Modifier une lesson.

— Supprimer une lesson.

6 Gestion d’ Administrateur S 4j
évaluations — Créer une nouvelle évaluation
par section.

— Consulter la liste des

évaluations.

— Modifier une évaluation.

— Supprimer une évaluation.

19
Chapitre 2. Analyse et planification du projet

7 Gestion Administrateur S 5j
des options — Créer une nouvelle option d’
d’évaluation évaluation.

— Consulter la liste des options

d’ évaluation.

— Modifier une option d’

évaluation.

— Supprimer une option d’

évaluation.

8 Gestion des Administrateur S 5j

projets — Créer un nouveau projet.

— Consulter la liste des projets.

— Modifier un projet.

— Supprimer un projet.

9 Gestion des Administrateur S 4j

cours inscrits — Consulter la liste des cours
par étudiant inscrits par étudiant.

— Supprimer des cours inscrits

par étudiant.

— Affecter un score et une

certification à un étudiant.

20
Chapitre 2. Analyse et planification du projet

10 Gestion des Administrateur C 4j

projets des — Consulter la liste des projets
étudiants des étudiants.

— Supprimer des projets des

étudiants.

11 Gestion des Administrateur S 9j

questions et — Consulter la liste des
des réponses questions.

— Créer et modifier une

question.

— Supprimer des questions.

— Consulter la liste des

réponses.

— Créer et modifier une

réponse.

— Supprimer des réponses.

12 Demande d’ Visiteur M 5j
inscription — S’ inscrire

13 Accès au Visiteur S 10j

forum — Consulter la liste des
questions/ forum.

— Chercher une question.

— Consulter une question et ses

réponses.

21
Chapitre 2. Analyse et planification du projet

14 Gestion de Étudiant S 4j
forum — Demander une question.

— Répondre à une question.

15 Accès aux Visiteur M 5j

cours — Consulter la liste des cours.

— Voir les détails d’ un cours.

16 Inscription aux Étudiant M 12j

cours — Consulter la liste de ses
cours.

— Regarder les lessons vidéos d’

un cours.

— Créer une note par cours.

— Consulter la liste des notes.

— Faire une évaluation par

section.

— Choisir un projet à faire.

— Déposer le projet fait.

— Supprimer l’ inscription au
cours

22
Chapitre 2. Analyse et planification du projet

2.4 Identification des sprints

En se basant sur le backlog du produit illustré dans la section précédente, l’équipe a décidé
de trier les users stories par ordre de priorité et dépendance selon les fonctionnalités attendues et
ces derniers sont répartis entre les sprints comme le montre le tableau 2.2 ci-dessous.

Tableau 2.2: Partitionnement des user stories par sprint

Sprint 1 Sprint 2 Sprint 3

Authentification Gestion des questions et Gestion des cours, des

Gestion des comptes des réponses catégories, des sections et
utilisateurs Accès et gestion du forum des lessons.
Inscription aux cours
Gestion des projets et d’
évaluation
Gestion des notes

2.5 Diagramme des cas d’ utilisation globale

Afin de donner une vision globale sur le comportement fonctionnel de notre application, nous
utilisons le diagramme de cas d’utilisation permettant de représenter de façon intuitive les différentes
interactions entre les acteurs et le système sans se soucier du fonctionnement interne de l’application.
Le diagramme de cas d’utilisation global représenté par la figure 2.1 , modélise les fonctionnalités
attendues par notre solution. Ce diagram sera découpé et raffiné lors de la phase d’ identification
des besoins de chaque sprint.

23
Chapitre 2. Analyse et planification du projet

Figure 2.1: Diagramme de cas d’ utilisation globale

24
Chapitre 2. Analyse et planification du projet

2.6 Diagramme des classes

Le diagramme des classes est considéré comme le plus important dans la modélisation orienté
objet. Il s’ agit d’ une vue statique, du fait qu’ on ne tient pas compte au facteur temporelle dans le
comportement du système.
Indépendamment d’ un langage de programmation particoulier, le diagramme des classes
permet de modéliser les classes du sysème et leurs relations , illustré par la figure 2.2.

Figure 2.2: Diagramme des classes

25
Chapitre 2. Analyse et planification du projet

2.7 Architecture du projet

L’architecture est le point de départ pour créer une application bien structurée, en fait une
architecture décrit la manière dont les éléments sont organisés. Dans cette section, nous montrons
le choix opté pour l’organisation physique et logique de notre projet.

2.7.1 Architecture physique

Notre choix est orienté vers l’architecture trois tiers pour notre application web qui s’ applique
au modèle MVC. La figure présente les parties primordiales pour mettre en place cette structure.

Figure 2.3: Architecture 3-tiers

— Serveur web : Le premier tiers prend en charge la présentation de notre application, il utilise
un navigateur web pour créer un lien de communication avec le serveur d’application afin
d’envoyer des demandes de traitement sous forme des requêtes HTTP.

— Serveur d’ application : C’est le coeur de l’application, elle prend en charge la partie

traitement et la logique métier.

— Serveur base de données : Assure la persistance des données et la gestion des flux de
données avec le serveur d’application.

2.7.2 Architecture logique

Dans l’ architecture 3-tiers, nous avons utilisé le modèle de conception MVC comme architecture
logique.
L’architecture logicielle s’intéresse plutôt au découpage logique de l’application et la façon
de regrouper les composants selon le type de fonction et traitements qu’ils effectuent. La figure 2.4
montre le schéma de l’architecture logique détaillée de notre projet.

26
Chapitre 2. Analyse et planification du projet

• Couche Modèle : c’est la couche d’ accès aux données qui permet le stockage et la récupération
des données traitées par la couche applicative.

• Couche Vue : Elle correspond à la couche présentation puisque c’ est la partie visible qui
permet à l’ utilisateur d’ interagir avec l’application. Elle affiche les données qu’elle a récupérées
auprès de la couche applicative en se basant sur le protocole de communication Http.

• Couche Contrôleur : cette couche représente la logique métier qui gère les requêtes des
utilisateurs puis retourne une réponse à l’ aide mutuelle des couches Modèle et Vue. La couche
Contrôleur est composée par des différents modules d’application :

- Couche d’accès aux données (DAO) : cette couche contient les classes d’accès à la base de
données et de traitement des requêtes sur les entités.

- Couche de service métier : elle contient les classes de traitement de logique métier.

- Couche d’exposition des services : cette couche contient les classes d’exposition des services
REST (ou web services) de notre application.

- Couche de sécurité : une couche supplémentaire qui traite la partie authentification et

autorisation de notre solution.

Figure 2.4: Architecture logique

2.8 Environnement du travail

Dans cette partie, nous allons indiquer les différentes caractéristiques qui constituent l’environnement
de travail à savoir l’environnement matériel et logiciel requis pour effectuer la conception, le développement
et le test de l’application.

27
Chapitre 2. Analyse et planification du projet

2.8.1 Environnement matériel

Au cours du développement de notre projet nous avons utilisé, un poste de travail ayant les
caractéristiques suivantes :

Tableau 2.3: Environnement matériel

Marque Lenovo

Processeur Intel CORE i5 8Gen

Disque dur 1 TO

RAM 12 GO

Système d’ exploitation Ubuntu 20.04

2.8.2 Environnement logiciel

Dans cette section nous énumérons les différents outils de développement que nous avons
utilisés au cours de la réalisation du système. Cette solution était développée sous l’environnement
Ubuntu avec l’utilisation de plusieurs logiciels ou éditeurs dont nous pouvons citer :

• Angular 12

Angular est un Framework Javascript, développé par Google et écrit avec Typescript, il permet
de créer la partie front-end des applications web de type SPA (Single Page Application), des
applications web accessibles à partir d’une page web unique.

• Spring Boot

C’ est un framework avancé qui permet de simplifier le démarrage et le développement des

applications basées sur Spring. Plusieurs étapes de configurations sont éliminées avec Spring
Boot, qui contient des conteneurs embarqués. Cela permet à des applications web de s’exécuter
indépendamment et sans déploiement sur le serveur web [6].

• Spring Security

C’ est un Framework de sécurité léger, il fournit une authentification, un support d’autorisation

et d’autres fonctionnalités afin de sécuriser les applications Spring [7].

• MySQL Connector Java

Pour une utilisation plus simplifiée de la base de données Relationnelles MySQL, nous avons
choisi d’opter pour la MySQL Connector Java à l’ aide de Spring Data JPA, ces dernièrss

28
Chapitre 2. Analyse et planification du projet

sont une implémentation qui fournit une couche d’abstraction au client Java, il offre les
fonctionnalités nécessaires en s’intégrant avec le framework Spring.

• MySQL

C’ est une base de données relationnelle open source basée sur des tableaux. Elle étend le
langage SQL combiné à des nombreuses fonctionnalités qui stockent et adaptent en toute
sécurité les charges de travail de données complexes[8].

• Gitlab

C’ est une plate-forme de développement collaborative open source qui permet aux professionnels
de gérer et d’exécuter diverses tâches de projet, telles que la gestion du code source, la
planification de projet, la surveillance et le maintien de la sécurité[9].

Nous avons utilisé Gitlab pour assurer la traçabilité des modifications de notre code source.

• Visual Studio Code Visual Studio Code est un éditeur de code extensible développé par
Microsoft. Cet outil intègre plusieurs fonctionnalités telles que la prise en charge du débogage,
la mise en évidence de la syntaxe, l’auto-complétion du code, la refactorisation du code ainsi
qu’un git intégré[10].

Nous avons utilisé cet éditeur pour développer la partie fron-tend et back-end de notre application.

• Swagger

C’ est un outil de outil de développement open course. Il permet de tester les API afin de les
consommer convenablement dans la partie front-end[11].

• Draw.io

C’ est une plateforme en ligne open source pour le développement extensible et libre en UML.
il possède une variété d’outils permettant une large possibilité de modélisation en UML.

Nous avons utilisé cet outil dans la partie conception de notre projet.

Conclusion

Dans ce chapitre, nous avons spécifié nos besoins fonctionnels et non fonctionnels ainsi que
les acteurs de notre solution, cette étude nous a donné une vision plus claire sur la finalité du projet,
aussi nous avons exposé notre backlog du produit et l’architecture à adopter. Dans le chapitre suivant,
nous allons entamer le sprint 1.

29
 Chapitre 3

Sprint 1

Plan
1 Spécification et analyse des besoins . . . . . . . . . . . . . . . . . . . . . 31

2 Description détaillée des cas d’utilisation . . . . . . . . . . . . . . . . . . 33

3 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Chapitre 3. Sprint 1

Introduction

Après avoir analysé et déterminé les objectifs globaux du notre solution, nous présentons en
détail les différentes phases exécutées durant ce premier sprint, ayant pour objectif la réalisation des
fonctionnalités suivantes : Gestion des comptes et authentification à l’application. Nous commençons
par la spécification et l’analyse des besoins du sprint 1. Par la suite, nous faisons une description
détaillée des cas d’utilisation, les diagrammes de séquence et nous terminons par la réalisation.

3.1 Spécification et analyse des besoins

Dans cette partie, nous allons entamer l’analyse et la spécification des besoins de ce sprint.
Nous allons commencer par présenter le backlog, ensuite établir le diagramme de cas d’utilisation
raffiné, et finir par détailler la description des cas d’utilisation.

3.1.1 Backlog du sprint

Le tableau 3.1 ci-dessous montre le backlog du sprint 1.

Tableau 3.1: Backlog du sprint 1

Id User story Priorité

1.1 En tant qu’ utilisateur, je souhaite m’ authentifier M

à travers un login et un mot de passe afin d’
accéder à mon espace.

1.2 En tant qu’ Admin , je souhaite consulter la M

liste des comptes utilisateurs afin d’ activer ou
supprimer un compte utilisateur.

1.3 En tant qu’ Aadministrateur , je souhaite ajouter M

un nouveau utilisateur.

1.4 En tant qu’ administrateur , je souhaite modifier, M

activer et désactiver un compte utilisateur.

1.5 En tant qu’ administrateur , je souhaite supprimer S

un utilisateur.

1.6 En tant qu ’ utilisateur , je souhaite accéder à mon C

profil afin de gérer mon compte.

31
Chapitre 3. Sprint 1

1.7 En tant qu ’ utilisateur , je souhaite modifier mon C

compte.

1.8 En tant qu ’ utilisateur , je souhaite changer mon C

mot de passe.

3.1.2 Diagramme de cas d’ utilisation

La figure 3.1 présente le diagramme de cas d’utilisation raffiné relative au sprint 1.

Figure 3.1: Diagramme de cas d’ utilisation raffiné du sprint 1

32
Chapitre 3. Sprint 1

3.2 Description détaillée des cas d’utilisation

Dans cette partie, nous allons commencer par décrire les grandes fonctionnalités, et par la
suite nous allons approfondir sur quelques cas d’utilisation :

• S’ authentifier :

L’ utilisateur doit s’ authentifier pour accéder à son espace.

• Gestion des comptes étudiants :

L’ administrateur doit s’ authentifier pour accéder à son espace il trouve les comptes étudiants,
qui visualise leurs noms, prénoms, usernames et leurs états actifs ou non actifs. L’ administrateur
a la main de supprimer un étudiant ou modifier son état.

• Gestion de son compte :

L’ étudiant doit s’ authentifier et être actif pour accéder à son espace il trouve son compte,
qui visualise son nom, prénom, username. L’ étudiant a la main de modifier son username et
changer son mot de passe.

3.2.1 Description du cas d’utilisation "S’ authentifier"

Tableau 3.2: Description textuelle du cas d’utilisation " S’ authentifier "

Titre S’ authentifier

Acteurs Étudiant

Préconditions Inscription Étudiant doit être actif.

Postconditions L’ Étudiant se connecte à la plateforme et peut

accéder à ses fonctionnalités.

33
Chapitre 3. Sprint 1

Sénario nominal 1- L’ Étudiant clique sur le bouton "sign in".

2- Le système affiche la page d’authentification.
3- L’ Étudiant remplit le formulaire de connexion.
4- Le système vérifie tous les champs obligatoires
qui ont été saisis.
5- Le système vérifie la validité du mot de passe
et du nom d’utilisateur.
6- Le système vérifie si le compte est activé par l’
administrateur.
7- Le système affiche la page d’accueil de la
plateforme.

Sénario altérnatif E1 : Saisies vides ou invalides

le système reprend au point 2.
E2 : Étudiant non activé
le système reprend au point 2.
7- Le système affiche un message d’ erreur

3.2.2 Description du cas d’utilisation " Activer un compte utilisateur"

Tableau 3.3: Description textuelle du cas d’utilisation "Activer compte utilisateur"

Titre Activer compte d’utilisateur.

Acteurs Administrateur

Préconditions L’ administrateur dispose d’un nom, d’un mot de

passe et d’un rôle « Admin » pour accéder à l’
espace d’administration.

Postconditions L’ administrateur se connecte à la plateforme et

peut accéder à ses fonctionnalités.

34
Chapitre 3. Sprint 1

Sénario 1- L’ administrateur consulte la liste des

nominal utilisateurs.
2- L’ administrateur choisit d’activer un compte
dans la liste et clique sur le bouton d’activation et
un jeton doit être attribué pour chaque étudiant
et l’activation réussie.
3- Le système affiche une notification de réussite.

3.3 Diagrammes de séquence

Dans cette partie, nous allons montrer les diagrammes de séquences de quelques cas d’utilisation,
en détaillant l’interaction entre les différents objets.

35
Chapitre 3. Sprint 1

3.3.1 Diagramme de séquences " S’ authentifier "

Pour avoir la sécurité voulue dans notre projet dans les informations personnelles des utilisateurs,
nous avons conçu une authentification et autorisation basées sur les jetons JSON Web token (JWT).
La figure 3.2 illustre le diagramme de séquence et les interactions entre les objets qui se
produisent lors du cas d’utilisation « S’ authentifier ».

Figure 3.2: Diagramme de séquences « S’ authentifier »

Il est indispensable de renseigner les informations d’authentification (nom d’utilisateur et

mot de passe), le système vérifie ces données lorsqu’elles sont valides il lui permet d’accéder aux
services du système.

36
Chapitre 3. Sprint 1

3.3.2 Diagramme de séquences « Activer compte utilisateur »

Lorsque l’utilisateur remplit le formulaire d’inscription, il doit attendre l’activation de son

compte. L’ administrateur doit donner l’accès d’acception ou de refus à l’utilisateur.
Le diagramme de séquence suivant illustré par la figure 3.3, met en évidence comment
l’activation du compte utilisateur se produit dans le système à l’aide de la plateforme de l’ administrateur.

Figure 3.3: Diagramme de séquences « Activer compte utilisateur »

37
Chapitre 3. Sprint 1

3.4 Réalisation

Dans cette partie, nous allons présenter les interfaces développées dans ce sprint.

• Interface d’ authentification Chaque utilisateur doit remplir le formulaire avec les données
nécessaires et ces infor- mations doivent être enregistrées dans la base de données. Tous les
champs doivent être remplis pour accéder à son espace. la figure 3.4 montre l ’interface d’
authentification.

Figure 3.4: « Interface d’ authentification »

• Interface de modification password La figure 3.5 ci-dessous présente l’interface de modification

password.

Figure 3.5: « Interface de modification password»

38
Chapitre 3. Sprint 1

• Interface d’activation des comptes utilisateurs Les figures 3.1 et l’interface graphique d’administration
dédiée à la consultation de la liste des comptes des utilisateurs et à l’activation ou la suppression
de ces derniers.

Figure 3.6: « Interface d’activation des comptes utilisateurs »

Figure 3.7: « Notification d’ activation du compte »

Conclusion

Ce chapitre nous a permis de présenter notre premier sprint. Nous avons commencé par décrire
les différentes fonctionnalités, ensuite nous avons fait une description détaillée des cas d’utilisation, et
leurs diagrammes de séquence, nous avons terminé par l’affichage de notre produit. Dans le chapitre
suivant, nous allons détailler le sprint 2 qui est consacré à la gestion des questions et des réponses,
et l’ accès au forum.

39
 Chapitre 4

Sprint 2

Plan
1 Spécification et analyse des besoins . . . . . . . . . . . . . . . . . . . . . 41

2 Description détaillée des cas d’utilisation . . . . . . . . . . . . . . . . . . 43

3 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Chapitre 4. Sprint 2

Introduction

Ce chapitre est dédié à la réalisation de la partie de gestion des questions et des réponses et
d’ accès et aux forum de notre projet. Ce chapitre illustre le cycle de vie du deuxième sprint à savoir
le backlog du sprint avec les priotités, la description des cas d’utilisation, le diagramme de cas d’
utilisation détaillé ainsi des diagrammes de séquence de quelques cas d’utilisation et nous finissons
par la réalisation.

4.1 Spécification et analyse des besoins

Dans cette partie, nous allons entamer l’analyse et la spécification des besoins de ce sprint.
Nous allons commencer par présenter le backlog, ensuite établir le diagramme des cas d’utilisation
de l’ étudiant et l’ administrateur, et finir par détailler la description des cas d’utilisation.

4.1.1 Backlog du sprint

Le tableau 4.1 ci-dessous montre le backlog du sprint 2.

Tableau 4.1: Backlog du sprint 2

Id User story Priorité

13.1 En tant que visiteur, je souhaite consulter le M

Forum.

13.2 En tant que visiteur, je souhaite voir les détails d’ C

une question et ses réponses.

13.3 En tant que visiteur, je souhaite chercher une C

question par mot clé afin de vérifier s’ il existe
déjà une réponse existante à ma question.

14.1 En tant qu’ étudiant je souhaite poser une M

question afin de résoudre un problème.

14.2 En tant qu’ étudiant je souhaite répondre à une M

question.

11.1 En tant qu ’ administrateur , je souhaite consulter S

la liste des question afin de les contrôler.

41
Chapitre 4. Sprint 2

11.2 En tant qu ’ administrateur , je souhaite créer une C

question.

11.3 En tant qu ’ administrateur , je souhaite supprimer S

une question.

11.4 En tant qu ’ administrateur , je souhaite créer une C

réponse.

11.5 En tant qu ’ administrateur , je souhaite supprimer S

une réponse.

4.1.2 Diagramme de cas d’ utilisation

La figure 4.1 présente le diagramme de cas d’utilisation raffiné relative au sprint 2.

Figure 4.1: Diagramme de cas d’ utilisation raffiné du sprint 2

42
Chapitre 4. Sprint 2

4.2 Description détaillée des cas d’utilisation

Nous allons commencer par décrire les fonctionnalitées , et par la suite nous allons concentrer
sur quelques cas d’utilisation pour les détailler :

• Accès aux Forum :

Sans authentification, un visiteur peut consulter le forum qui représente un ensemble des
questions publieés par les étudiants de la plateforme, puis voir les détails et les réponses d’
une question choisite. Il peut aussi chercher une question par mot clé pour vérifier sa question
a déja une réponse.

Après l’ authentification, l’ étudiant peut poser sa question en choisissant le titre et la description

du problème, l peut aussi répondre à une question.

• Gestion des questions : L’ administarteur a la main d’ accéder à la liste des questions et

supprimer des questions non convenables.

• Gestion des réponses :

L’ administarteur a la main d’ accéder à la liste des réponses et supprimer des réponses non
convenables.

4.2.1 Description du cas d’utilisation " Poser une question "

Tableau 4.2: Description textuelle du cas d’utilisation " Poser une question "

Titre Poser une question

Acteurs Étudiant

Préconditions Étudiant doit être authentifié

Postconditions Question créée avec succés selon les informations

saisies.

43
Chapitre 4. Sprint 2

Sénario nominal 1- L’ Étudiant accède au Forum.

2- L’ Étudiant clique sur le bouton "Ask question".
3- Le système affiche le formulaire qui contient les
champs titre et description.
4- L’ Étudiant remplit le formulaire de connexion.
5- L’ Étudiant clique sur le bouton " Post your
question ".
6- Le système affiche une pop-up de succés.
7- L’ Étudiant clique sur le boutoon " Close ".
8- Le système affiche la page Forum, liste des
question publiées.

Sénario altérnatif E1 : Étudiant non authentifié

le système affiche le formulaire de connexion et
reprend au point 2 .
E2 : Saisies invalides
le système reprend au point 4.
7- Le système affiche un message d’ erreur

4.2.2 Description du cas d’utilisation " Répondre à une question "

Tableau 4.3: Description textuelle du cas d’utilisation " Répondre à une question "

Titre Répondre à une question.

Acteurs Étudiant

Préconditions Étudiant authentifié

Postconditions Réponse enregistré et ajouté à la liste des réponses

de la question choisie.

44
Chapitre 4. Sprint 2

Sénario 1- L’ Étudiant accède au Forum.

nominal 2- L’ Étudiant clique sur une question de la liste
de Forum.
3- Le système affiche les détails d’ une question et
le formulaire de réponse.
4- L’ Étudiant remplit le formulaire.
5- L’ Étudiant clique sur le bouton "Post your
answer".
6- Le système affiche la réponse ajoutée.

Sénario E1 : Étudiant non authentifié

altérnatif le système affiche le formulaire de connexion et
reprend au point 4.
E2 : Saisies invalides
le système reprend au point 4.
7- Le système affiche un message d’ erreur

4.3 Diagrammes de séquence

Dans cette partie, nous allons montrer les diagrammes de séquences de quelques cas d’utilisation,
en détaillant l’interaction entre les différents objets.

45
Chapitre 4. Sprint 2

4.3.1 Diagramme de séquences " Poser une question "

La figure 4.2 illustre le diagramme de séquence et les interactions entre les objets qui se
produisent lors du cas d’utilisation « Poser une question ».

Figure 4.2: Diagramme de séquences « Poser une question »

46
Chapitre 4. Sprint 2

4.3.2 Diagramme de séquences « Répondre à une question »

Le diagramme de séquence suivant illustré par la figure 4.3

Figure 4.3: Diagramme de séquences « Répondre à une question »

47
Chapitre 4. Sprint 2

4.4 Réalisation

Dans cette partie, nous allons présenter les interfaces développées dans ce sprint.

• Interface Forum L’ Étudiant peut accéder au Forum, voir les questions publiées ou chercher
une question. Au cas d’ authentification, il peut s’ interragir par l’ ajout d’ une question ou
par répondre à une quetion.

la figure 4.4 montre l ’interface Forum.

Figure 4.4: « Interface Forum »

48
Chapitre 4. Sprint 2

la figure 4.5 montre l ’interface d’ ajout d’ une question.

Figure 4.5: « Interface d’ ajout d’ une question »

la figure 4.6 montre l ’interface de répondre à une question.

Figure 4.6: « Interface de répondre à une question »

Conclusion

Au cours de ce chapitre, nous avons mis en place la partie traitée durant le sprint 2, nous
avons fait recours aux diagrammes de cas d’utilisationpour démontrer la vue statique du projet, et

49
Chapitre 4. Sprint 2

ensuite nous avons utilisé les diagrammes de séquence pour détailler le comportement dynamique.
Et avant de clôturer le chapitre, nous avons exposé la partie réalisation, . Dans le prochain chapitre,
nous allons entamer la phase de sprint 3.

50
 Chapitre 5

Sprint 3

Plan
1 Spécification et analyse des besoins . . . . . . . . . . . . . . . . . . . . . 52

2 Description détaillée des cas d’utilisation . . . . . . . . . . . . . . . . . . 56

3 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Chapitre 5. Sprint 3

Introduction

Ce chapitre représente notre dernier sprint, il englobe les fonctionnalités : gestion des cours,
des sections, des lessons, des évaluations et des projets et l’ accès aux cours inscrits. Ce chapitre
illustre le cycle de vie du troixième sprint à savoir le backlog du sprint avec les priotités, la description
des cas d’utilisation, le diagramme de cas d’ utilisation détaillé ainsi des diagrammes de séquence
de quelques cas d’utilisation et nous finissons par la réalisation.

5.1 Spécification et analyse des besoins

Dans cette partie, nous allons entamer l’analyse et la spécification des besoins de ce sprint.
Nous allons commencer par présenter le backlog, ensuite établir le diagramme des cas d’utilisation,
et finir par détailler la description des cas d’utilisation.

5.1.1 Backlog du sprint

Le tableau 5.1 ci-dessous montre le backlog du sprint 3.

Tableau 5.1: Backlog du sprint 2

Id User story Priorité

2.1 En tant qu’ administrateur, je souhaite ajouter M

une catégorie.

2.2 En tant qu’ administrateur, je souhaite consulter M

mes catégorie.

2.3 En tant qu’ administrateur, je souhaite modifier M

une catégorie.

2.4 En tant qu’ administrateur, je souhaite supprimer M

une catégorie.

3.1 En tant qu’ administrateur, je souhaite ajouter un M

cours.

3.2 En tant qu’ administrateur, je souhaite consulter M

les cours.

3.3 En tant qu’ administrateur, je souhaite modifier M

un cours.

52
Chapitre 5. Sprint 3

3.4 En tant qu’ administrateur, je souhaite supprimer M

un cours.

4.1 En tant qu’ administrateur, je souhaite ajouter M

une section à un cours.

4.2 En tant qu’ administrateur, je souhaite consulter M

les sections.

4.3 En tant qu’ administrateur, je souhaite modifier M

une section.

4.4 En tant qu’ administrateur, je souhaite supprimer M

une section.

5.1 En tant qu’ administrateur, je souhaite ajouter M

une lesson à une section.

5.2 En tant qu’ administrateur, je souhaite consulter M

les lessons.

5.3 En tant qu’ administrateur, je souhaite modifier M

une lesson.

5.4 En tant qu’ administrateur, je souhaite supprimer M

une lesson.

6.1 En tant qu’ administrateur, je souhaite ajouter M

une évaluation à une section.

6.2 En tant qu’ administrateur, je souhaite consulter M

les évaluations.

6.3 En tant qu’ administrateur, je souhaite modifier M

une évaluation.

6.4 En tant qu’ administrateur, je souhaite supprimer M

un évaluation.

7.1 En tant qu’ administrateur, je souhaite ajouter M

une option à une évaluation.

7.2 En tant qu’ administrateur, je souhaite consulter M

les options évaluations.

53
Chapitre 5. Sprint 3

7.3 En tant qu’ administrateur, je souhaite modifier M

une option d’ évaluation.

7.4 En tant qu’ administrateur, je souhaite supprimer M

une option d’ évaluation.

8.1 En tant qu’ administrateur, je souhaite ajouter un M

projet à une section.

8.2 En tant qu’ administrateur, je souhaite consulter M

les projets.

8.3 En tant qu’ administrateur, je souhaite modifier M

un projet.

8.4 En tant qu’ administrateur, je souhaite supprimer M

un projet.

9.1 En tant qu’ administrateur, je souhaite consulter M

les cours inscrits.

9.2 En tant qu’ administrateur, je souhaite affecter un M

score à un cours inscrit.

9.3 En tant qu’ administrateur, je souhaite supprimer M

un cours inscrit.

15.1 En tant que visiteur, je souhaite consulter la liste M

des cours.

15.2 En tant que visiteur, je souhaite voir les détails d’ M

un cours.

16.1 En tant qu’ étudiant, je souhaite m’ inscrire à un M

cours.

16.2 En tant qu’ étudiant, je souhaite regarder les M

vidéos d’ un cours.

16.3 En tant qu’ étudiant, je souhaite consulter mes S

cours.

16.4 En tant qu’ étudiant, je souhaite prendre note à S

un cours.

54
Chapitre 5. Sprint 3

16.5 En tant qu’ étudiant, je souhaite consulter mes S

notes.

16.6 En tant qu’ étudiant, je souhaite faire les S

évaluations après chaque section du cours.

16.7 En tant qu’ étudiant, je souhaite faire les S

évaluations après chaque section du cours.

16.8 En tant qu’ étudiant, je souhaite choisir un projet S

à faire afin de tester ce que j’ ai appris.

16.9 En tant qu’ étudiant, je souhaite déposer mon S

projet.

16.10 En tant qu’ étudiant, je souhaite supprimer l’ S

inscription à cours.

5.1.2 Diagrammes de cas d’ utilisation

5.1.2.1 Diagramme de cas d’ utilisation de l’ étudiant

La figure 5.1 présente le diagramme de cas d’utilisation raffiné relative au sprint 3 de l’

étudiant .

Figure 5.1: Diagramme de cas d’ utilisation raffiné du sprint 3 de l’ étudiant

55
Chapitre 5. Sprint 3

5.1.2.2 Diagramme de cas d’ utilisation de l’ administrateur

La figure 5.2 présente le diagramme de cas d’utilisation raffiné relative au sprint 3 de l’

administrateur.

Figure 5.2: Diagramme de cas d’ utilisation raffiné du sprint 3 de l’ administrateur

5.2 Description détaillée des cas d’utilisation

Dans cette partie, nous allons commencer par décrire les grands cas d’utilisation, et par la
suite nous allons approfondir sur quelques cas d’utilisation :

56
Chapitre 5. Sprint 3

Tableau 5.2: Description textuelle du cas d’utilisation " S’ inscrire à un cours "

Titre S’ inscrire à un cours

Acteurs Étudiant

Préconditions Étudiant doit être authentifié.

Postconditions L’ étudiant est inscrit au cours choisit.

Sénario nominal 1- L’ Étudiant accède à la liste des cours.

2- L’ Étudiant clique sur un cours.
3- Le système affiche les détails du cours choisit.
4- L’ Étudiant clique sur le bouton "Start Course".
5- Le système affiche les lessons du cours
selectionné.

Tableau 5.3: Description textuelle du cas d’utilisation " Ajouter une lesson "

Titre " Ajouter une lesson"

Acteurs Administrateur

Préconditions Administrateur doit être authentifié. Cours et

sections déjà créés.

Postconditions Lesson créée succés selon les informations saisies.

Sénario nominal 1- L’ administrateur consulte la rubrique lesson.

2- L’ administrateur clique sur le bouton " create
Lesson ".
3- Le système affiche le formulaire qui contient les
champs.
4- L’ Étudiant remplit le formulaire par titre, cours
section et lien vidéo, etc.
5- L’ Étudiant clique sur le bouton " Save ".
6- Le système affiche la liste des lessons.

57
Chapitre 5. Sprint 3

5.3 Diagrammes de séquence

La figure 5.3 illustre le diagramme de séquence et les interactions entre les objets qui se
produisent lors du cas d’utilisation « S’ inscrire à un cours ».

Figure 5.3: Diagramme de séquence de l’inscription à un cours

58
Chapitre 5. Sprint 3

5.4 Réalisation

Dans cette partie, nous allons présenter les interfaces développées dans ce sprint.
La figure 5.4 ci-dessous présente l’ interface ajouter une lesson.

Figure 5.4: Interface ajouter un lesson

La figure 5.5 ci-dessous présente l’ interface de la liste des sections.

Figure 5.5: Interface de la liste des sections

59
Chapitre 5. Sprint 3

La figure 5.6 ci-dessous présente l’ interface de la liste des cours de l’ étudiant.

Figure 5.6: Interface de la liste des cours de l’ étudiant

La figure 5.7 ci-dessous présente l’ interface des lessons du cours.

Figure 5.7: Interface des lessons du cours

60
Chapitre 5. Sprint 3

La figure 5.8 ci-dessous présente l’ interface des notes de l’ étudiant.

Figure 5.8: Interface des notes de l’ étudiant

La figure 5.9 ci-dessous présente l’ interface d’ évaluation.

Figure 5.9: Interface d’ évaluation

61
Chapitre 5. Sprint 3

La figure 5.10 ci-dessous présente l’ interface du choix du projet.

Figure 5.10: Interface du choix du projet

La figure 5.11 et 5.12 ci-dessous présente les interfaces d’ importation du projet.

Figure 5.11: Interface du choix du projet

62
Chapitre 5. Sprint 3

Figure 5.12: Interface du choix du projet

Conclusion

Au cours de ce chapitre, nous avons mis en place la partie traitée durant le sprint 2, nous
avons fait recours aux diagrammes de cas d’utilisationpour démontrer la vue statique du projet, et
ensuite nous avons utilisé les diagrammes de séquence pour détailler le comportement dynamique.
Et avant de clôturer le chapitre, nous avons exposé la partie réalisation, . Dans le prochain chapitre,
nous allons entamer la phase de sprint 3.

63
Conclusion générale

Ce projet de fin d’études élaboré au sein de la société Bee Coders, a pour objectif de doter
les cours en ligne pour attirer l’ attention sur l’ importance de l’ e-learning.

L’idée est de concevoir et d’implémenter une plateforme e-learning, qui offre aux étudiants la
possibilité d’ apprendre en ligne à travers des cours en vidéos et aussi d’ interragir grâce au forum
en posant des questions pour avoir des réponses à travers des autres étudiants.

Pour aboutir aux objectifs visés, nous avons d’abord commencé par une étude approfondie
des besoins et des solutions existantes dans le marché. Ensuite, nous avons traité les différentes
phases du projet, tout en respectant le cadre du travail choisi qui est “Scrum”.
Ce stage a été une opportunité riche sur le plan personnel et technique puisqu’il constitue
une véritable porte d’entrée au monde professionnel.

Cette période nous a permis de consolider les connaissances techniques, en effet, ce projet
a été une occasion pour monter en compétence dans le développement front-end et back-end, et
pratiquer les connaissances académiques acquises tout au long de notre cursus universitaire.

En guise de perspectives, la solution peut ajouter un module de suivi de progrès de l’ étudiant.

Ainsi, elle peut intégrer un module d’intelligence artificielle, en appliquant des modèles de machine
learning sur les cours qu ’ un étudiant l’ interresse , ces fonctionnalités avancées sont en mesure de
prédire le comportement des étudiants et prévoir des cours qui peuvent être recommandés.

64
Bibliographie

[1] A. Neffati. (Jan. 2018). « beecoders.tn. » [Accès le 5-Février-2022], adresse : https://www.

beecoders.tn/.

[2] digitiz team. (Octobre. 2018). « Que vaut Coursera ? » [Accès le 25-Mars-2022], digitiz, adresse :
https://digitiz.fr/blog/coursera/.

[3] F. Team. (Jan. 2018). « STUDY.TN. » [Accès le 25-Mars-2022], Flat6Lab, adresse : https:
//www.flat6labs.com/fr/Company/study-tn/.

[4] P. Gérard. (Jan. 2013). « Conception orientée objets. » [Accès le 09-October-2022], IUT de
Villetaneuse, adresse : https://lipn.univ-paris13.fr/~gerard/uml-s2/.

[5] M. B. Brahim. (Jui.2017). « Acteurs. » [Consulté le 30-Avril-2022], ISI, adresse : http://

www.isi.rnu.tn/BIBI/ing/P%20ING%20490.

[6] (Avril. 2019). « Le Tutoriel de Spring Boot pour débutant. » [Accès le 19-Aout-2022], devstory,
adresse : https://devstory.net/11267/tutoriel-spring-boot-pour-debutant.

[7] Q. LEULY. (octobre. 2017). « Preuve d’authentification avec JWT. » [Accès le 19-Aout-2022],
devstory, adresse : https://blog.ippon.fr/2017/10/12/preuve- dauthentification-
avec-jwt/.

[8] JDN. (Janvier. 2019). « MySQL (My Structured Query Language). » [Accès le 19-Aout-2022],
JDN Site, adresse : https://devstory.net/11267/tutoriel-spring-boot-pour-debutant.

[9] A. Pathak. (Février. 2021). « Qu’est-ce que GitLab et où l’héberger ?. » [Accès le 24-Aout-2022],
GeekFlare, adresse : https://geekflare.com/fr/gitlab-hosting/.

[10] wikipedia. (Février. 2021). « Visual Studio Code. » [Accès le 24-Aout-2022], wikipedia, adresse :
https://fr.wikipedia.org/wiki/Visual_Studio_Code.

[11] I. Team. (Février. 2021). « Qu’est-ce que Swagger ? . » [Accès le 24-Aout-2022], GeekFlare,
adresse : https://www.ionos.fr/digitalguide/sites- internet/developpement- web/
quest-ce-que-swagger/.

65
 PÌl›
2021-2022 Ty`›A˜ Tnsl˜ Ty›®ˆ²˜ ¨˜A`˜ dh`m˜ ¨ x¤Cd˜ œt CAV ¨ Pr ŸmR Š¤rKm˜ @¡ Cdn§
rhJ
TtF ­dm˜ Š¤rKm˜ @¡zž
d’¤ .Tyw˜wnkt˜ ¤ TyqybWt˜ wl`˜ ¨ xdnhml˜ TynVw˜ ­ AhK˜ Ylˆ šwOl˜
. ™ˆAftl˜ «dtn› ryw ¤ Ÿyml`tml˜ ­C¤ ¨ ™yst˜ , x¤Cd˜ ­C ¯ “ybW r§wW ‘dh EC wk-¨ T•rJ ¨
MySQL , Angular , API , SpringBoot , MVC : y Af› Aml•

Résumé
Ce travail s’inscrit dans le cadre de notre Projet de Fin d’ Études pour l’obtention du diplôme
d’ingénieur en informatique à l’Institut Supérieur de l’Informatique de l’ Ariana pour l’année
universitaire 2021-2022, fait au sein de l’entreprise bee coders. L’objectif de ce PFE consiste à
concevoir et à développer une plateforme permettant la gestion des cours, l’ inscription au cours.
Cette applcation offre également la possibilité de poser une question et d’ avoir des réponses à
partir d’ un forum.

Mots clés : MVC, SpringBoot, API, Angular, MySQL

Abstract
This work is part of our End of Studies Project to obtain the national software engineer diploma
at the Higher Institute of Informatics for the 2021-2022 academic year. We completed a six-month
internship at bee coders with the objective of developing a plateform that ensure course manage-
ment and course registration. This application offers also the possibility to ask a question and
get answers from the forum.

Keywords : MVC, SpringBoot, API, Angular, MySQL

contact@company.com : ¨ž¤rtk˜¯ d§rb˜ 71 222 222 : H•Af˜ 71 111 111 :  Ah˜ Hžw - ­ryb˜ ‘AfR - C®› ­ry hž
Rue du Lac Malaren, Les Berges du Lac 1053 Tunis Tél : 71 111 111 Fax : 71 222 222 Email : contact@company.com
isi@isim.rnu.tn : ¨ž¤rtk˜¯ d§rb˜ 71 706 698 : H•Af˜ 71 706 164 :  Ah˜ TžA§C
2080 ¨ž¤CAb˜ A§r˜ w
hž 2
2, Abou Raihane Bayrouni 2080 l’Ariana Tél : 71 706 164 Fax : 71 706 698 Email : isi@isim.rnu.tn