Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Direction Générale des Etudes Technologiques

Institut Supérieur des Etudes Technologiques de Bizerte
Département Technologies de l'Informatique

Référence Dép. TI
AN 2023
N° DSI2308

Rapport de
PROJET DE FIN D’ETUDES
En vue de l’obtention de :
Licence Appliquée en Développement des systèmes d’informations

Conception et développement d’un module de la

plateforme ScientiWorld qui permet la gestion
de la réorientation universitaire

Elaboré par :
Sabrine KAMKOUM
Encadré par :
Mme Najla ALLOUCHE (ISET)
Mr Feres OTHMEN (ENTREPRISE)

Effectué à :
Entreprise : Technix Informatique
• Adresse : Rue de la connaissance, 7015 Rafraf
• Tel : +216 72 411 207

Année universitaire 2022-2023

Dédicace

“ À mon cher père Slim je te dédie ce travail pour

t’exprimer ma profonde gratitude pour ton soutien sans
faille, ta présence et ton amour ont été une véritable
source de force et de motivation pour moi,

À ma chère mère Neila que ce travail soit le fruit de tes

sacrifices et ton encouragement, tu as toujours trouvé les
mots justes pour me réconforter et m’encourager,

À mes chères soeurs Nissrine et Oumaima je tiens à

prendre un moment pour vous remercier pour tout vos
encouragements et votre générosité, votre présence et votre
soutien ont été une véritable source de force pour moi,

À toute la famille Kamkoum et Oueslati je vous

remercie pour tout vos encouragements, cette réussite est
aussi la vôtre, et je voulais que vous le sachiez,

À mes chers amis je vous dédie ce travail en témoignage de

l’amitié qui nous unit et des souvenirs que nous avons
passés ensemble,

À tous ceux qui me sont chers, à vous tous

Merci.

”
- Sabrine

I
Remerciements

Merci Allah, mon Dieu, de m’avoir donné la capacité d’écrire et de réfléchir, la force
d’y croire, la patience d’aller jusqu’au bout du rêve et le bonheur de lever mes mains vers
le ciel et de dire “Ya Mouiin ”.
Je tiens à exprimer ma sincère gratitude pour son accompagnement précieux tout au
long de mon Projet de Fin d’Études. Son expertise, sa patience et son soutien constant
ont été essentiels dans la réussite de ce projet, mon encadrante Mme. Allouche Najla.
J’adresse également mes remerciements à M. Kboubi Amir le directeur de la so-
ciété Technix informatique pour son chaleureux accueil, sa confiance ainsi que pour son
encouragement qui m’a poussé vers l’avant.
Je tiens également à exprimer ma profonde gratitude à M. Othmen Feres , CTO
à Technix informatique, qui a assuré mon encadrement avec beaucoup d’engagement, de
patience et de convivialité en dépit de ses responsabilités.
Je tiens à prendre un moment pour exprimer ma sincère gratitude envers chacun de
l’équipe Technix informatique pour son accueil chaleureux et son collaboration précieuse
tout au long de mon stage de fin d’é[Link] suis reconnaissante pour l’environnement de
travail positif et stimulant que ils ont créé.
Je souhaite aussi remercier l’équipe pédagogique et administrative de ISET BIZERTE
spécialement du département technologie de l’informatique pour leurs efforts dans le but
de nos offrir une excellente formation.
Que les membres de jury trouvent, ici, l’expression de mes sincères remerciements pour
l’honneur qu’ils me font en prenant le temps de lire et d’évaluer ce travail.
Pour finir, je souhaite remercier toute personne ayant contribué de prés ou de loin à
la réalisation de ce projet ainsi qu’à la rédaction de ce rapport.

II
Table des matières

Dédicace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I

Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II

Introduction générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1 Cadre général du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 2
1.2 Etude préalable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Critiques de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Méthodologies adoptées . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Méthodologie de modélisation et de conception . . . . . . . . . . . 5
1.3.2 Méthodologie de gestion du projet . . . . . . . . . . . . . . . . . . 5
1.4 Environnemet de travail : . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1 Environnement matériels . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.3 Les langages de programmation . . . . . . . . . . . . . . . . . . . . 9
1.4.4 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.5 Le système de gestion de base de données (SGBD) . . . . . . . . . 10
1.4.6 Les bibliothèques et les outils . . . . . . . . . . . . . . . . . . . . . 10

2 Analyse et spécifications des besoins . . . . . . . . . . . . . . . . . . . . . 12

2.1 Planification de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.2 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.3 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Structure et découpage de projet avec SCRUM . . . . . . . . . . . . . . . 14
2.2.1 Equipe SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Architecture logicielle adoptée . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 La couche de présentation . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2 La couche applicative . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.3 La couche accès aux données . . . . . . . . . . . . . . . . . . . . . 19

3 Release 1 : Planification de concours et le traitement des dossiers . . . 20

III
Table des matières

3.1 Organisation des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Sprint 1 : La gestion d’accès et de profils . . . . . . . . . . . . . . . . . . . 21
3.2.1 Sprint goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.2 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.3 Implémentation de sprint 1 . . . . . . . . . . . . . . . . . . . . . . 24
3.2.4 Sprint review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.5 Sprint rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3 Sprint 2 : La planification du concours . . . . . . . . . . . . . . . . . . . . 44
3.3.1 Sprint goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.2 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.3 Implémentation de sprint 2 . . . . . . . . . . . . . . . . . . . . . . 50
3.3.4 Sprint review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.3.5 Sprint rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.4 Sprint 3 : La gestion et traitement des dossiers de réorientation . . . . . . 70
3.4.1 Sprint goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.4.2 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.4.3 Implémentation de sprint 3 . . . . . . . . . . . . . . . . . . . . . . 72
3.4.4 Sprint review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
3.4.5 Sprint rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
3.5 Sprint 4 : La gestion de la page d’accueil de la plateforme . . . . . . . . . 106
3.5.1 Sprint goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
3.5.2 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
3.5.3 Implémentation de sprint 4 . . . . . . . . . . . . . . . . . . . . . . 109
3.5.4 Sprint review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3.5.5 Sprint rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

4 Release 2 : Planification intelligente de concours et le traitement des

résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.1 Organisation des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.2 Sprint 1 : La gestion des examens et affectations des étudiants aux salles . 124
4.2.1 Sprint goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.2.2 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
4.2.3 Implémentation de sprint 1 . . . . . . . . . . . . . . . . . . . . . . 132
4.2.4 Sprint review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4.2.5 Sprint rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4.3 Sprint 2 : La gestion des calendriers et des convocations des examens . . . 147
4.3.1 Sprint goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4.3.2 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
4.3.3 Implémentation de sprint 2 . . . . . . . . . . . . . . . . . . . . . . 149
4.3.4 Sprint review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
4.3.5 Sprint rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
4.4 Sprint 3: Le traitement des résultats finaux . . . . . . . . . . . . . . . . . . 157
4.4.1 Sprint goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
4.4.2 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
4.4.3 Implémentation de sprint 3 . . . . . . . . . . . . . . . . . . . . . . 160
4.4.4 Sprint review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

IV
Table des matières

4.4.5 Sprint rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Conclusion générale et perspectives . . . . . . . . . . . . . . . . . . . . . . . . 175

Bibliographie et Nétrographie . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

V
Table des figures

1 Logo de Technix Informatique . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Logo de ScientiWorld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Le processus de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4 L’équipe SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6 L’architecture n-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7 Méchanisme de fonctionnemt de Redux . . . . . . . . . . . . . . . . . . . . 19

8 Organisation de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9 Diagramme des cas d’utilisation sprint 1 release 1 . . . . . . . . . . . . . . 24
10 Maquette de création d’un compte étudiant . . . . . . . . . . . . . . . . . 28
11 Maquette de la mise à jour d’un profil étudiant . . . . . . . . . . . . . . . 29
12 Diagramme de séquence système de CU « Créer compte étudiant » . . . . 30
13 Diagramme de séquence système de « S’authentifier étudiant » . . . . . . 31
14 Diagramme de séquence système de « Consulter profil étudiant » . . . . . 31
15 Diagramme de séquence système de « Éditer profil étudiant » . . . . . . . 32
16 Diagramme de classes participantes de CU « Créer compte étudiant » . . 33
17 Diagramme de classes participantes de CU «S’authentifier étudiant » . . . 33
18 Diagramme de classes participantes de CU «Consulter et éditer profil étu-
diant» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
19 Diagramme de classes de conception de sprint 1 release 1. . . . . . . . . . 35
20 Diagramme de séquence de conception de CU «Créer compte étudiant» . 36
21 Diagramme de séquence de conception de CU «S’authentifier étudiant» . 37
22 Diagramme de séquence de conception de CU «Consulter profil étudiant» 38
23 Diagramme de séquence de conception de CU «Editer profil étudiant» . . 38
24 Interface graphique de l’authentification . . . . . . . . . . . . . . . . . . . 39
25 Interface graphique de la page d’accueil de ScientiWorld . . . . . . . . . . 39
26 Interface graphique de la consultation et la modification d’un profil admi-
nistrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
27 Interface graphique de la consultation et la modification d’un profil étu-
diant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
28 Test des champs obligatoires . . . . . . . . . . . . . . . . . . . . . . . . . 41
29 Test de compte introuvable . . . . . . . . . . . . . . . . . . . . . . . . . . 42
30 Test de mot de passe incorrect . . . . . . . . . . . . . . . . . . . . . . . . 42
31 Test des champs invalides . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
32 Message de succès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
33 Diagramme des cas d’utilisation sprint 2 release 1 . . . . . . . . . . . . . . 50

VI
Table des figures

34 Maquette de consultation de la liste des matières . . . . . . . . . . . . . . 55

35 Maquette d’ajout d’une matière . . . . . . . . . . . . . . . . . . . . . . . . 55
36 Maquette de mise à jour d’une matière . . . . . . . . . . . . . . . . . . . . 55
37 Maquette de consultation de la liste des salles d’examen . . . . . . . . . . 56
38 Maquette d’ajout d’une salle d’examen . . . . . . . . . . . . . . . . . . . . 56
39 Maquette de mise à jour d’une salle d’examen . . . . . . . . . . . . . . . . 56
40 Maquette de consultation de la liste des surveillants . . . . . . . . . . . . . 57
41 Maquette d’ajout d’un surveillant . . . . . . . . . . . . . . . . . . . . . . . 57
42 Maquette de mise à jour d’un surveillant . . . . . . . . . . . . . . . . . . . 57
43 Diagramme de séquence système de «Ajouter matière» . . . . . . . . . . . 58
44 Diagramme de séquence système de «Editer matière» . . . . . . . . . . . . 59
45 Diagramme de séquence système de «Supprimer matière» . . . . . . . . . . 60
46 Diagramme de séquence système de «Importer liste des matières» . . . . . 60
47 Diagramme de séquence système de «Exporter liste des matières» . . . . . 61
48 Diagramme de classes participantes de la gestion des matières . . . . . . . 61
49 Diagramme de classes de conception de sprint 2 release 1. . . . . . . . . . . 62
50 Diagramme de séquence de conception «Créer matière» . . . . . . . . . . 63
51 Diagramme de séquence de conception «Editer matière» . . . . . . . . . . 64
52 Diagramme de séquence de conception «Consulter la liste des matières» . 65
53 Interface graphique de la consultation de la liste des matières . . . . . . . . 66
54 Interface graphique de la création d’une nouvelle matière . . . . . . . . . . 66
55 Interface graphique de la suppression d’une matière . . . . . . . . . . . . . 67
56 Icône de modification d’une matière . . . . . . . . . . . . . . . . . . . . . . 67
57 Interface graphique de la modification d’une matière . . . . . . . . . . . . 67
58 Les boutons de «Importer» et «Exporter» liste des matières . . . . . . . . 68
59 Interface graphique de l’exportation de la liste des matières . . . . . . . . . 68
60 Interface graphique d’importation d’une liste matière . . . . . . . . . . . . 68
61 Test des champs obligatoires lors de l’ajout d’une matière . . . . . . . . . . 69
62 Prévention d’erreur de nom de matière . . . . . . . . . . . . . . . . . . . . 69
63 Prévention de duplication de matière . . . . . . . . . . . . . . . . . . . . . 70
64 Diagramme des cas d’utilisation sprint 3 . . . . . . . . . . . . . . . . . . . 73
65 Maquette de la première étape de la création d’un dossier de réorientation 78
66 Maquette de la deuxième étape de la création d’un dossier de réorientation 79
67 Maquette de la consultation et de la recherche d’un dossier de réorientation 80
68 Maquette de changement d’état d’un dossier de réorientation . . . . . . . . 81
69 Diagramme de séquence système de CU «Consulter la liste des branches» . 82
70 Diagramme de séquence système de CU «Consulter mes demandes de ré-
orientation» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
71 Diagramme de séquence système de CU «Créer une demande de réorien-
tation» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
72 Diagramme de séquence système de CU «Télécharger une demande de
réorientation» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
73 Diagramme de séquence système de CU «Consulter les demandes de mon
université» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
74 Diagramme de séquence système de CU «Rechercher un dossier de réorien-
tation» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

VII
Table des figures

75 Diagramme de séquence système de CU «Changer état d’une demande» . . 86

76 Diagramme de classes participantes de CU «Consulter la liste des branches» 87
77 Diagramme de classes participantes de CU «Consulter les demandes de
réorientation d’un étudiant» . . . . . . . . . . . . . . . . . . . . . . . . . . 88
78 Diagramme de classes participantes de CU «Créer une demande de réoien-
tation» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
79 Diagramme de classes participantes de CU «Télécharger une demande de
réorientation» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
80 Diagramme de classes participantes de CU «Rechercher un dossier de ré-
orientation» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
81 Diagramme de classes participantes de CU «Changer état d’un dossier» . . 91
82 Diagramme de classes de conception de sprint 3 release 1. . . . . . . . . . . 92
83 Diagramme de séquence de conception de CU «Consulter la liste des branches
de réorientation» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
84 Diagramme de séquence de conception de CU «Consulter la liste des de-
mandes de réorientation» . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
85 Diagramme de séquence de conception de la première étape de la création
d’une demande de réorientation . . . . . . . . . . . . . . . . . . . . . . . . 95
86 Diagramme de séquence de conception de la deuxième étape de la création
d’une demande de réorientation . . . . . . . . . . . . . . . . . . . . . . . . 96
87 Diagramme de séquence de conception de la troisième étape de la création
d’une demande de réorientation . . . . . . . . . . . . . . . . . . . . . . . . 97
88 Diagramme de séquence de conception de CU «Télécharger une demande
de réorientation» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
89 Diagramme de séquence de conception de CU «Consulter les dossiers de
réorientation de mon université» . . . . . . . . . . . . . . . . . . . . . . . 98
90 Diagramme de séquence de conception de CU «Rechercher un(des) dos-
sier(s) de réorientation» . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
91 Diagramme de séquence de conception de CU «Changer état d’un dossier» 99
92 Interface graphique de la liste des universités . . . . . . . . . . . . . . . . . 100
93 Interface graphique de la liste des facultés . . . . . . . . . . . . . . . . . . 100
94 Interface graphique de la liste des branches . . . . . . . . . . . . . . . . . . 101
95 Interface graphique de modification des informations d’un étudiant . . . . 101
96 Interface graphique de consultation et de choix d’une université . . . . . . 102
97 Interface graphique de choix des branches de réorientation . . . . . . . . . 102
98 Interface graphique de la troisième étape de création du dossier de réorien-
tation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
99 Interface graphique de consultation de toutes les demandes d’un étudiant. . 103
100 Interface graphique de la liste de toutes les demandes d’une université
donnée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
101 Icône détails d’un dossier . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
102 Interface graphique de la page de détails d’un dossier . . . . . . . . . . . . 105
103 Interface graphique de recherche d’un (des) dossier(s) . . . . . . . . . . . . 105
104 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . 110
105 Maquette de la page d’accueil de la plateforme . . . . . . . . . . . . . . . . 113
106 Diagramme de séquence système de CU «Ajouter un programme» . . . . . 114

VIII
Table des figures

107 Diagramme de séquence système de CU « Consulter la liste des programmes

» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
108 Diagramme de séquence système de CU «Modifier un programme» . . . . 116
109 Diagramme de séquence système de CU «Supprimer un programme» . . . 117
110 Diagramme de classes participantes de la gestion des programmes . . . . . 117
111 Diagramme de classes de conception de sprint 4 release 1. . . . . . . . . . . 119
112 Diagramme de séquence de conception de CU «Consulter la liste des pro-
grammes» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
113 Diagramme de séquence de conception de CU «Créer un programme» . . . 120
114 Diagramme de séquence de conception de CU «Modifier un programme» . 121
115 Interface graphique de la liste des programmes . . . . . . . . . . . . . . . . 121
116 Interface graphique d’ajout d’un nouveau programme . . . . . . . . . . . . 122
117 Interface graphique de la page d’accueil de la plateforme . . . . . . . . . . 122
118 Interface graphique des détails d’une université . . . . . . . . . . . . . . . 123

119 Tableau résumant la comparaison entre les arbres de décision ID3, C4.5 et
DID [33] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
120 Schéma de l’algorithme génétique . . . . . . . . . . . . . . . . . . . . . . . 129
121 Diagramme des cas d’utilisation sprint 1 release 2 . . . . . . . . . . . . . . 132
122 Maquette de consultation du calendrier d’examen . . . . . . . . . . . . . . 136
123 Maquette de création et de modification d’un examen . . . . . . . . . . . . 137
124 Diagramme de séquence système de cas d’utilisation «Consulter calendrier
d’examen» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
125 Diagramme de séquence système de cas d’utilisation «Créer un examen» . 138
126 Diagramme de séquence système de cas d’utilisation «Modifier un examen» 139
127 Diagramme de séquence système de cas d’utilisation «Supprimer un examen»140
128 Diagramme de séquence système de cas d’utilisation «Affecter étudiants
dans des salles » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
129 Diagramme de classes participantes de la gestion des examens . . . . . . . 141
130 Diagramme de classes de conception de sprint 1 release 2. . . . . . . . . . . 142
131 Diagramme de séquence de conception de CU «Consulter calendrier» . . . 143
132 Diagramme de séquence de conception de CU «Créer examen» . . . . . . . 144
133 Diagramme de séquence de conception de CU «Modifier examen» . . . . . 145
134 Diagramme de séquence de conception de CU «Affecter étudiants aux salles»146
135 Interface graphique de la consultation du calendrier . . . . . . . . . . . . . 146
136 Interface graphique de la modification d’un examen . . . . . . . . . . . . . 147
137 Diagramme cas d’utilisation de sprint 2 release 2 . . . . . . . . . . . . . . 149
138 Diagramme de séquence système de CU «Télécharger convocation d’examen»150
139 Diagramme de séquence système de CU «Envoyer calendrier de surveillance
aux surveillants par email» . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
140 Diagramme de classes participantes de CU «Télécharger la convocation
d’examen» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
141 Diagramme de classes participantes de CU «Envoyer calendrier de sur-
veillance aux surveillants par email» . . . . . . . . . . . . . . . . . . . . . 152
142 Diagramme de classes de conception de sprint 2 release 2. . . . . . . . . . . 153

IX
Table des figures

143 Diagramme de séquence de conception de CU «Télécharger la convocation

d’examen» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
144 Diagramme de séquence de conception de CU «Envoyer calendrier de sur-
veillance aux surveillants par email» . . . . . . . . . . . . . . . . . . . . . 154
145 La convocation d’examen en format PDF . . . . . . . . . . . . . . . . . . . 155
146 Email envoyé au surveillant . . . . . . . . . . . . . . . . . . . . . . . . . . 156
147 Un exemple de calendrier de surveillance . . . . . . . . . . . . . . . . . . . 156
148 Diagramme cas d’utilisation de sprint 3 release 2 . . . . . . . . . . . . . . 160
149 Maquette de consultation de résultat d’une université . . . . . . . . . . . 163
150 Maquette de consultation de résultat d’un étudiant . . . . . . . . . . . . . 164
151 Diagramme de séquence système de CU «Importer une liste des notes» . . 165
152 Diagramme de séquence système de CU «Exporter la liste des notes» . . . 165
153 Diagramme de séquence système de CU «Affecter étudiants aux branches» 166
154 Diagramme de séquence système de CU «Consulter les résultats d’une
université» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
155 Diagramme de séquence système de CU «Consulter le résultat d’un étudiant»167
156 Diagramme de classes participantes de CU «Importer une liste des notes» . 167
157 Diagramme de classes participantes de CU «Affecter étudiants aux branches»168
158 Diagramme de classes participantes de CU «Consulter résultat d’une uni-
versité» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
159 Diagramme de classes participantes de CU «Consulter résultat d’un étudiant»169
160 Diagramme de classes de conception de sprint 3 release 2. . . . . . . . . . . 170
161 Diagramme de séquence de conception de CU «Importer une liste des notes»171
162 Diagramme de séquence de conception de CU «Affecter étudiants aux
branches» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
163 Interface graphique de consultation de résultat d’un étudiant . . . . . . . . 172
164 Interface graphique de consultation de résultat d’une université . . . . . . 173
165 Le fichier PDF contenant les étudiants qui sont acceptés à une branche . . 173

X
Liste des tableaux

1 Fiche d’identification de Technix Informatique . . . . . . . . . . . . . . . . 3

2 Les caractéristiques de l’ordinateur . . . . . . . . . . . . . . . . . . . . . . 8

3 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Sprint Backlog du sprint 1 release 1 . . . . . . . . . . . . . . . . . . . . . . 22

5 Description textuelle du cas d’utilisation « Créer un compte » . . . . . . . 25
6 Description textuelle du cas d’utilisation « S’authentifier étudiant » . . . . 26
7 Description textuelle du cas d’utilisation « Consulter profil étudiant » . . . 27
8 Description textuelle du cas d’utilisation « Éditer profil étudiant » . . . . . 27
9 Sprint Backlog du sprint 2 release 1 . . . . . . . . . . . . . . . . . . . . . . 45
10 Description textuelle du cas d’utilisation « Ajouter une matière » . . . . . 51
11 Description textuelle du cas d’utilisation « Consulter la liste des matières » 52
12 Description textuelle du cas d’utilisation « Modifier une matière » . . . . . 52
13 Description textuelle du cas d’utilisation « Supprimer une matière » . . . . 53
14 Description textuelle du cas d’utilisation « Importer une liste des matières » 53
15 Description textuelle du cas d’utilisation « Exporter une liste des matières » 54
16 Sprint Backlog du sprint 3 release 1 . . . . . . . . . . . . . . . . . . . . . . 71
17 Description textuelle du cas d’utilisation « Consulter les branches de ré-
orientation » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
18 Description textuelle du cas d’utilisation « Créer une demande de réorien-
tation » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
19 Description textuelle du cas d’utilisation « Télécharger une demande de
réorientation » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
20 Description textuelle du cas d’utilisation « Rechercher un dossier de ré-
orientation » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
21 Description textuelle du cas d’utilisation « Changer état d’un dossier de
réorientation » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
22 Sprint Backlog sprint 4 release 1 . . . . . . . . . . . . . . . . . . . . . . . . 107
23 Description textuelle du cas d’utilisation « Ajouter un programme » . . . . 111
24 Description textuelle du cas d’utilisation « Consulter la liste des pro-
grammes » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
25 Description textuelle du cas d’utilisation « Modifier un programme » . . . 112
26 Description textuelle du cas d’utilisation « Supprimer un programme » . . 112

27 Sprint Backlog sprint 1 release 2 . . . . . . . . . . . . . . . . . . . . . . . . 130

28 Description textuelle du cas d’utilisation « Créer un examen de réorienta-
tion » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

XI
Liste des tableaux

29 Description textuelle du cas d’utilisation « Consulter le calendrier d’exa-

men » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
30 Description textuelle du cas d’utilisation « Modifier un examen de réorien-
tation» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
31 Description textuelle du cas d’utilisation « Supprimer un examen de ré-
orientation » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
32 Description textuelle du cas d’utilisation « Affecter étudiants dans des
salles d’examens » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
33 Description textuelle du cas d’utilisation « Exporter une liste des étudiants
par salle » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
34 Sprint Backlog sprint 2 release 2 . . . . . . . . . . . . . . . . . . . . . . . . 148
35 Description textuelle du cas d’utilisation « Télécharger la convocation
d’examen » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
36 Description textuelle du cas d’utilisation « Enovyer calendrier de sur-
veillance au surveillant par email » . . . . . . . . . . . . . . . . . . . . . . 150
37 Sprint Backlog sprint 3 release 2 . . . . . . . . . . . . . . . . . . . . . . . . 157
38 Description textuelle du cas d’utilisation « Importer une liste des notes » . 161
39 Description textuelle du cas d’utilisation « Exporter une liste des notes » . 161
40 Description textuelle du cas d’utilisation « Affecter les étudiants dans des
filières » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
41 Description textuelle du cas d’utilisation «Consulter le résultat d’une uni-
versité» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
42 Description textuelle du cas d’utilisation « Consulter résultat d’un étudiant »163

XII
Introduction générale

L’orientation universitaire est un enjeu majeur pour les futurs étudiants, qui se re-
trouvent souvent confrontés à des choix difficiles et décisifs quant à leur avenir profes-
sionnel. Plusieurs étudiants se facent à des mauvais choix. De ce fait le concours de
réorientation constitue une source d’espoir et une deuxième chance pour eux pour qu’ils
puissent décrocher les facultés et les filières désirés.
Le processus de gestion de la réorientation universitaire avec la planification et le
traitement des résultats finaux est un processus aussi critique et délicat. Puisque nous
savons tous qu’il demande un très haut degré de sécurité et de précision.
Dans le cadre de notre projet de fin d’études effectué au sein de la société Téchnix
informatique, nous avons pensé à concevoir et développer une application web qui permet
la gestion de la réorientation universitaire et de l’intégrer comme un module dans la
plateforme ScientiWorld.
Ce présent document a pour but de synthétiser la réalisation de notre projet. Il est
subdivisé en quatre chapitres :
Dans le premier chapitre « Cadre général du projet », nous illustrons en premier
lieu, l’organisme d’accueil. Par la suite nous présentons la solution proposée. Enfin, nous
décrivons les méthodologies et l’environnement de travail adoptés pour la réalisation de
notre projet.
Dans le deuxième chapitre « Analyse et spécifications des besoins », nous dévoi-
lons les besoins de notre projet avec la présentation de l’architecture logicielle de notre
application.
Dans le troisième chapitre « Release 1: Planification de concours et le traite-
ment des dossiers », nous pésentons le premier release de notre projet.
Dans le quatrième chapitre « Release 2: Planification intelligente de concours
et le traitement des résultats, nous illustrons notre deuxième release.
Au niveau de chaque release, nous allons définir les sprints en abordant les phases
d’analyse et de conception afin d’aboutir à la phase de la réalisation.
Nous clôturons notre rapport par une conclusion générale et les perspectives envisa-
geables pour notre projet.

1
Chapitre 1

Cadre général du projet

Introduction
Dans ce chapitre préliminaire, nous allons ,en premier lieu, présenter l’organisme d’ac-
cueil où j’ai effectué mon stage de fin d’études, en second lieu nous allons donner une vue
d’ensemble de notre projet tout en expliquant les problèmes à résoudre et la solution pro-
posée. Et en troisième lieu, nous allons détailler la méthodologie que nous avons adopté
pour la réalisation du projet ainsi que l’environnement de travail.

1.1 Présentation de l’organisme d’accueil

Technix Informatique a été crée en 2013. Actuellement, elle se présente comme un

opérateur expérimenté dans le domaine d’é[Link] société s’est engagée dans la four-
niture de ses propres services d’expertises pour consolider sa position dans le marché.
Ayant acquis une expérience dans ce domaine, à travers son activité de représentant d’un
produit étranger et ayant l’exclusivité de la vente de ce produit à l’échelle des pays du
Maghreb, Technix s’est engagée dans l’élargissement de son domaine de compétence en
œuvrant pour le développement de son propre produit antiplagiat.

Fig. 1 : Logo de Technix Informatique

2
Chapitre 1. Cadre général du projet

La société Technix Informatique propose un produit appelé ScientiWorld qui est vendu
sur le marché. Il s’agit d’un système de gestion des universités, également appelé ERP
pédagogique, qui a pour but de centraliser les différentes ressources d’une université.
ScientiWorld est composée de plusieurs modules dont un module de gestion des stages, un
module d’antilagiat, un module de mutation universitaire, module de gestion des projets,
ainsi qu’un module de gestion des emplois du temps, etc.

Fig. 2 : Logo de ScientiWorld

Le tableau 1 représente une fiche d’identification de Technix Informatique

Tab. 1 : Fiche d’identification de Technix Informatique

Nom de la société Technix Informatique

Adresse Rue de la connaissance, 7015 Rafraf
Fondée en 2013
Email info@[Link]
Site Web [Link]
Téléphone +216 72 411 207

1.2 Etude préalable

1.2.1 Etude de l’existant

Après avoir réussi le concours de baccalauréat, certains étudiants seront orientés vers
des spécialités qu’ils n’apprécient pas, alors passer le concours de réorientation est une
deuxième chance pour eux pour être affectés à une spécialité qui se rapproche le plus de
leurs désirs.
La planification du concours de réorientation constitue un soucis pour les adminitra-
teurs des universités, elle consiste à la gestion des salles d’examen, la gestion des matières
d’examen, la gestion des surveillants, le traitement des dossiers des étudiants, l’affectation
des étudiants et des surveillants aux salles d’examen,...etc
Sans oublier le processus de traitement des résultats des étudiants et l’affectation de
ces derniers aux branches désirées.
C’est pour celà la gestion de la réorientation est une tâche aussi critique et délicate
qui exige un système aussi performant et sécurisé.
De nos jours, le traitement des dossiers de réorientation et la planification de concours
se font manuellement dans la plupart des universités. Citons l’exemple de l’université
Tunis El Manar, elle dispose d’un système de gestion de réorientation qui est partiellement
manuel.

3
Chapitre 1. Cadre général du projet

1.2.2 Critiques de l’existant

Comme nous avons noté précédemment, la gestion de réorientation universitaire né-
cessite un système d’information performant et sécurisé pour qu’il puisse gérer l’énorme
quantité de données personnelles relatives aux étudiants
Après une analyse approfondie du système de réorientation de l’université Tunis El
Manar, nous avons pu relever un certain nombre de points faibles de ce système tel que :

• L’affectation des étudiants aux salles d’examen se fait manuellement ce qui peut
mener à des conflits énormes.

• La manque de sécurité et de confidentialité des données car les accès aux informa-
tions ne sont pas contrôlés.

• La plateforme manque d’ergonomie, elle n’est pas assez facile à utiliser.

Dans ce contexte, il est nécessaire de trouver une solution sécurisée, fiable et ergonomique
pour la gestion de réorientation universitaire.

1.2.3 Solution proposée

Comme nous avons noté précédemment, la plateforme ScientiWorld est un ERP pé-
dagogique qui centralise les ressources d’une université, elle est composée par différents
module : gestion des stages, gestion des projets, système antiplagiat etc...
Pour notre part et en tenant compte de l’expérience de la société Technix Informatique,
notre effort portera sur l’analyse des insuffisances relevées lors de l’analyse du système de
réorientation de l’université Tunis EL Manar, afin d’en tenir compte lors de la conception
et le développement notre future application.
De ce fait, nous proposons de concevoir et d’implémenter un module de gestion de
réorientation intégré à la plateforme ScientiWorld. Ce système doit permettre entre autres
de mieux gérer et d’automatiser le processus de réorientation, de plus il permet de le
centraliser dans une seule plateforme, c’est à dire pas besoin de consulter le site web de
chaque université à part, notre solution compris toutes les universités. Il permettra de
mettre en place :

• Un module de gestion des dossiers de réorientation.

• Un module de traitement des dossiers.

• Un module de planification de concours de réorientation.

• Un module de traitement des résultats finaux.

4
Chapitre 1. Cadre général du projet

1.3 Méthodologies adoptées

Au cours de cette section, nous détaillons les méthodologies utilisées qui nous ont
permis d’avancer dans la réalisation de notre projet.

1.3.1 Méthodologie de modélisation et de conception

L’objectif d’une méthodologie de modélisation et de conception c’est de permettre
de formaliser les étapes préliminaires de la réalisation d’un système afin de satisfaire les
besoins du client. Pour ce faire nous avons choisi UML ou Unified Modeling Language
pour la conception de notre projet. Le langage UML (Unified Modeling Language, ou
langage de modélisation unifié) a été pensé pour être un langage de modélisation visuelle
commun, et riche sémantiquement et syntaxiquement. Il est destiné à l’architecture, la
conception et la mise en œuvre de systèmes logiciels complexes par leur structure aussi
bien que leur comportement. L’UML a des applications qui vont au-delà du développement
logiciel, notamment pour les flux de processus dans l’industrie.[1]

1.3.2 Méthodologie de gestion du projet

Afin de parvenir à une application de bonne qualité, nous avons adopté une démarche
cohérente et structurée. D’où l’effort de modélisation qui se situera dans une logique de
conception et de développement orienté selon « le principe d’amélioration continue » via
une coordination active et dynamique entre l’équipe chargée de l’élaboration du service
sollicité et la satisfaction des besoins du client.

Vu que notre projet sera vers la fin livré à un client, il est primordial de le mettre au
courant de toutes les phases de la réalisation.

La participation du client est garantit par les méthodes agiles. En outre, la métho-
dologie agile est la plus appréciée dans le monde des affaires grâce à sa simplicité et son
fonctionnement assez particulier. Le projet réalisé avec l’approche agile sera décortiqué en
des sous projets, chacun d’eux sera traité indépendammenet des autres et l’ensemble est
développé de manière itérative et incrémentale. Et comme framework agile, nous avons
choisi Scrum car les besoins fonctionnels de la plateforme se développent aucours de
l’avancement du projet.

Scrum est la méthode agile la plus utilisée. À l’Instar d’autres méthodes agiles, Scrum
est une démarche de gestion de projets qui fait du client (ou utilisateur) le principal pilote
de l’équipe en charge de développement.

Le terme anglais ”scrum” signifie ”mêlée” et s’inspire ouvertement du rugby, sport qui
requiert une équipe soudée avançant dans la même direction. Dans le cadre de la méthode
Scrum, une ”mêlée” se traduit par un sprint. Entendez par là une phase de développement
d’une à quatre semaines qui visent à concentrer l’équipe projet sur une partie limitée du
produit ou du service à réaliser. [2]

5
Chapitre 1. Cadre général du projet

Comme pour les autres méthodes agiles, l’avantage majeur de Scrum est qu’il conduit
rapidement à une première itération de produit ou de service utilisable sur le terrain.
Validés progressivement par le client, les sprints suivants viennet compléter cette première
base. Il en résulte que la gestion de projet est beaucoup plus productive.

En vue de faciliter la mise en oeuvre rapide et efficace d’un projet, Scrum exige trois
piliers fondamentaux : [3]

• La transparence : Elle vise à faire en sorte que les parties prenantes (équipe
projets, management et utilisateurs) partagent un langage commun et bénéficient
de toutes les informations nécessaires à la compréhension du projet..

• L’inspection : Elle a pour but de vérifier, via des évaluations régulières, que le
développement est toujours en phase avec les demandes du client et qu’il ne dévie
pas par rapport à ces dernières.

• L’adaptation : Un concept qui porte bien son nom. Son objectif ? Corriger la
trajectoire du projet si des écarts avec les résultats à atteindre sont détectés lors de
la phase d’inspection.

Le framework Scrum se compose par certains éléments appelées ”artéfacts Scrum” qui
constituent les éléments de bases du guide de travail scrum. Ils assurent un transfert fluide
et clair des informations entre l’équipe Scrum :

• Le Product Backlog : C’est la liste de toutes les fonctionnalités intervennant

dans la réalisation du projet, décortiqués en taches individuelles avec ses priorités.
Ce document évolue fréquemment au fil du temps en fonction des besoins du client.

• Le Sprint Backlog : C’est une partie du Product Backlog sur laquelle l’équipe de
développement pris en charge durant un sprint.

• L’incrément Produit : Il s’agit de l’ensemble des taches accomplis du Product

Backlog du sprint en cours, ainsi que ceux des sprints précendents.

La réalisation d’un projet avec le framework Scrum impose un ensemble des réunions
ou appelées également ”cérémonies Scrum” dans le but de clarifier le développement d’un
projet agile dans les meilleures conditions. Ces cérémonies sont appelées : [4]

• Le sprint meeting planning (planification du sprint) : C’une réunion qui se

déroule le premier jour du sprint. Le backlog produit est analysé par les partici-
pants, qui vont faire en sorte d’échanger et de se mettre d’accord sur le cadre et les
fonctionnalités qu’ils s’engagent à livrer à la fin du sprint.

• Le daily Scrum (mêlée quotidienne) : Le daily Scrum est une réunion très
rapide qui a lieu chaque jour du sprint, généralement le matin. Chaque participant
prend la parole afin de communiquer au reste de l’équipe.

6
Chapitre 1. Cadre général du projet

• Le sprint review (revue de sprint) : C’une réunion où l’équipe projet présente

aux parties prenantes les différents livrables terminés. Plus qu’une simple présenta-
tion, c’est l’occasion de faire 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 (rétrospective de sprint) : C’est la réunion qui vient

clôturer le sprint. Elle intervient donc tout à la fin.

L’équipe Scrum se compose de :

• Product Owner : Son principal role s’articule sur la compréhension des exigences
client, puis la création et la gestion du backlog produit en fonction de ces exigences.
Il vise à maximiser la valeur business du produit.

• Scrum Master : Il assure la cohérence et la bonne fonctionnement de Scrum. Il

joue le role d’un coach de l’équipe.

• Equipe du développement : C’est un ensemble organisé de personne qui vont

travailler ensemble durant les Sprints afin de réaliser un certain projet. L’équipe
doit etre auto-organisée pour qu’ils puissent prendre des décisions en vue de réaliser
le travail.

La figure 3 ci-dessous représente le processus Scrum avec ses différents acteurs, arté-
facts ainsi que ses cérémonies.

Fig. 3 : Le processus de Scrum

1.4 Environnemet de travail :

Avant de se lancer dans l’implémentation de notre projet, nous allons décrire l’envi-
ronnement et les outils du travail que nous avons utilisé ainsi que leurs caractéristiques.

7
Chapitre 1. Cadre général du projet

1.4.1 Environnement matériels

Lors de la développement de notre plateforme, nous avons utilisé notre ordinateur qui
a comme caractéristiques :

Tab. 2 : Les caractéristiques de l’ordinateur

Propriétaire Kamkoum Sabrine

Marque Lenovo
CPU Intel Core i5 11éme Génération
Ram 8 Go
Système Windows 10 x64

1.4.2 Environnement logiciel

La réalisation d’une application que ce soit web ou mobile nécessite l’utilisation de
plusieurs logiciels. C’est pour celà, nous énumérons dans cette section les logiciels que
nous avons utilisé lors de la développement de notre plateforme.

• Visual Studio Code

Visual Studio Code est un éditeur de code exten-
sible développé par Microsoft pour Windows, Linux
et macOS3. [5]

• Postman

Postman est une application permettant de tester

des API, créée en 2012 par Abhinav Asthana. [6]

• GitLab
GitLab GitLab est un logiciel libre de forge basé sur
git proposant les fonctionnalités de wiki, un système
de suivi des bugs, l’intégration continue et la livraison
continue. [7]

• Overleaf

Overleaf est un éditeur LaTeX en ligne, collaboratif

en temps réel. [8]

• Node JS
Node JS est un environnement d’exécution single-
thread, open-source et multi-plateforme permettant
de créer des applications rapides et évolutives côté ser-
veur et en réseau. [9]

8
Chapitre 1. Cadre général du projet

• Trello

Trello est un outil de gestion de projet en ligne, lancé

en septembre 2011 et inspiré par la méthode Kanban
de Toyota. [10]

• Odoo

Odoo est initialement un progiciel de gestion intégré

open-source comprenant de très nombreux modules
permettant de répondre à de nombreux besoins de
gestion des entreprises ou de gestion de la relation
client (CRM). [11]

• [Link]

[Link] est une application gratuite en ligne, acces-

sible via son navigateur (protocole https) qui permet
de dessiner des diagrammes ou des organigrammes.
[12]

• Balsamiq Wireframes

Balsamiq Wireframes est un outil de conception

d’interface utilisateur permettant de créer des wire-
frames (parfois appelés maquettes ou prototypes basse
fidélité). [13]

1.4.3 Les langages de programmation

A propos des langages de programmation nous avons utilisé les langages suivants :

• HTML5

HTML5 (HyperText Markup Language 5) est la

dernière révision majeure du HTML (format de don-
nées conçu pour représenter les pages web). Cette ver-
sion a été finalisée le 28 octobre 2014. [14]

• CSS3

Le CSS pour Cascading Style Sheets est un lan-

gage informatique utilisé sur Internet pour la mise en
forme de fichiers et de pages HTML. [15]

• JavaScript

9
Chapitre 1. Cadre général du projet

JavaScript est un langage de script qui vous permet

de créer du contenu mis à jour dynamiquement, de
contrôler le multimédia, d’animer des images. [16]

• LaTeX
LaTeX souvent stylisé comme La T E X ,est un sys-
tème logiciel pour la préparation de documents. Lors
de l’écriture, l’auteur utilise du texte brut par oppo-
sition au texte formaté trouvé dans les traitements de
texte WYSIWYG comme Microsoft Word ,LibreOffice
Writer et Pages Apple. [17]

1.4.4 Framework
Comme framework, nous avons utilisé :

• Express JS

Express JS est le framework Web Node le plus popu-

laire et constitue la bibliothèque sous-jacente pour un
certain nombre d’autres frameworks Web Node popu-
laires. [18]

1.4.5 Le système de gestion de base de données (SGBD)

Le SGBD que nous avons utilisé est :

• MongoDB

MongoDB est une base de données orientée docu-

ments. En clair, vous bénéficiez de la scalabilité et de
la flexibilité que vous voulez, avec les fonctions d’in-
terrogation et d’indexation qu’il vous faut. [19]

1.4.6 Les bibliothèques et les outils

Lors de la réalisation de notre projet, nous avons recours à utiliser une diversité des
bibliothèques et des outils.

• React JS

React JS est une bibliothèque JavaScript frontale

gratuite et open source pour la création d’interfaces
utilisateur basées sur des composants. [20]

10
Chapitre 1. Cadre général du projet

• Bootstrap
Bootstrap est une infrastructure de développement
frontale, gratuite et open source pour la création de
sites et d’applications Web. L’infrastructure Boots-
trap repose sur HTML, CSS et JavaScript (JS) pour
faciliter le développement de sites et d’applications
réactives et tout-mobile.[21]
• Axios
Axios est un client HTTP basé sur les promesses com-
patible avec [Link] et les navigateurs. Il est isomor-
phique (c’est à dire qu’il peut opérer dans le naviga-
teur et dans [Link] avec le même code).[22]
• Redux
Redux est une bibliothèque compacte qui fournit un
conteneur d’état « predictable state container » pour
les applications JavaScript. Redux est développé par
Dan Abramov depuis mai 2015.[23]

• React Router
React Router est une des bibliothèques qui per-
mettent de transformer une application React en
SPA.[24]
• Reactstrap
Reactstrap est une bibliothèque / un package convi-
vial qui contient des composants React Bootstrap 4
qui fournissent des composants Bootstrap 4 prédéfinis
qui nous aident à concevoir une application réactive
impressionnante avec une expérience utilisateur intui-
tive.[25]
• React Feather
React Feather est une collection d’icônes open
source tout simplement magnifiques pour [Link].
Chaque icône est conçue sur une grille 24x24 en met-
tant l’accent sur la simplicité, la cohérence et la lisi-
bilité.[26]

Conclusion
Dans le présent chapitre, nous avons présenté le cadre général de notre projet de
fin d’études qui englobe la présentation de l’organisme d’accueil, l’étude préalable, les
méthodologies adoptées ainsi que la description de l’environnement de travail. Dans le
chapitre qui suit, nous nous engageons à analyser et spécifier les besoins de notre système.

11
Chapitre 2

Analyse et spécifications des besoins

Introduction
L’étude faite durant la phase de pré-analyse sert généralement de point de départ à
décrire sans ambiguïté l’application à développer. Ainsi pour assurer cet objectif, il est
essentiel d’avoir une vue claire et précise des besoins. C’est pour celà, nous consacrons ce
chapitre à l’analyse et la spécification des besoins en commençant par l’identification des
acteurs, des besoins fonctionnels et non fonctionnels, puis une présentation de notre pro-
duct backlog et de diagramme cas d’utilisation global, et nous finissons par une description
détaillée de l’architecture logicielle de notre projet.

2.1 Planification de projet

Dans une première phase, nous allons identifier les acteurs du système. Puis,nous allons
commencer par dégager les besoins fonctionnels et non fonctionnels.

2.1.1 Identification des acteurs

Dans cette section, nous allons énumérer les acteurs de notre système. Avant tout allons
définir qu’est qu’un acteur, un acteur est une entité externe au système qui intéragit avec
ce dernier. Il peut être une personne ou un autre système informatique. Les acteurs qui
vont intéragir avec notre futur système sont :

• L’étudiant : Il aura l’accès à la plateforme ScientiWorld pour consulter les différents

universités avec ses différentes branches, soumettre son dossier de réorientation,
consulter l’état de son dossier ainsi que consulter les résultats finaux de concours,
etc...

• L’administrateur : C’est l’administrateur d’un université précis. Il aura l’accès à

gérer les différentes branches de son université, planifier le concours de réorientation,
traiter les dossiers des étudiants ainsi que traiter les résultats finaux, etc ...

12
Chapitre 2. Analyse et spécifications des besoins

2.1.2 Les besoins fonctionnels

Notre système est destiné aux étudiants et aux universités pour faciliter et digitaliser
la planification de concours de réorientation ainsi que le traitement des résultats finaux.
Dans cette partie nous allons énumérer les besoins fonctionneles du système par acteur :

L’étudiant peut :
• Créer un compte
• S’authentifier
• Consulter son profil
• Gérer son profil
• Consulter la liste des branches de réorientation
• Créer une demande de réorientatin
• Consulter ses dossiers
• Télécharger sa demande
• Consulter la page d’accueil de chaque université
• Consulter la convocation de concours
• Télécharger la convocation de concours
• Consulter le calendrier d’examen
• Consulter le résultat de concours
• Consulter l’autorisation d’inscription en cas de réussite
• Consulter les résultats finaux
• Télécharger l’autorisation d’inscription en cas de réussite
L’administrateur peut :
• S’authentifier
• Consulter son profil
• Gérer son profil
• Gérer la page d’accueil de son université
• Rechercher les dossiers de réorientation
• Changer l’état des dossiers (conforme, non conforme, non arrivé)
• Gérer les surveillants
• Gérer les salles d’examen
• Gérer les branches de réorientation
• Gérer les matières
• Gérer les calendriers d’examen
• Consulter la liste des étudiants par salle d’examen
• Envoyer le calendrier d’examen aux surveillants par email
• Gèrer les notes des étudiants
• Consulter les résultats finaux

13
Chapitre 2. Analyse et spécifications des besoins

2.1.3 Les besoins non fonctionnels

Quand les besoins fonctionnels expriment les fonctionnalités concrètes du produit,
les besoins non fonctionnels sont des indicateurs de qualité de l’exécution des besoins
fonctionnels. Celles de notre application s’appuient principalement sur :

• Sécurité : L’application devrait veiller à la vie privée et la sécurité de données

personnelles des étudiants.

• Ergonomie : L’application doit être facile à utiliser.

• Fiabilité : L’application doit fonctionner d’une façon cohérente et sans commettre

des erreurs.

• Maintenabilité : Le code source doit être lisible, compréhensible et bien commenté

pour faciliter sa maintenance.

2.2 Structure et découpage de projet avec SCRUM

2.2.1 Equipe SCRUM

Comme nous allons noté précedement, SCRUM est composé par 3 rôles :

• Product Owner

• SCRUM Master

• Equipe de développement

La figure ci-dessous met en valeur ses différents rôles.

14
Chapitre 2. Analyse et spécifications des besoins

Fig. 4 : L’équipe SCRUM

2.2.2 Product Backlog

Le product backlog est défini par le guide scrum comme étant “une liste ordonnée et
émergente de ce qui est nécessaire pour améliorer le produit”. [27]
Le tableau ci-dessous représente le product backlog de notre système.

Tab. 3 : Product Backlog

ID Thème User Story Priorité Compléxité

Gestion d’accès En tant qu’étudiant je veux créer un compte Haute Moyenne
et de profil
1 En tant qu’étudiant je veux m’authentifier Haute Moyenne
En tant qu’administrateur je veux m’authen- Haute Moyenne
tifier
En tant qu’administrateur je veux éditer les Moyenne Moyenne
informations de mon profil
En tant qu’étudiant je veux éditer les infor- Moyenne Moyenne
mations de mon profil
Gestion des dos- En tant qu’étudiant je veux consulter la liste Haute Moyenne
siers de réorien- des branches de réorientation
2
tation
En tant qu’étudiant je veux créer une de- Haute Haute
mande de réorientation
En tant qu’étudiant je veux consulter ma de- Haute Moyenne
mande de réorientation
En tant qu’étudiant je veux télécharger ma Moyenne Haute
demande de réorientation

15
Chapitre 2. Analyse et spécifications des besoins

Gestion de la En tant qu’administrateur je veux gérer la Basse Haute

3
page d’accueil page d’accueil
de la plateforme
En tant qu’étudiant je veux consulter la page Basse Moyenne
d’accueil de la plateforme
Traitement des En tant qu’administrateur je veux faire la re- Haute Haute
4
dossiers cherche d’un dossier de réorientation.
En tant qu’administrateur je veux changer Haute Basse
l’état des dossiers
Planification de En tant qu’administrateur je veux gérer les Haute Moyenne
concours surveillants
En tant qu’administrateur je veux gérer les Haute Moyenne
salles d’examen
En tant qu’administrateur je veux gérer les Haute Moyenne
branches de réorientation
5 En tant qu’administrateur je veux gérer les Haute Moyenne
matières
En tant qu’administrateur je veux gérer les Haute Haute
calendriers d’examen
En tant que système je veux affecter les étu- Haute Haute
diants aux salles
En tant qu’administrateur je veux consulter Haute Moyenne
liste étudiants par salles d’examen
En tant qu’étudiant je veux consulter la Moyenne Moyenne
convocation d’examen
En tant qu’étudiant je veux télécharger la Moyenne Haute
convocation d’examen
En tant qu’étudiant je veux consulter le ca- Moyenne Moyenne
lendrier d’examen
En tant qu’administrateur je veux envoyer Moyenne Haute
le calendrier d’examen aux surveillants par
email
Traitement des En tant qu’administrateur je veux gérer les Haute Haute
résultats finaux notes
En tant que système je veux affecter les étu- Haute Haute
diants aux spécialités
En tant qu’administrateur je veux consulter Haute Moyenne
6
les résultats finaux
En tant qu’étudiant je veux consulter le ré- Haute Moyenne
sultat d’examen
En tant qu’étudiant je veux télécharger l’au- Haute Haute
torisation d’inscription en cas de réussite

16
Chapitre 2. Analyse et spécifications des besoins

2.2.3 Planification des sprints

La planification des sprints est une étape primordiale dans la réalisation des projets
SCRUM. Notre projet sera décortiqué en 2 releases qui sont composés par 7 sprints. La
figure ci-après représente la décompostion des releases en des sprints.

Fig. 5 : Planification des sprints

2.3 Architecture logicielle adoptée

Pour la réalisation de notre application, on a opté à l’architecture n-tiers.

Fig. 6 : L’architecture n-tiers

2.3.1 La couche de présentation

Ou encore appelée IHM (Interaction Homme Machine). Elle permet l’intéraction de
l’application avec l’utilisateur. Cette couche gère les saisies au clavier, les actions avec la

17
Chapitre 2. Analyse et spécifications des besoins

souris et la présentation des informations à l’écran. Dans notre cas, la couche présentation
est réalisée avec React JS.
Cette couche utilise le modèle Redux de React JS pour gérer l’état de l’interface
utilisateur. Redux est une bibliothèque de gestion d’état pour les applications JavaScript,
qui fournit une façon maintenable de gestion d’état de l’application. En utilisant Redux,
nous sommes en mesure de centraliser l’état de notre application dans un ”store” global,
qui est accessible à tous les composants de notre application. Cela nous permet de gérer
facilement l’état de l’interface utilisateur, tout en gardant notre logique métier et notre
accès aux données dans les autres couches de notre architecture n-tiers.
En fait, React ne gère que l’interface de l’application, considérée comme la vue dans
le modèle MVC.
Le modèle Redux se compose par plusieurs parties principales :

• Store : Le store est le conteneur de l’état global de l’application. Il contient toutes

les données que l’application utilise pour fonctionner, les mises à jour de cet état
sont réalisées grâce aux actions.

• Actions : Les actions sont des objets JavaScript qui représentent des événements qui
surviennent au sein de l’application, comme un clic sur un bouton ou la soumission
d’un formulaire. Les actions sont envoyées au store pour mettre à jour l’état de
l’application.

• Reducers : Les reducers sont des fonctions pures qui prennent l’état actuel de
l’application et une action en entrée, et renvoient un nouvel état en sortie. Les
reducers sont chargés de traiter les actions et de mettre à jour l’état de l’application.

• Middleware : Les middlewares sont des fonctions qui interceptent les actions avant
qu’elles n’atteignent les reducers.

Ces différentes parties intéragissent de la manière suivante :

• Lorsqu’une action est créée, elle est envoyée au store via la fonction dispatch.

• Lorsqu’une action est reçue par le store, il la transmet à tous les reducers enregistrés.
Les reducers examinent l’action et décident s’ils doivent mettre à jour l’état de
l’application en conséquence.

• Les reducers ne modifient jamais directement l’état de l’application, mais créent

plutôt une copie modifiée de l’état.

• Lorsqu’un reducer renvoie un nouvel état, le store met à jour l’état de l’application
avec ce nouvel état.

• Les middlewares peuvent être utilisés pour ajouter des fonctionnalités supplémen-
taires à l’application, telles que la gestion des erreurs ou la journalisation.

Dans l’ensemble, ces différentes parties travaillent ensemble pour permettre à l’ap-
plication de maintenir un état global cohérent et de faciliter la gestion de cet état. Les

18
Chapitre 2. Analyse et spécifications des besoins

actions déclenchent des mises à jour de l’état, les reducers mettent à jour l’état en fonc-
tion des actions, et les middlewares ajoutent des fonctionnalités supplémentaires. Le store
agit comme une sorte de hub central pour toutes ces intéractions, assurant que tout reste
synchronisé et cohérent. La figure ci-dessous résume le méchanisme de fonctionnement de
ce modèle.

Fig. 7 : Méchanisme de fonctionnemt de Redux

2.3.2 La couche applicative

Elle représente la partie traitement de l’application qui est réalisée avec Express JS
dans notre projet.

2.3.3 La couche accès aux données

Elle regroupe l’ensemble des mécanismes qui permettent la gestion des informations
stockées par l’application. Dans notre projet, nous avons opté pour une base de données
NoSQL orientée documents avec MongoDB.
Une base de données orientée documents est un type spécifique de base de données
qui fonctionne sur le principe de traiter des « documents » plutôt que des tableaux d’in-
formations strictement définis. [28]

Conclusion
Après l’analyse approfondie des be de notre projet, le chapitre suivant sera consacré
à l’implémentation de notre premier release.

19
Chapitre 3

Release 1 : Planification de concours

et le traitement des dossiers

Introduction
Durant ce chapitre, nous traitons le premier release qui se rapporte à la « Planification
de concours et le traitement des dossiers », en évoquant l’analyse, la conception et la
réalisation des ses différents sprints, afin d’aboutir à un incrément potentiellement livrable.
Notre premier release se prolonge de 6 Février jusqu’à 3 Avril.

3.1 Organisation des sprints

Notre release est composé par 4 sprints :

• Sprint 1: Gestion d’accès et de profils.

• Sprint 2: Planification de concours.

• Sprint 3: Gestion et traitement des dossiers de réorientation.

• Sprint 4: Gestion de la page d’accueil de la plateforme.

La figure ci-après représente l’organisation de chaque sprint :

20
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 8 : Organisation de sprint

3.2 Sprint 1 : La gestion d’accès et de profils

3.2.1 Sprint goal

L’objectif de ce sprint est de gérer l’accès des utilisateurs à notre plateforme ainsi que
leurs profils. Un étudiant peut créer un compte, se connecter à l’application et gérer son
profil. L’administrateur aussi peut accéder à la plateforme et gérer son profil.

3.2.2 Sprint backlog

Le premier sprint se prolonge du 6 Février jusqu’au 20 Février. Le tableau ci-dessous
représente le backlog de notre premier sprint.

21
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Tab. 4 : Sprint Backlog du sprint 1 release 1

ID User Story ID Tâches Durée

En tant qu’étu- 1.1 La réalisation de l’interface d’inscription des 2 jours
1 diant je veux étudiants à la plateforme
créer compte
1.2 La réalisation de contrôle de saisie (nom, pré-
nom, cin, téléphone, code postale, date de
naissance „,) coté frontend
1.3 La réalisation de l’api qui permet la création
d’un nouveau étudiant
1.4 La réalisation de contrôle de saisie (nom, pré-
nom, cin, téléphone, code postale, date de
naissance „,) coté backend
1.5 La liaision de la partie frontend avec la partie
backend
1.6 Le test et la validation d’inscription d’un étu-
diant
En tant qu’étu- 2.1 La réalisation de l’interface d’authentifica- 2 jours
2 diant je veux tion
m’authentifier
2.2 La création de validation des champs (email
et mot de passe) coté frontend
2.3 La réalisation de l’api qui permet l’accès d’un
étudiant à la plateforme
2.4 La liaision de la partie frontend avec la partie
backend
2.5 Le test et la validation de l’accès d’un étu-
diant à la plateforme
En tant qu’ad- 3.1 La réalisation de l’interface d’authentifica- 2 jours
3 ministrateur je tion
veux m’authen-
tifier
3.2 La création de validation des champs (email
et mot de passe) coté frontend
3.3 La réalisation de l’api qui permet l’accès d’un
administrateur à la plateforme
3.4 La liaision de la partie frontend avec la partie
backend
3.5 Le test et la validation de l’accès d’un admi-
nistrateur à la plateforme
En tant qu’étu- 4.1 La création de l’interface de consultation de 2 jours
4 diant je veux profil
consulter mon
profil

22
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

4.2 La réalisation de l’api qui permet la récupé-

ration des informations personnels d’un étu-
diant
4.3 La liaision de la partie frontend avec la partie
backend
4.4 Le test et la validation de la consultation
d’un profil étudiant
En tant qu’étu- 5.1 La création de validation des champs (nom, 2 jours
5 diant je veux prénom, cin, téléphone, code postale, date de
éditer mon profil naissance, email, mot de passe „,) coté fron-
tend
5.2 La réalisation de l’api qui permet la mise à
jour d’un profil étudiant
5.3 La création de validation des champs (nom,
prénom, cin, téléphone, code postale, date de
naissance „,) coté backend
5.4 Le test et la validation de la mise à jour d’un
profil étudiant
En tant qu’ad- 6.1 La création de l’interface de consultation de 2 jours
6 ministrateur je profil
veux consulter
mon profil
6.2 La réalisation de l’api qui permet la récupé-
ration des informations personnels d’un ad-
ministrateur
6.3 La liaision de la partie frontend avec la partie
backend
6.4 Le test et la validation de la consultation
d’un profil administrateur
En tant qu’ad- 7.1 La création de validation des champs (nom, 2 jours
7 ministrateur je prénom, email, mot de passe „,) coté fron-
veux éditer mon tend
profil
7.2 La réalisation de l’api qui permet la mise à
jour d’un profil étudiant
7.3 La création de validation des champs (nom,
prénom, email, mot de passe „,) coté backend
7.4 Le test et la validation de la mise à jour d’un
profil administrateur

23
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

3.2.3 Implémentation de sprint 1

[Link] Spécification des besoins

Dans cette section, nous allons détailler les besoins de notre premier sprint, en dé-
finissant son diagramme des cas d’utilisation, les descriptions textuelles des différents
cas d’utilisation, et les maquettes. Nous allons également identifier les diagrammes de
séquences système.
Cette partie sera un guide précieux pour l’équipe de développement, en lui fournissant
une vision claire et détaillée des exigences à respecter pour la réalisation du premier sprint.
La figure ci-après représente le diagramme cas d’utilisation de notre sprint :

Fig. 9 : Diagramme des cas d’utilisation sprint 1 release 1

Vu que le diagramme des cas d’utilisation ne décrit pas de façon détaillée le dialogue
entre les acteurs et les cas d’utilisation, nous avons préféré de présenter les descriptions
textuelles des différents cas d’utilisations comme indiquent les tableaux ci dessous :

24
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Tab. 5 : Description textuelle du cas d’utilisation « Créer un compte »

Cas d’utilisation Créer un compte

Acteur Étudiant
Pré condition L’étudiant demande l’interface d’inscription
Post condition Compte étudiant crée
Scénario nominal
2. Le système affiche la page d’inscription.
3. L’étudiant remplit le formulaire par les champs nécessaires.
4. L’étudiant clique sur le bouton ”s’inscrire” pour valider les
données saisies.
5. Le système vérifie les champs saisies par l’étudiant
6. Le système affiche un message de succès
7. Le système redirige l’étudiant vers la page d’authentification

Scénario alternatif
5. L’étudiant valide avec un champ obligatoire vide
5.2 Le système affiche un message d’erreur
5.3 Reprise de la 2ème étape du scénario nominal
5. L’étudiant valide avec un champ invalide
5.2 Le système affiche un message d’erreur
5.3 Reprise de la 2ème étape du scénario nominal

Scénario d’erreur
2. Rupture de connexion
3. Panne dans l’ordinateur de l’étudiant

25
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Tab. 6 : Description textuelle du cas d’utilisation « S’authentifier étudiant »

Cas d’utilisation S’authentifier étudiant

Acteur Étudiant
Pré condition L’étudiant dispose d’un compte à ScientiWorld
Post condition L’étudiant accéde à ScientiWorld
Scénario nominal
2. L’étudiant demande l’interface d’authentification
3. Le système affiche la page d’authentification
4. L’étudiant saisie ses identifiants (email et mot de passe) dans
les champs appropiés
5. L’étudiant clique sur le bouton ”connexion” pour valider les
données saisies
6. Le système vérifie les champs saisies par l’étudiant et affiche
un message de succès
7. Le système redirige l’étudiant vers la page d’accueil de Scien-
tiWorld

Scénario alternatif
5. L’étudiant valide avec un champ vide
5.2 Le système affiche un message d’erreur ”Champ obliga-
toire”
5.3 Reprise de la 3éme étape du scénario nominal
5. L’étudiant valide avec un email invalide
5.2 Le système affiche un message d’erreur ”Email invalide”
5.3 Reprise de la 3éme étape du scénario nominal
5. L’étudiant valide avec un email introuvable
5.2 Le système affiche un message d’erreur ”Email n’existe
pas”
5.3 Reprise de la 3éme étape du scénario nominal
5. L’étudiant valide avec un mot de passe incorrect
5.2 Le système affiche un message d’erreur ”Mot de passe in-
correct”
5.3 Reprise de la 3éme étape du scénario nominal

Scénario d’erreur
2. Rupture de connexion
3. Panne dans l’ordinateur de l’étudiant

26
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Remarque : Étant donné que le cas d’utilisation « S’authentifier administrateur » a

le même principe que « S’authentifier étudiant », nous avons opté de ne pas présenter sa
description textuelle.

Tab. 7 : Description textuelle du cas d’utilisation « Consulter profil étudiant »

Cas d’utilisation Consulter profil étudiant

Acteur Étudiant
Pré condition L’étudiant est authentifié
Post condition Le profil de l’étudiant est affiché
Scénario nominal
2. L’étudiant clique sur le bouton ”profil”
3. Le système affiche les informations de l’étudiant dans un for-
mulaire

Scénario alternatif Néant

Scénario d’erreur
2. Rupture de connexion
3. Panne dans l’ordinateur de l’étudiant

Tab. 8 : Description textuelle du cas d’utilisation « Éditer profil étudiant »

Cas d’utilisation Éditer profil étudiant

Acteur Étudiant
Pré condition L’étudiant consulte son profil
Post condition Le profil de l’étudiant est édité
Scénario nominal
2. L’étudiant modifie ses informations (cin, nom, prénom, email,
section de baccalauréat „, )
3. L’étudiant clique sur le bouton ”Sauvegarder” pour valider les
données saisies
4. Le système vérifie les champs saisies par l’étudiant et affiche
un message de succès ”Utilisateur modifié”
5. Le système redirige l’étudiant vers la page d’accueil de Scien-
tiWorld

Scénario alternatif
3. L’étudiant valide avec un champ obligatoire vide ou invalide
3.2 Le système affiche un message d’erreur.
3.3 Reprise de la 1ére étape du scénario nominal

27
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Remarque : Étant donné que les cas d’utilisation « Consulter profil administrateur »
et «Éditer profil administrateur» ont le même principe que, respectivement, « Consulter
profil étudiant » et « Éditer profil étudiant » , nous avons opté de ne pas présenter leurs
descriptions textuelles.
Avant de se lancer dans la production de notre plateforme, nous avons opté de pré-
parer une maquette. Cette dernière nous permet de détecter et de corriger les problèmes
d’ergonomie et de convivialité avant la mise en production, c’est pour celà le maquetage
est une étape primordiale dans le processus de conception d’un logiciel.
Les figures ci-dessous représentent quelques maquettes de notre premier sprint :

Fig. 10 : Maquette de création d’un compte étudiant

28
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 11 : Maquette de la mise à jour d’un profil étudiant

Afin de mieux comprendre les intéractions entre les différents éléments du système et
de visualiser l’ordre d’exécution des tâches, nous avons opté à réaliser les diagrammes de
séquence systèmes représentés ci-dessous :
La figure ci-après représente le diagramme de séquence système de cas d’utilisation
«Créer compte étudiant».

29
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 12 : Diagramme de séquence système de CU « Créer compte étudiant »

Ci-dessous, le diagramme de séquence système de CU «S’authentifier étudiant».

30
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 13 : Diagramme de séquence système de « S’authentifier étudiant »

Remarque : Étant donné que le cas d’utilisation « S’authentifier administrateur » a

le même principe que « S’authentifier étudiant », nous avons opté de ne pas présenter son
diagramme de séquence système.

Fig. 14 : Diagramme de séquence système de « Consulter profil étudiant »

31
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 15 : Diagramme de séquence système de « Éditer profil étudiant »

Remarque : Étant donné que les cas d’utilisation « Consulter profil administrateur »
et «Éditer profil administrateur» ont le même principe que, respectivement, « Consulter
profil étudiant » et « Éditer profil étudiant » , nous avons opté de ne pas présenter leurs
diagrammes de séquence système.

[Link] Analyse détaillée

Dans cette section, nous allons procéder à une analyse détaillée en examinant les
différents diagrammes de classes participantes, afin de mieux comprendre la structure et
les intéractions entre les différents éléments du système.

32
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 16 : Diagramme de classes participantes de CU « Créer compte étudiant »

Fig. 17 : Diagramme de classes participantes de CU «S’authentifier étudiant »

Remarque : Comme le cas d’utilisation «S’authentifier administrateur» suit le même

principe que «S’authentifier étudiant», nous avons décidé de ne pas inclure son diagramme
de classes participantes afin d’éviter toute redondance inutile.

33
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 18 : Diagramme de classes participantes de CU «Consulter et éditer profil étudiant»

Remarque : Veuillez noter que le cas d’utilisation «Consulter et éditer profil admi-
nistrateur» suit le même schéma que «Consulter et éditer profil étudiant». Pour éviter
toute redondance inutile, nous avons choisi de ne pas inclure le diagramme de classes
participantes correspondant dans cette section.

[Link] Conception

Après avoir présenter les diagrammes de classes participantes des différents cas d’utili-
sation de notre premier sprint, cette partie sera consacrée à la présentation de diagramme
de classes de conception de notre sprint et les diagrammes de séquence de conception des
différents cas d’utilisation.

34
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 19 : Diagramme de classes de conception de sprint 1 release 1.

La classe Teacher renseigne les enseignants et les administrateurs des universités ins-
crits à la plateforme ScientiWorld.
Notez bien : Vu que notre solution sera intégrée dans la plateforme ScientiWorld,
les classes Student, Teacher et Company disposent d’autres attributs et méthodes spéci-
fiques aux autres modules de la plateforme, c’est pourquoi nous avons opté de présenter
seulement les attributs et les méthodes qui concernent le module de réorientation dans
les diagrammes de classes de conception pour éviter leurs encombrements.
La figure ci-après illustre le diagramme de séquence de conception de cas d’utilisation
«Créer compte étudiant».

35
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 20 : Diagramme de séquence de conception de CU «Créer compte étudiant»

36
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Ci-dessous nous présentons le diagramme de séquence de conception de cas d’utilisa-

tion «S’authentifier étudiant».

Fig. 21 : Diagramme de séquence de conception de CU «S’authentifier étudiant»

Le diagramme suivant représente le diagramme de séquence de conception de cas

d’utilisation «Consulter profil étudiant».

37
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 22 : Diagramme de séquence de conception de CU «Consulter profil étudiant»

Et concernant le diagramme ci-après, il représente le diagramme de séquence de

conception de cas d’utilisation «Editer profil étudiant».

Fig. 23 : Diagramme de séquence de conception de CU «Editer profil étudiant»

38
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

[Link] La réalisation

Dans cette section, nous présentons quelques interfaces graphiques de notre premier
sprint. La figure 24 illustre la page d’authentification de la plateforme ScientiWorld.

Fig. 24 : Interface graphique de l’authentification

La figure 25 représente la page d’accueil de la plateforme qui regroupe les différents

modules de ScientiWorld : Module de réorientation universitaire, module de mutation
universitaire, module PlagPrevent (antiplagiat), module E-Learning, etc...

Fig. 25 : Interface graphique de la page d’accueil de ScientiWorld

La figure 26 renseigne l’interface graphique de la consultation et de la modification

39
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

d’un profil administrateur, ce dernier peut éditer son nom, son prénom, son email, numéro
de téléphone ainsi que son mot de passe.

Fig. 26 : Interface graphique de la consultation et la modification d’un profil administra-

teur

La figure 27 représente l’interface graphique de la consultation et la modification d’un

profil étudiant.

Fig. 27 : Interface graphique de la consultation et la modification d’un profil étudiant

40
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

[Link] Le test

Après avoir présenter quelques interfaces graphiques de notre plateforme, nous allons
aborder la phase de test que nous avons effectuée afin de garantir la qualité et le bon
fonctionnement de l’application.
La figure ci-dessous illustre le test des champs obligatoires dans l’interface d’authenti-
fication, si un utilisateur (étudiant ou administrateur) clique sur le bouton ”Connexion”
sans avoir remplir les champs email et mot de passe, des messages d’erreurs apparaissent.

Fig. 28 : Test des champs obligatoires

La figure suivante renseigne le test si un utilisateur (étudiant ou administrateur) saisit

un email introuvable.

41
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 29 : Test de compte introuvable

La figure ci-dessous représente le message d’erreur qui s’affiche si un utilisateur saisit

un mot de passe incorrect

Fig. 30 : Test de mot de passe incorrect

La figure ci-après représente le contrôle de saisie dans l’interface de modification d’un

compte étudiant. Par exemple, si un étudiant valide le formulaire avec un cin contenant
6 chiffres, le message ”CIN doit contenir 8 chiffres” est affiché,

42
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 31 : Test des champs invalides

La figure 32 désigne le message de succès affiché si toutes les données saisies par
l’étudiant sont valides.

Fig. 32 : Message de succès

3.2.4 Sprint review

Nous avons prévu une réunion chez Technix à la fin de ce sprint pour évaluer notre dé-
marche de travail par rapport aux besoins du client tout en respectant les délais convenus.

43
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Pendant cette réunion, nous présentons notre incrément à travers une démonstration :

• La création d’un compte étudiant.

• L’accès à la plateforme ScientiWorld.

• La consultation et la modification d’un compte étudiant.

• La consultation et la modification d’un compte administrateur.

3.2.5 Sprint rétrospective

Suite à la revue de sprint, nous avons tenu une réunion de rétrospective pour explorer
les moyens d’améliorer la qualité et l’efficacité de notre application.

• Ce qui s’est bien passé : Une bonne intégration avec l’équipe Technix.

• Ce qui n’est pas bien passé : Difficulté de saisir la bibliothèque React.

3.3 Sprint 2 : La planification du concours

3.3.1 Sprint goal

L’objectif de ce sprint est de planifier le concours de réorientation, un administrateur
va gérer les branches de réorientation de chaque faculté de son université ainsi que les
matières de l’examen, les salles d’examen et les surveillants.

3.3.2 Sprint backlog

Notre deuxième sprint se prolonge du 21 Février jusqu’au 6 Mars. Le tableau ci-dessous
représente le backlog de notre sprint.

44
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Tab. 9 : Sprint Backlog du sprint 2 release 1

ID User Story ID Tâches Durée

En tant qu’adminis- 1.1 La création de la table matière Demi journée
1 trateur je veux créer
une matière
1.2 La réalisation de l’interface d’ajout d’une
matière
1.3 La réalisation de controle de saisie (nom de
la matière)
1.4 La réalisation de l’api qui permet la création
d’une nouvelle matière
1.5 La liaision de la partie frontend avec la partie
backend
1.6 Le test et la validation de la création d’une
matière
En tant qu’adminis- 2.1 La réalisation de l’interface de modification Demi journée
2 trateur je veux modi- d’une matière
fier une matière
2.2 La création de validation des champs (nom
de la matière)
2.3 La réalisation de l’api qui permet la modifi-
cation d’une matière
2.4 La liaision de la partie frontend avec la partie
backend
2.5 Le test et la validation de la modification
d’une matière
En tant qu’adminis- 3.1 La réalisation de l’interface de consultation Demi journée
3 trateur je veux consul- de la liste des matières
ter la liste des ma-
tières
3.2 La réalisation de l’api qui permet de récupé-
rer la liste des matières
3.3 La liaision de la partie frontend avec la partie
backend
3.4 Le test et la validation de la consultation de
la liste des matières
En tant qu’adminis- 4.1 La réalisation de l’api qui permet d’archiver Demi journée
4 trateur je veux archi- une matière
ver une matière
4.2 La liaision de la partie frontend avec la partie
backend
4.3 Le test et la validation de l’archivage d’une
matière

45
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

En tant qu’adminis- 5.1 La création de la table salle d’examen Demi journée

5 trateur je veux créer
une salle d’examen
5.2 La réalisation de l’interface d’ajout d’une
salle d’examen
5.3 La réalisation de controle de saisie (nom de
la salle, nombre de places, centre d’examen)
5.4 La réalisation de l’api qui permet la création
d’une nouvelle salle d’examen
5.5 La liaision de la partie frontend avec la partie
backend
5.6 Le test et la validation de la création d’une
salle d’examen
En tant qu’adminis- 6.1 La réalisation de l’interface de modification Demi journée
6 trateur je veux modi- d’une salle
fier une salle
6.2 La création de validation des champs (nom
de la salle, nombre de places, centre d’exa-
men)
6.3 La réalisation de l’api qui permet la modifi-
cation d’une salle
6.4 La liaision de la partie frontend avec la partie
backend
6.5 Le test et la validation de la modification
d’une salle
En tant qu’adminis- 7.1 La réalisation de l’interface de consultation demi journée
7 trateur je veux consul- de la liste des salles
ter la liste des salles
d’examens
7.2 La réalisation de l’api qui permet de récupé-
rer la liste des salles
7.3 La liaision de la partie frontend avec la partie
backend
7.4 Le test et la validation de la consultation de
la liste des salles
En tant qu’adminis- 8.1 La réalisation de l’api qui permet d’archiver Demi journée
8 trateur je veux archi- une salle
ver une salle
8.2 La liaision de la partie frontend avec la partie
backend
8.3 Le test et la validation de l’archivage d’une
salle
En tant qu’adminis- 9.1 La création de l’interface d’ajout d’un sur- Demi journée
9 trateur je veux ajouter veillant
un surveillant

46
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

9.2 La réalisation de controle de saisie (nom,

prénpm, email, faculté ...)
9.3 La réalisation de l’api qui permet l’ajout d’un
nouveau surveillant
9.4 La liaision de la partie frontend avec la partie
backend
9.5 Le test et la validation de la création d’un
nouveau surveillant
En tant qu’adminis- 10.1 La réalisation de l’interface de modification Demi journée
10 trateur je veux modi- d’un surveillant
fier un surveillant
10.2 La création de validation des champs (nom,
prénpm, email, faculté ...)
10.3 La réalisation de l’api qui permet la modifi-
cation d’un surveillant
10.4 La liaision de la partie frontend avec la partie
backend
10.5 Le test et la validation de la modification
d’un surveillant
En tant qu’adminis- 11.1 La réalisation de l’interface de consultation Demi journée
11 trateur je veux consul- de la liste des surveillants
ter la liste des sur-
veillants
11.2 La réalisation de l’api qui permet de récupé-
rer la liste des surveillants
11.3 La liaision de la partie frontend avec la partie
backend
11.4 Le test et la validation de la consultation de
la liste des surveillants
En tant qu’adminis- 12.1 La réalisation de l’api qui permet d’archiver Demi journée
12 trateur je veux archi- un surveillant
ver un surveillant
12.2 La liaision de la partie frontend avec la partie
backend
12.3 Le test et la validation de l’archivage d’un
surveillant
En tant qu’adminis- 13.1 La création de la table branche Demi journée
13 trateur je veux créer
une branche
13.2 La réalisation de l’interface d’ajout d’une
branche
13.3 La réalisation de controle de saisie (nom de
la branche, les matières d’examen à passer
pour cette dernière)
13.4 La réalisation de l’api qui permet la création
d’une nouvelle branche

47
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

13.5 La liaision de la partie frontend avec la partie

backend
13.6 Le test et la validation de la création d’une
branche
En tant qu’adminis- 14.1 La réalisation de l’interface de modification Demi journée
14 trateur je veux modi- d’une branche
fier une branche
14.2 La création de validation des champs
14.3 La réalisation de l’api qui permet la modifi-
cation d’une branche
14.4 La liaision de la partie frontend avec la partie
backend
14.5 Le test et la validation de la modification
d’une branche
En tant qu’admi- 15.1 La réalisation de l’interface de consultation Demi journée
15 nistrateur je veux de la liste des branches
consulter la liste des
branches par faculté
15.2 La réalisation de l’api qui permet de récupé-
rer la liste des branches
15.3 La liaision de la partie frontend avec la partie
backend
15.4 Le test et la validation de la consultation de
la liste des branches
En tant qu’adminis- 16.1 La réalisation de l’api qui permet d’archiver Demi journée
16 trateur je veux archi- une branche
ver une branche
16.2 La liaision de la partie frontend avec la partie
backend
16.3 Le test et la validation de l’archivage d’une
branche
En tant qu’adminis- 17.1 La réalisation du traitement qui permet l’im- Demi journée
17 trateur je veux impor- portation d’une liste des matières
ter une liste des ma-
tières
17.2 La liaision de la partie frontend avec la partie
backend
17.3 Le test et la validation de l’importation d’une
liste des matières
En tant qu’adminis- 18.1 La réalisation du traitement qui permet l’ex- Demi journée
18 trateur je veux expor- portation d’une liste des matières
ter une liste des ma-
tières
18.2 La liaision de la partie frontend avec la partie
backend

48
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

18.3 Le test et la validation de l’exportation d’une

liste des matières
En tant qu’adminis- 19.1 La réalisation du traitement qui permet l’im- Demi journée
19 trateur je veux impor- portation d’une liste des salles
ter une liste des salles
d’examens
19.2 La liaision de la partie frontend avec la partie
backend
19.3 Le test et la validation de l’importation d’une
liste des salles
En tant qu’adminis- 20.1 La réalisation du traitement qui permet l’ex- Demi journée
20 trateur je veux expor- portation d’une liste des salles
ter une liste des salles
20.2 La liaision de la partie frontend avec la partie
backend
20.3 Le test et la validation de l’exportation d’une
liste des salles
En tant qu’adminis- 21.1 La réalisation du traitement qui permet l’im- Demi journée
21 trateur je veux impor- portation d’une liste des surveillants
ter une liste des sur-
veillants
21.2 La liaision de la partie frontend avec la partie
backend
21.3 Le test et la validation de l’importation d’une
liste des surveillants
En tant qu’adminis- 22.1 La réalisation du traitement qui permet l’ex- Demi journée
22 trateur je veux expor- portation d’une liste des surveillants
ter une liste des sur-
veillants
22.2 La liaision de la partie frontend avec la partie
backend
22.3 Le test et la validation de l’exportation d’une
liste des surveillants
En tant qu’adminis- 23.1 La réalisation du traitement qui permet l’im- Demi journée
23 trateur je veux im- portation d’une liste des branches
porter une liste des
branches
23.2 La liaision de la partie frontend avec la partie
backend
23.3 Le test et la validation de l’importation d’une
liste des branches
En tant qu’adminis- 24.1 La réalisation du traitement qui permet l’ex- Demi journée
24 trateur je veux ex- portation d’une liste des branches
porter une liste des
branches

49
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

24.2 La liaision de la partie frontend avec la partie

backend
24.3 Le test et la validation de l’exportation d’une
liste des branches

3.3.3 Implémentation de sprint 2

[Link] Spécification des besoins

La figure ci-après représente le diagramme cas d’utilisation de notre sprint :

Fig. 33 : Diagramme des cas d’utilisation sprint 2 release 1

Ce diagramme cas d’utilisation représente le processus de planification de concours de

réorientation qui se manifeste dans l’ajout, la modification, la suppression, la consultation,
l’importation et l’exportation d’une matière, d’une salle d’examen, d’un surveillant ainsi
qu’une branche.

50
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Dans ce qui suit, nous allons détailler ces cas d’utilisation par leurs descriptions tex-
tuelles.
Tab. 10 : Description textuelle du cas d’utilisation « Ajouter une matière »

Cas d’utilisation Ajouter une matière

Acteur Administrateur de l’université
Pré condition L’authentification
Post condition Message de succés
Scénario nominal
2. L’administrateur demande l’interface d’ajout d’une matière.
3. Le système affiche l’interface.
4. L’administrateur de l’université remplit les champs et valide
5. Le système vérifie les champs saisies par l’administrateur et
affiche un message de succès

Scénario alternatif
3. L’administrateur valide avec un champ obligatoire vide ou in-
valide
3.2 Le système affiche un message d’erreur
3.3 Reprise de la 2ème étape du scénario nominal

51
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Tab. 11 : Description textuelle du cas d’utilisation « Consulter la liste des matières »

Cas d’utilisation Consulter la liste des matières

Acteur Administrateur de l’université
Pré condition L’authentification
Post condition La liste des matières est affichée
Scénario nominal
2. L’administrateur demande l’interface de consultation de la
liste des matières.
3. Le système affiche un tableau qui contient tous les matières.

Scénario alternatif Néant

Tab. 12 : Description textuelle du cas d’utilisation « Modifier une matière »

Cas d’utilisation Modifier une matière

Acteur Administrateur de l’université
Pré condition L’authentification
Post condition Message de succés
Scénario nominal
2. L’administrateur consulte la liste des matières.
3. L’administrateur choisit la matière à modifier et clique sur son
icône de modification.
4. Le système affiche l’interface.
5. L’administrateur de l’université met à jour les données d’une
matière et valide.
6. Le système vérifie les champs saisies par l’administrateur et
affiche un message de succès

Scénario alternatif
4. L’administrateur valide avec un champ obligatoire vide ou in-
valide
4.2 Le système affiche un message d’erreur
4.3 Reprise de la 3ème étape du scénario nominal

52
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Tab. 13 : Description textuelle du cas d’utilisation « Supprimer une matière »

Cas d’utilisation Supprimer une matière

Acteur Administrateur de l’université
Pré condition L’authentification
Post condition Message de succés
Scénario nominal
2. L’administrateur consulte la liste des matières.
3. L’administrateur choisit la matière à supprimer et clique sur
son icône de suppression.
4. Le système affiche un message de confirmation.
4.2 Si l’administrateur confirme la suppression le système af-
fiche un message de succès

Scénario alternatif Néant

Tab. 14 : Description textuelle du cas d’utilisation « Importer une liste des matières »

Cas d’utilisation Importer une liste des matières

Acteur Administrateur de l’université
Pré condition L’authentification
Post condition Message de succés
Scénario nominal
2. L’administrateur dépose un fichier excel qui contient une liste
des matières et clique sur le bouton ”Importer”.
3. Le système vérifie les lignes du fichier excel et affiche un mes-
sage de succès

Scénario alternatif
1. L’administrateur dépose un fichier qui contient une matière
invalide (sans nom par exemple)
1.2 Le système affiche un message d’erreur
1.3 Reprise de la 1ére étape du scénario nominal

53
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Tab. 15 : Description textuelle du cas d’utilisation « Exporter une liste des matières »

Cas d’utilisation Exporter la liste des matières

Acteur Administrateur de l’université
Pré condition L’authentification
Post condition La liste des matières est téléchargée
Scénario nominal
2. L’administrateur clique sur le bouton ”Exporter”.
3. Le système télécharge un fichier excel qui contient la liste des
matières.

Scénario alternatif Néant

Remarque : Vu que la gestion des salles d’examens, des surveillants et des branches
sont identiques à celle des matières, nous avons choisi de ne pas présenter leurs descriptions
textuelles pour éviter tout type de redondance.
Dans cette partie, nous allons présenter quelques maquettes de notre deuxième sprint.

54
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

La figure suivante représente la maquette de la consultation de la liste des matières.

Fig. 34 : Maquette de consultation de la liste des matières

Les figures ci-après sont les maquettes de création et de modification d’une matière.

Fig. 35 : Maquette d’ajout d’une Fig. 36 : Maquette de mise à jour

matière d’une matière

55
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

La figure 37 représente la maquette de la liste des salles d’examens.

Fig. 37 : Maquette de consultation de la liste des salles d’examen

Les figures suivantes sont les maquettes de la création et la modification d’une salle
d’examen.

Fig. 38 : Maquette d’ajout d’une Fig. 39 : Maquette de mise à jour

salle d’examen d’une salle d’examen

56
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

La maquette de la liste des surveillants est illustrée par la figure 40.

Fig. 40 : Maquette de consultation de la liste des surveillants

Les maquettes de création et de modification d’un surveillant sont présentées dans les
figures suivantes.

Fig. 41 : Maquette d’ajout d’un Fig. 42 : Maquette de mise à jour

surveillant d’un surveillant

57
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Les figures ci-après illustrent les diagrammes de séquences systèmes des différents cas
d’utilisation de notre 2ème sprint.
Le diagramme suivant représente le diagramme de séquence système de cas d’utilisa-
tion «Ajouter matière».

Fig. 43 : Diagramme de séquence système de «Ajouter matière»

Ci après, le diagramme de séquence système de cas d’utilisation «Editer matière».

58
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 44 : Diagramme de séquence système de «Editer matière»

Concernant la figure suivant, elle illustre le diagramme de séquence système de cas

d’utilisation «Supprimer matière».

59
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 45 : Diagramme de séquence système de «Supprimer matière»

Le diagramme de séquence système de cas d’utilisation «Importer liste des matières»

est illustré dans la figure 46.

Fig. 46 : Diagramme de séquence système de «Importer liste des matières»

60
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 47 : Diagramme de séquence système de «Exporter liste des matières»

Remarque : Étant donné que les gestion des salles d’examen, des surveillants, des
branches et des matières sont similaires, nous avons décidé de ne pas inclure tous les
diagrammes de séquence système pour éviter les répétitions.

[Link] Analyse détaillée

La figure ci-après représente le diagramme de classes participantes de processus de

gestion des matières.

Fig. 48 : Diagramme de classes participantes de la gestion des matières

[Link] Conception

Dans cette partie nous allons représenter le diagramme de classes de conception, ainsi
que les diagrammes de séquences de conception de notre deuxième Sprint.

61
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 49 : Diagramme de classes de conception de sprint 2 release 1.

Ci-dessous le diagramme de séquence de conception de cas d’utilisation «Créer ma-

tière».

62
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 50 : Diagramme de séquence de conception «Créer matière»

La figure ci-après désigne le diagramme de séquence de conception de cas d’utillisation

«Modifier matière».

63
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 51 : Diagramme de séquence de conception «Editer matière»

Ci-dessous, le diagramme de séquence de conception de cas d’utilisation «Consulter la

liste des matières».

64
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 52 : Diagramme de séquence de conception «Consulter la liste des matières»

[Link] Réalisation

Nous allons présenter dans cette section quelques interfaces graphiques qui ont été
développées lors de notre deuxiéme sprint.

Notez bien : Notre plateforme supporte plusieurs langues (Français, Anglais et

Arabe), dans ce qui suit nous décidons de présenter les captures d’écrans de la plate-
forme en Français.
La figure ci-après représente la liste des matières qui contient le nom de la matière, la
date de création et de modification de cette dernière.

65
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 53 : Interface graphique de la consultation de la liste des matières

La figure 54 illustre le formulaire de la création d’une nouvelle matière, nous avons

opté à créer trois champs : nom de la matière en Français, Anglais et en Arabe pour des
raisons de traduction.

Fig. 54 : Interface graphique de la création d’une nouvelle matière

Pour supprimer un matière, il suffit de cliquer sur l’icône ”Delete”. La figure suivante
représente l’interface graphique de suppression d’une matière.

66
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 55 : Interface graphique de la suppression d’une matière

Concernant la modification d’une matière, il suffit de cliquer sur l’icône ”Edit”, et un

formulaire initialement rempli par les données de la matière à modifier est affiché.
La figure 56 renseigne l’icône de modification d’une matière.

Fig. 56 : Icône de modification d’une matière

La figure 57 représente le formulaire de modification d’une matière.

Fig. 57 : Interface graphique de la modification d’une matière

67
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

La figure ci-après désigne les boutons «Importer» et «Exporter» une liste des matières.

Fig. 58 : Les boutons de «Importer» et «Exporter» liste des matières

Pour exporter la liste des matières, nous cliquons sur le bouton «Exporter» et la liste
des matières en format Excel est téléchargée.

Fig. 59 : Interface graphique de l’exportation de la liste des matières

A propos l’importation d’une liste des matières, nous cliquons sur le bouton «Im-
porter» et l’explorateur des fichiers est ouvert pour choisir le fichier Excel à importer.

Fig. 60 : Interface graphique d’importation d’une liste matière

[Link] Le test

Après avoir exposé certaines des interfaces graphiques de notre plateforme, nous allons
maintenant décrire les tests que nous avons réalisés pour assurer la qualité et le bon
fonctionnement de l’application.

68
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

La figure ci-dessous représente le test des champs obligatoires lors de l’ajout d’une
matière.

Fig. 61 : Test des champs obligatoires lors de l’ajout d’une matière

Si la longueur de nom de la matière ne dépasse pas les 2 caractères l’alerte suivante

est affichée.

Fig. 62 : Prévention d’erreur de nom de matière

69
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Supposé que l’administrateur essaie d’ajouter une matière déjà existane, l’alerte sui-
vante est affiché.

Fig. 63 : Prévention de duplication de matière

3.3.4 Sprint review

À la fin de ce sprint, nous avons planifié une réunion chez Technix pour évaluer notre
approche de travail par rapport aux besoins du client, tout en respectant les délais conve-
nus. Au cours de cette réunion, nous faisons une démonstration de notre incrément.

• La gestion des matières.

• La gestion des salles d’examens.
• La gestion des surveillants.
• La gestion des branches de réorientation.

3.3.5 Sprint rétrospective

• Ce qui s’est bien passé : nous avons terminé ce sprint dans les délais convenus.
• Ce qui n’est pas bien passé : Difficulté de mise en place de pagination dans les
différentes interfaces graphiques.

3.4 Sprint 3 : La gestion et traitement des dossiers

de réorientation

3.4.1 Sprint goal

L’objectif de ce sprint est de permettre à l’étudiant de créer un dossier de réorientation
par université, et de permettre à l’administrateur de cette dernière de changer l’état de
chaque dossier (conforme, non conforme ou non arrivé) par rapport au dossier version
papier arrivé à l’administration de l’université.

70
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

3.4.2 Sprint backlog

Notre troisième sprint se prolonge du 7 Mars jusqu’au 20 Mars. Le tableau ci-dessous
représente le backlog de notre sprint.

Tab. 16 : Sprint Backlog du sprint 3 release 1

ID User Story ID Tâches Durée

En tant qu’étudiant je 1.1 La réalisation de l’interface de consultation 2 jours
1 veux consulter la liste de liste des branches
des branches de ré-
orientation
1.2 La réalisation de l’api qui permet de récupé-
rer la liste des branches
1.3 La liaision de la partie frontend avec la partie
backend
1.4 Le test et la validation de la consultation de
la liste des branches
En tant qu’étudiant 2.1 La création de la table FolderReo 2 jours
2 je veux créer une de-
mande de réorienta-
tion par université
2.2 La réalisation de l’interface de la consultation
de la liste des universités
2.3 La réalisation de l’interface de la création
d’un dossier de réorientation
2.4 La création de validation des champs (noms
des branches, ... )
2.5 La réalisation de l’api qui permet la création
d’un dossier de réorientation
2.6 La liaision de la partie frontend avec la partie
backend
2.7 Le test et la validation de la création d’un
dossier de réorientation
En tant qu’étudiant je 3.1 La réalisation de l’interface de consultation 2 jours
3 veux consulter mes de- des dossiers de réorientation par étudiant
mandes de réorienta-
tion
3.2 La réalisation de l’api qui permet de récupé-
rer la liste des dossiers d’un étudiant
3.3 La liaision de la partie frontend avec la partie
backend
3.4 Le test et la validation de la consultation des
dossiers

71
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

En tant qu’étudiant je 4.1 La réalisation d’un api qui permet de récu- 2 jours
4 veux télécharger ma pérer les détails d’un dossier
demande de réorienta-
tion
4.2 La génération d’un fichier PDF contenant la
demande de réorientation
En tant qu’adminis- 5.1 La création de l’interface de consultation des 2 jours
5 trateur je veux consul- tous les dossiers de réorientation par univer-
ter les dossiers de sité
réorientation de mon
université
5.2 La réalisation de l’api qui permet de récupé-
rer la liste des dossiers
5.3 La liaison de la partie frontend avec la partie
backend
5.4 Le test et la validation de la consultation des
dossiers
En tant qu’adminis- 6.1 La création des champs pour la recherche des 2 jours
6 trateur je veux recher- dossiers dans l’interface de consultation des
cher les dossiers de ré- dossiers de réorientation
orientation
6.2 La réalisation de l’api qui permet de recher-
cher un dossier selon plusieurs filtres
6.3 La liaison de la partie frontend avec la partie
backend
6.4 Le test et la validation de la recherche d’un
dossier de réorientation
En tant qu’adminis- 7.1 La réalisation de l’interface de changement 2 jours
7 trateur je veux chan- d’un état de dossier
ger état des dossiers
7.2 La réalisation de l’api qui permet de modifier
l’état d’un dossier
7.3 La liaison de la partie frontend avec la partie
backend
7.4 Le test et la validation de changement d’un
dossier de réorientation

3.4.3 Implémentation de sprint 3

[Link] Spécification des besoins

La figure ci-après représente le diagramme cas d’utilisation de notre sprint :

72
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 64 : Diagramme des cas d’utilisation sprint 3

Le diagramme de cas d’utilisation décrit la gestion des dossiers de réorientation. Ce

processus implique la création d’un dossier de réorientation par un étudiant pour une
université donnée, après avoir consulté la liste des filières disponibles. L’état du dossier
peut ensuite être modifié par l’administrateur de l’université après consultation de toutes
les demandes de son établissement.
Dans la suite, nous allons détailler ces cas d’utilisation en fournissant ses descriptions
textuelles.

73
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Tab. 17 : Description textuelle du cas d’utilisation « Consulter les branches de réorientation »

Cas d’utilisation Consulter les branches de réorientation

Acteur Etudiant
Pré condition L’authentification
Post condition La liste des différentes branches est affichée
Scénario nominal
2. L’étudiant clique sur «Liste des branches» dans le menu.
3. Le système affiche la page contenant la liste des universités.
4. L’étudiant clique sur une université.
5. Le système affiche la liste des facultés de cette université.
6. L’étudiant clique sur une faculté.
7. Le système affiche la liste des filières de cette faculté.

Scénario alternatif Néant

74
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Tab. 18 : Description textuelle du cas d’utilisation « Créer une demande de réorientation »

Cas d’utilisation Créer une demande de réorientation

Acteur Etudiant
Pré condition L’authentification
Post condition La demande de réorientation est crée
Scénario nominal
2. L’étudiant clique sur «Dossier de réorientation» dans le menu.
3. Le système affiche la page contenant la liste des demandes de
réorientation.
4. L’étudiant clique sur le bouton ”Créer une demande de ré-
orientation”.
5. Le système affiche un formulaire remplit par les données de
l’étudiant.
6. Si l’étudiant veut changer ses données, il remplit le formulaire.
7. L’étudiant clique sur le bouton ”Je valide mes informations”
8. Le système redirectionne l’étudiant vers une page contenant
la liste des universités.
9. L’étudiant clique sur une université.
10. Le système redirectionne l’étudiant vers la page de demande.
11. L’étudiant remplit le formulaire par ses choix et valide

Scénario alternatif
5. L’étudiant valide le formulaire avec un champ invalide
5.2 Le système affiche un message d’erreur
5.3 Reprise de la 4éme étape du scénario nominal
10. L’étudiant ajoute la même filière 2 fois.
10.2 Le système affiche un message d’erreur
10.3 Reprise de la 10éme étape du scénario nominal

75
 Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Tab. 19 : Description textuelle du cas d’utilisation « Télécharger une demande de réorientation »

Cas d’utilisation Télécharger une demande de réorientation

Acteur Etudiant
Pré condition L’authentification
Post condition La demande de réorientation est téléchargée
Scénario nominal
2. L’étudiant clique sur «Dossier de réorientation» dans le menu.
3. Le système affiche la page contenant la liste des demandes de
réorientation.
4. L’étudiant clique sur l’icône ”Imprimer”.
5. Le système télécharge la demande sous format PDF.

Scénario alternatif Néant

Tab. 20 : Description textuelle du cas d’utilisation « Rechercher un dossier de réorientation »

Cas d’utilisation Rechercher un dossier de réorientation

Acteur Administrateur de l’université
Pré condition L’authentification
Post condition Dossier de réorientation trouvé
Scénario nominal
2. L’administrateur clique sur « Les demandes » dans le menu.
3. Le système affiche la page contenant la liste des demandes de
réorientation.
4. L’administrateur clique sur le menu déroulant et choisit un
critère de filtrage (nom, prénom, cin, adresse, année de bacca-
luréat, etc ...).
5. Le système affiche un champ pour chaque critère de filtrage
choisi.
6. L’administrateur remplit les champs affichés par les filtres dé-
sirés et clique sur l’icône «Rechercher».
7. Le système affiche le(s) dossier(s) qui vérifie(nt) le critère de
filtrage.

Scénario alternatif
5. L’administrateur clique sur l’icône «Rechercher» avec des
champs invalides
5.2 Le système affiche un message d’erreur
5.3 Reprise de la 4éme étape du scénario nominal

76
 Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Considérez attentivement : Les critères de filtrage d’un dossier de réorientation

dans notre plateforme sont plusieurs, mentionnons : recherche par nom de l’étudiant,
prénom, numéro cin, numéro de téléphone, email, genre (mâle, femelle), état civil, adresse,
cité, governorat, code postale, date de naissance, governorat de naissance, nationalité,
section de baccalauréat, année de baccalauréat, option de baccalauréat, nom de faculté
dans les choix de réorientation et aussi nom des branches.

Tab. 21 : Description textuelle du cas d’utilisation « Changer état d’un dossier de réorientation »

Cas d’utilisation Changer l’état d’un dossier

Acteur Etudiant
Pré condition L’authentification
Post condition L’état de dossier est modifié
Scénario nominal
2. L’administrateur clique sur « Les demandes » dans le menu.
3. Le système affiche la page contenant la liste des demandes de
réorientation.
4. L’administrateur choisit un dossier et clique sur l’icône ”Dé-
tails”.
5. Le système affiche la page contenant les détails d’un dossier
de réorientation choisi.
6. L’administrateur clique sur le menu déroulant et choisit un
état (Conforme, non conforme, ou non arrivée ).
7. L’administrateur clique sur le bouton «Valider».
8. Le système redirectionne l’administrateur vers la page de la
liste des dossiers

Scénario alternatif Néant

Les maquettes présentées ci-dessous illustrent le résultat de notre troisième sprint

et permettent de visualiser les différentes fonctionnalités développées pour répondre aux
besoins identifiés lors de cette étape du projet.
La figure ci-dessous rensigne la première étape de la création d’un dossier de réorien-
tation qui se manifeste à l’édition de profil étudiant (en cas de besoin) et la vérification
des données.

77
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 65 : Maquette de la première étape de la création d’un dossier de réorientation

Après avoir valider le formulaire des données personnelles, le système redirectionne

l’étudiant vers une autre page où il va choisir l’université dans laquelle il va créer la
demande de réorientation. Et finalement, l’interface de choix des filières est affichée. La
figure 66 représente la maquette de cette dernière.

78
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 66 : Maquette de la deuxième étape de la création d’un dossier de réorientation

79
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

La figure ci-après représente la maquette de la consultation et la recherche des dossiers

de réorientation d’une université donnée.

Fig. 67 : Maquette de la consultation et de la recherche d’un dossier de réorientation

Une image vaut plus que mille mots - cette maquette représente une vision concrète
et réaliste de changement d’état d’un dossier.

80
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 68 : Maquette de changement d’état d’un dossier de réorientation

81
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Les schémas de séquences systèmes pour les différents cas d’utilisation de notre troi-
sième sprint sont représentés dans les figures suivantes.

Fig. 69 : Diagramme de séquence système de CU «Consulter la liste des branches»

Le diagramme présenté ci-dessous représente le diagramme de séquence système pour

le cas d’utilisation «Consulter mes demandes de réorientation».

Fig. 70 : Diagramme de séquence système de CU «Consulter mes demandes de réorien-

tation»

82
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Le diagramme ci-dessous renseigne le diagramme de séquence système de cas d’utili-

sation «Créer une demande de réorientation».

Fig. 71 : Diagramme de séquence système de CU «Créer une demande de réorientation»

83
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Le diagramme ci-après représente le diagramme de séquence système de cas d’utilisa-

tion «Télécharger une demande de réorientation»

Fig. 72 : Diagramme de séquence système de CU «Télécharger une demande de réorien-

tation»

Le diagramme ci-dessous renseigne le diagramme de séquence système de cas d’utili-

sation «Consulter les demandes de réorientation de mon université»

Fig. 73 : Diagramme de séquence système de CU «Consulter les demandes de mon uni-

versité»

84
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Ci-après, nous présentons le diagramme de séquence système de cas d’utilisation «Re-

chercher un dossier réorientation».

Fig. 74 : Diagramme de séquence système de CU «Rechercher un dossier de réorientation»

85
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Le diagramme suivant est le diagramme de séquence système de cas d’utilisation

«Changer état d’une demande».

Fig. 75 : Diagramme de séquence système de CU «Changer état d’une demande»

[Link] Analyse détaillée

Ci-dessous, nous présentons le diagramme de classes participantes de cas d’utilisation

«Consulter la liste des branches»

86
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 76 : Diagramme de classes participantes de CU «Consulter la liste des branches»

87
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Le diagramme suivant représente le diagramme de classes participantes de cas d’utili-

sation «Consulter la liste des demandes de réorientation d’un étudiant».

Fig. 77 : Diagramme de classes participantes de CU «Consulter les demandes de réorien-

tation d’un étudiant»

88
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 78 : Diagramme de classes participantes de CU «Créer une demande de réoientation»

89
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 79 : Diagramme de classes participantes de CU «Télécharger une demande de ré-

orientation»

Fig. 80 : Diagramme de classes participantes de CU «Rechercher un dossier de réorien-

tation»

90
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 81 : Diagramme de classes participantes de CU «Changer état d’un dossier»

[Link] Conception

Au cours de cette section, nous allons présenter le diagramme de classes de conception,

ainsi que les diagrammes de séquences de conception correspondant à notre troisième
Sprint.

91
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 82 : Diagramme de classes de conception de sprint 3 release 1.

92
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Le diagramme suivant représente le diagramme de classes de conception de CU «Consul-

ter la liste des demandes de réorientation d’un étudiant»
Dans ce qui suit nous allons présenter les diagrammes de séquence de conception de
notre troisième sprint.

Fig. 83 : Diagramme de séquence de conception de CU «Consulter la liste des branches

de réorientation»

93
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Le diagramme suivant représente le diagramme de séquence de conception de cas

d’utilisation «Consulter mes demandes de réorientation».

Fig. 84 : Diagramme de séquence de conception de CU «Consulter la liste des demandes

de réorientation»

94
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Ci-après nous présentons le diagramme de séquence de conception de la première étape

de la création d’une demande de réorientation «Modifier les informations d’un étudiant».

Fig. 85 : Diagramme de séquence de conception de la première étape de la création d’une

demande de réorientation

Ci-dessous, nous désignons le diagramme de séquence de conception de la deuxième

étape de la création d’une demande de réorientation «Choisir une université».

95
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 86 : Diagramme de séquence de conception de la deuxième étape de la création d’une

demande de réorientation

Et finalement, ce diagramme représente le diagramme de séquence de conception de

notre troisième étape de la création d’une demande de réorientation qui s’articule dans le
choix des branches.

96
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 87 : Diagramme de séquence de conception de la troisième étape de la création d’une

demande de réorientation

Ajoutons à celà le diagramme de séquence de conception de cas d’utilisation «Télé-

charger une demande de réorientation».

Fig. 88 : Diagramme de séquence de conception de CU «Télécharger une demande de

réorientation»

97
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Ci-après, le diagramme de séquence de conception de cas d’utilisation «Consulter les

dossiers de réorientation de mon université».

Fig. 89 : Diagramme de séquence de conception de CU «Consulter les dossiers de réorien-

tation de mon université»

Le diagramme suivant désigne le diagramme de séquence de conception de cas d’uti-

lisation «Rechercher un(des) dossier(s) de réorientation».

Fig. 90 : Diagramme de séquence de conception de CU «Rechercher un(des) dossier(s)

de réorientation»

98
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Ci-contre, nous présentons le diagramme de séquence de conception de cas d’utilisation

«Changer état d’un dossier»

Fig. 91 : Diagramme de séquence de conception de CU «Changer état d’un dossier»

[Link] Réalisation

Dans cette section, nous allons vous montrer quelques interfaces graphiques que nous
avons développées lors de notre troisième sprint.

99
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Après avoir cliquer sur la liste des branches dans le menu la liste des universités est
affichée pour permettre à l’étudiant de choisir une université et de consulter leurs facultés.
La figure 92 représente l’interface graphique de la liste des universités.

Une fois que l’étudiant a consulté la liste des universités et en a sélectionné une, il peut
accéder à la liste de toutes les facultés proposées par cette université et choisir celle qui
l’intéresse afin de consulter les branches correspondantes. La figure 93 illustre l’interface
graphique de la liste des facultés de l’Université de Carthage.

Fig. 92 : Interface graphique de la liste des universités

Fig. 93 : Interface graphique de la liste des facultés

100
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Dans la figure 94 nous illustrons l’interface graphique de la liste des branches de la

faculté ”ENSTA Borj Cedria».

Ci-dessous, nous représentons l’interface graphique de modification des données d’un

étudiant avant avoir créer une nouvelle demande de réorientation dans la figure 95.

Fig. 94 : Interface graphique de la liste des branches

Fig. 95 : Interface graphique de modification des informations d’un étudiant

101
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Vous trouverez dans la figure 96 la représentation de l’interface graphique permettant

la consultation d’une université et le choix d’une, avant de procéder à la création d’une
nouvelle demande de réorientation.

Dans la figure 97, nous présentons l’interface graphique de choix des branches de
réorientation.

Fig. 96 : Interface graphique de consultation et de choix d’une université

Fig. 97 : Interface graphique de choix des branches de réorientation

102
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

La figure 98 illustre l’interface graphique de la troisième étape de création du dossier

de réorientation.

L’interface graphique de consultation de toutes les demandes d’un étudiant est illustrée
dans la figure 99.

Fig. 98 : Interface graphique de la troisième étape de création du dossier de réorientation

Fig. 99 : Interface graphique de consultation de toutes les demandes d’un étudiant.

103
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Ci-après nous désignons l’interface graphique de la liste de toutes les demandes d’une
université donnée dans la figure 100.

En cliquant sur l’icône «Details», le système redirectionne l’administrateur vers la page

de détails d’un dossier pour changer son état tel qu’il est présenté par la figure 101.

Fig. 100 : Interface graphique de la liste de toutes les demandes d’une université donnée

Fig. 101 : Icône détails d’un dossier

104
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Ci-dessous la figure 102 représente l’interface graphique de la consultation des détails

d’un dossier.

La figure 103 ci-après représente l’interface graphique de recherche d’un (des) dossier(s)
de réorientation.

Fig. 102 : Interface graphique de la page de détails d’un dossier

Fig. 103 : Interface graphique de recherche d’un (des) dossier(s)

105
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

3.4.4 Sprint review

Au cours de cette revue, nous allons présenter notre incrément de travail et collecter
les commentaires du notre encadrant afin de nous assurer que nos efforts répondent bien
à ses besoins.

3.4.5 Sprint rétrospective

Ce qui s’est bien passé : Nous avons réussi à résoudre rapidement les problèmes
techniques qui se sont présentés, grâce à l’expertise des membres de l’équipe Technix.
Ce qui n’est pas bien passé : Nous avons rencontré des difficultés lors de la gestion
de la demande de réorientation sous format PDF.

3.5 Sprint 4 : La gestion de la page d’accueil de la

plateforme

3.5.1 Sprint goal

Le but de notre quatrième sprint est de permettre à l’administrateur de l’université de
gérer la page d’accueil de son université en ajoutant les dates de concours, les programmes
à réviser pour chaque matière et les documents nécessaires à envoyer dans le dossier de
réorientation version papier.

3.5.2 Sprint backlog

Le quatrième sprint se prolonge du 21 Mars jusqu’au 3 Avril. Le tableau ci-dessous
représente le backlog de notre quatrième sprint.

106
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Tab. 22 : Sprint Backlog sprint 4 release 1

ID User Story ID Tâches Durée

En tant qu’adminis- 1.1 La création de la table date 1 jour
1 trateur je veux ajouter
une date
1.2 La réalisation de l’interface d’ajout d’une
date
1.3 La réalisation de l’api qui permet la création
d’une nouvelle date
1.4 La liaision de la partie frontend avec la partie
backend
1.5 Le test et la validation de la création d’une
date
En tant qu’adminis- 2.1 La réalisation de l’interface de modification 1 jour
2 trateur je veux modi- d’une date
fier une date
2.2 La réalisation de l’api qui permet la modifi-
cation d’une date
2.3 La liaision de la partie frontend avec la partie
backend
2.4 Le test et la validation de la modification
d’une date
En tant qu’adminis- 3.1 La réalisation de l’interface de consultation 1 jour
3 trateur je veux consul- de la liste des dates
ter la liste des dates
importantes
3.2 La réalisation de l’api qui permet de récupé-
rer la liste des dates
3.3 La liaision de la partie frontend avec la partie
backend
3.4 Le test et la validation de la consultation de
la liste des dates
En tant qu’adminis- 4.1 La réalisation de l’api qui permet d’archiver 1 jour
4 trateur je veux archi- une date
ver une date
4.2 La liaision de la partie frontend avec la partie
backend
4.3 Le test et la validation de l’archivage d’une
date
En tant qu’adminis- 5.1 La création de la table programme 1 jour
5 trateur je veux ajouter
un programme pour
une matière
5.2 La réalisation de l’interface d’ajout d’un pro-
gramme

107
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

5.3 La réalisation de l’api qui permet la création

d’un nouveau programme
5.4 La liaision de la partie frontend avec la partie
backend
5.5 Le test et la validation de la création d’un
programme
En tant qu’adminis- 6.1 La réalisation de l’interface de modification 1 jour
6 trateur je veux modi- d’un programme
fier un programme
6.2 La réalisation de l’api qui permet la modifi-
cation d’un programme
6.3 La liaision de la partie frontend avec la partie
backend
6.4 Le test et la validation de la modification
d’un programme
En tant qu’adminis- 7.1 La réalisation de l’interface de consultation 1 jour
7 trateur je veux consul- de la liste des programmes
ter la liste des pro-
grammes
7.2 La réalisation de l’api qui permet de récupé-
rer la liste des programmes
7.3 La liaision de la partie frontend avec la partie
backend
7.4 Le test et la validation de la consultation de
la liste des programmes
En tant qu’adminis- 8.1 La réalisation de l’api qui permet d’archiver 1 jour
8 trateur je veux archi- un programme
ver un programme
8.2 La liaision de la partie frontend avec la partie
backend
8.3 Le test et la validation de l’archivage d’un
programme
En tant qu’adminis- 9.1 La création de la table document 1 jour
9 trateur je veux ajouter
un document
9.2 La réalisation de l’interface d’ajout d’un do-
cument
9.3 La réalisation de l’api qui permet la création
d’un nouveau document
9.4 La liaision de la partie frontend avec la partie
backend
9.5 Le test et la validation de la création d’un
nouveau document

108
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

En tant qu’adminis- 10.1 La réalisation de l’interface de modification 1 jour

10 trateur je veux modi- d’un document
fier un document
10.2 La réalisation de l’api qui permet la modifi-
cation d’un document
10.3 La liaision de la partie frontend avec la partie
backend
10.4 Le test et la validation de la modification
d’un document
En tant qu’adminis- 11.1 La réalisation de l’api qui permet d’archiver 1 jour
11 trateur je veux archi- un document
ver un document
11.2 La liaision de la partie frontend avec la partie
backend
11.3 Le test et la validation de l’archivage d’un
document

3.5.3 Implémentation de sprint 4

[Link] Spécification des besoins

La figure ci-après illustre le diagramme de cas d’utilisation de sprint 4.

109
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 104 : Diagramme de cas d’utilisation

Le diagramme représenté dans la figure 104 représente le diagrammee de cas d’utilisa-

tion de notre quatrième sprint. Il représente la gestion de la page d’accueil de la plateforme
de réorientation qui se manifeste dans l’ajout, la modification, la suppression et la consul-
tation des dates importantes dans le concours pour chaque université, les programmes à
réviser pour chaque matière et les documents nécessaires pour envoyer une demande de
réorientation.

110
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Dans ce qui suit nous désignons quelques descriptions textuelles de notre quatrième
sprint.

Tab. 23 : Description textuelle du cas d’utilisation « Ajouter un programme »

Cas d’utilisation Ajouter un programme

Acteur Administrateur de l’université
Pré condition L’authentification
Post condition Message de succés
Scénario nominal
2. L’administrateur demande l’interface d’ajout d’un pro-
gramme.
3. Le système affiche l’interface.
4. L’administrateur de l’université remplit les champs et valide
5. Le système vérifie les champs saisies par l’administrateur et
affiche un message de succès

Scénario alternatif
3. L’administrateur valide avec un champ obligatoire vide ou in-
valide
3.2 Le système affiche un message d’erreur
3.3 Reprise de la 2ème étape du scénario nominal

Tab. 24 : Description textuelle du cas d’utilisation « Consulter la liste des programmes »

Cas d’utilisation Consulter la liste des programmes

Acteur Administrateur de l’université
Pré condition L’authentification
Post condition La liste des programmes est affichée
Scénario nominal
2. L’administrateur demande l’interface de consultation de la
liste des programmes.
3. Le système affiche un tableau qui contient tous les pro-
grammes.

Scénario alternatif Néant

111
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Tab. 25 : Description textuelle du cas d’utilisation « Modifier un programme »

Cas d’utilisation Modifier un programme

Acteur Administrateur de l’université
Pré condition L’authentification
Post condition Message de succés
Scénario nominal
2. L’administrateur consulte la liste des programmes.
3. L’administrateur choisit le programme à modifier et clique sur
son icône de modification.
4. Le système affiche l’interface.
5. L’administrateur de l’université met à jour les données d’un
programme et valide.
6. Le système vérifie les champs saisies par l’administrateur et
affiche un message de succès

Scénario alternatif
4. L’administrateur valide avec un champ obligatoire vide ou in-
valide
4.2 Le système affiche un message d’erreur
4.3 Reprise de la 3ème étape du scénario nominal

Tab. 26 : Description textuelle du cas d’utilisation « Supprimer un programme »

Cas d’utilisation Supprimer un programme

Acteur Administrateur de l’université
Pré condition L’authentification
Post condition Message de succés
Scénario nominal
2. L’administrateur consulte la liste des programmes.
3. L’administrateur choisit le programme à supprimer et clique
sur son icône de suppression.
4. Le système affiche un message de confirmation.
4.2 Si l’administrateur confirme la suppression le système af-
fiche un message de succès

Scénario alternatif Néant

Remarque : Etant donné que la gestion des documents et des dates sont similaires à la
gestion des programmes, nous avons opté de ne pas présenter leurs descriptions textuelles.
Dans la suite nous allons présenter la maquette de notre quatrième sprint.

112
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 105 : Maquette de la page d’accueil de la plateforme

113
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Les figures ci-après désignent les diagrammes de séquences systèmes des différents cas
d’utilisation de notre 4ème sprint.

Fig. 106 : Diagramme de séquence système de CU «Ajouter un programme»

114
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Le diagramme suivant représente le diagramme de séquence système de CU « Consulter

la liste des programmes ».

Fig. 107 : Diagramme de séquence système de CU « Consulter la liste des programmes »

115
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Ci-dessous le diagramme de séquence système de CU «Modifier un programme»

Fig. 108 : Diagramme de séquence système de CU «Modifier un programme»

116
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Ci-après le diagramme de séquence système de cas d’utilisation «Supprimer un pro-

gramme».

Fig. 109 : Diagramme de séquence système de CU «Supprimer un programme»

Remarque : Vu que les gestions des programmes, des documents et des dates sont
presque identiques, nous avons opté de ne pas inclure tous les diagrammes de séquence
système afin d’éviter tout type de redondance.

[Link] Analyse détaillée

La figure 110 représente le diagramme de classes participantes de la gestion des pro-

grammes.

Fig. 110 : Diagramme de classes participantes de la gestion des programmes

117
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

[Link] Conception

Cette partie sera consacré à représenter le diagramme de classes de conception ainsi

que les diagrammes de séquence de conception de notre quatrième Sprint.

118
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 111 : Diagramme de classes de conception de sprint 4 release 1.

119
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Ci-dessous, les diagrammes de séquence de conception de la gestion des programmes.

Fig. 112 : Diagramme de séquence de conception de CU «Consulter la liste des pro-

grammes»

Fig. 113 : Diagramme de séquence de conception de CU «Créer un programme»

120
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Fig. 114 : Diagramme de séquence de conception de CU «Modifier un programme»

[Link] Réalisation

Dans cette partie nous visons à présenter quelques interfaces graphiques de notre
quatrième sprint. La figure ci-après représente l’interface graphique qui permette à l’ad-
ministrateur de consulter les différentes programmes pour chaque matière.

Fig. 115 : Interface graphique de la liste des programmes

121
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

La figure ci-après représente l’interface graphique d’ajout d’un nouveau programme.

Fig. 116 : Interface graphique d’ajout d’un nouveau programme

La figure ci-dessous représente l’interface de la page d’accueil affichée aux étudiants.

Fig. 117 : Interface graphique de la page d’accueil de la plateforme

122
Chapitre 3. Release 1 : Planification de concours et le traitement des
dossiers

Un étudiant peut choisir une université pour consulter ses détails. La figure suivante
illustre les détails de l’université de Carthage.

Fig. 118 : Interface graphique des détails d’une université

3.5.4 Sprint review

A la fin de ce sprint, nous avons montré les tâches demandées :

• Gérer les délais (les dates)

• Gérer les programmes de chaque matière

• Gérer les documents nécessaires

3.5.5 Sprint rétrospective

Ce qui s’est bien passé : Nous avons réussi à compléter les users stories de ce sprint
rapidement et en respectant les délais.
Ce qui n’est pas bien passé : La mise en page de l’interface étudiant n’est pas
facile.

Conclusion
Ce chapitre nous a permis d’étudier le processus de planification de concours et de
traitement des dossiers avec ces différents étapes. Le chapitre suivant sera consacré à
détailler la partie planification intelligente de concours et le traitement des résultats.

123
Chapitre 4

Release 2 : Planification intelligente

de concours et le traitement des
résultats

Introduction
Au cours de ce chapitre, nous examinerons le deuxième release de notre projet qui se
rapporte à «La planification intelligente de concours et le traitement des résultats finaux».
Notre release s’étend de 4 Avril jusqu’à 15 Mai.

4.1 Organisation des sprints

Notre release est composé par 3 sprints :

• La gestion des examens et affectation des étudiants dans des salles d’examens.

• La gestion des calendriers et des convocations.

• Le traitement des résultats finaux

4.2 Sprint 1 : La gestion des examens et affectations

des étudiants aux salles

4.2.1 Sprint goal

Le but de ce sprint est de planifier les examens de réorientation avec la création des
examens et l’affectation des étudiants dans des salles d’examens.
Comme nous avons mentionné auparavant que l’un des failles des systèmes de réorien-
tation actuelle est l’affectation manuelle des étudiants dans des salles d’examens, ce qui
conduit à des salles non équilibrés ou même plus pire ; dépasser la capacité d’une salle.

124
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Les critères d’affectation sont le nombre des étudiants par matière d’examen, les ma-
tières d’examens à passer dans chaque salle et la capacité de chaque salle. Vu que notre
solution sera développer plus tard donc les critéres d’affectation seront modifiés ; par
exemple par l’ajout les surveillants ou l’horaire adéquat pour chaque surveillant, etc.
Ce problème nous a permis de penser de réaliser une solution intelligente qui permet
l’affectation des étudiants.
L’intelligence artificielle (IA) est un processus d’imitation de l’intelligence humaine
qui repose sur la création et l’application d’algorithmes exécutés dans un environnement
informatique dynamique. Son but est de permettre à des ordinateurs de penser et d’agir
comme des êtres humains.[29]
Pour atteindre notre objectif, nous avons passé par plusieurs solutions jusqu’à trouver
la plus efficace.

[Link] Première solution : Algorithme de l’appariement stable de Gale et

Shapley

Comme une première solution, nous avons trouvé l’algorithme de Gale et Shapley,
c’est un algorithme qui vise à trouver un appariement stable entre deux ensembles, où
chaque élément d’un ensemble est associé à une liste préférentielle d’éléments de l’autre
ensemble. Il a été proposé par David Gale et Lloyd Shapley en 1962, pour résoudre le
problème de l’appariement stable dans le contexte du marché matrimonial.
De ce fait, nous devons créer 2 ensembles : Ensemble étudiants où chaque étudiant
est associé à une matière, et un ensemble salle d’examen où chaque salle a une capacité
maximale. Puis, pour chaque étudiant on doit classer les salles d’examens en fonction de sa
préférence : La préférence est déterminée par la matière de chaque salle d’examen. Et pour
chaque salle on doit classer les étudiants en fonction de ses préférences : Les préférences
des salles sont détérminées par la capacité de chaque salle et la matière d’examen à passer
dans cette classe.
En quatrième étape, nous devons lancer l’algorithme de Gale - Shapley en demandant
de faire des propositions des salles d’examens par chaque étudiant, de l’autre coté les
salles examinent les propositions qu’elles ont reçus et choisissent la proposition préférée.
Suite à cela on met à jour les apparaiements en conséquence et on continue le processus
jusqu’à affecter tout les étudiants.
Selon l’article ”An Overview of Record Linkage Methods : Applications and Perspec-
tive on Health Data. Journal de la Societe Française de Statistique”, les bases de données
médicales et administratives ou statistiques, comme celles que nous pouvons trouver dans
le SNDS (Système National des Données de Santé, géré par la Caisse Nationale de l’As-
surance Maladie CNAM), dans l’EDP (Echantillon Démographique Permanent, géré par
l’INSEE) ou la BCMD (Base des Causes Médicales de Décès, gérée par l’Inserm), sont
volumineuses et peuvent rendre difficile l’application directe des méthodes de couplage
(telle que l’algorithme d’apparaiement stable). L’échantillon EA × EB, contient un total
de nA × nB individus (sachant que la BCMD cumule environ 550 000 entrées chaque
année). [30]

125
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Bien que cet algorithme est largement utilisé pour résoudre des problèmes d’appa-
riement, il n’est pas la meilleure solution pour notre problème, car il n’est pas efficace
pour les grands ensemble de données et le temps d’exécution peut augmenter si le nombre
d’individus et les préférences augmentent.

[Link] Deuxième solution : Arbre de décision

Vu que la première solution n’est pas faisable, nous avons pensé à une deuxième
solution qui est l’arbre de décision.
Un arbre de décision est un algorithme d’apprentissage supervisé non paramétrique,
qui est utilisé à la fois pour les tâches de classification et régression. Il a une structure
hiérarchique, une structure arborescente, qui se compose d’un noeud racine, des branches,
des nœuds interne et des nœuds feuille. [31]
Pour la création automatique d’un arbre de décision il existe plusieurs algorithmes
comme :

• ID3 (Iterative Dichotomiser 3) : dévelopé en 1986 par Ross Quinlan. Il peut être
appliqué seulement sur les caractéristiques nominales. Il est utilisé pour le clas-
sement. Cet algorithme utilise la fonction entropie et le gain d’information pour
décider quelle est la meilleure caractéristique. Etant donnée un ensemble de classes
C, l’entropie de ensemble de donnée S est exprimée par : [32]
∑
H(S) = −P (ci ) log2 P (ci )
ci ∈C
|ci |
Où : P (ci ) = |S|

Etant donnée un vecteur de caractéristiques f⃗ , en utilisant les valeurs d’une ca-

ractéristique fj , on peut diviser l’ensemble de donnée S en plusieurs sous ensembles
groupés dans un ensemble Sj . Le gain d’information est mesuré en se basant sur la
différence entre l’entropie originale de S et celle après sa division en se basant sur
une caractéristique fj .
∑
IG(S, fi ) = H(S) − P (Sjk )H(Sjk )
Sjk ∈Sj
|Sj k|
Où : P (Sj k) = |S|
Les caractéristiques ayant plus de gain d’information est celle sélectionnée comme
meilleure. Aussi, la valeur avec entropie null est considérée comme feuille de l’arbre.

• C4.5 : Cet algorithme est une amélioration sur l’algorithme ID3. Parmi les amélio-
rations nous citons : Les caractéristiques sans valeurs sont ignorées lors du calcul
de l’entropie et le gain d’information et l’élagage des arbres après la création.
Pour décider quelle est la meilleure caractéristique afin de diviser l’ensemble de
données, C4.5 utilise une extension du gain d’information connue par rapport de
gain. Lorsqu’on a une caractéristique ait un grand nombre de valeurs, elle sera
favorisée par le gain d’information. Le rapport de gain fait face au problème de
biais en normalisant le gain d’informations à l’aide de l’information de division. [32]
Etant donnée :

126
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

– C : un ensemble de classes
– S : un ensemble de donnée d’entrainement
– f⃗ : un vecteur de caractéristiques
– Sj : un hyper-ensemble contenant des ensembles avec les mêmes valeurs de la
caractéristique fj
– IG(S, fj ) : le gain d’information en divisant l’ensemble de données S avec la
caractéristique fj .

L’information de dévision SI (Split Information) peut être calculée comme suit :

∑ |Sj k| S k
SI(S, fj ) = − |S|
∗ log2 ( Sj )
Sjk ∈Sj
Et le rapport de gain GR (Gain Ratio) est calculé comme suit :
IG(S,f )
GR(S, fj ) = SI(S,fjj)
Donc, la caractéristique avec le plus grand rapport de gain sera prise comme ca-
ractéristique de division. ID3 ne supporte pas les caractéristiques avec des valeurs
continues ; comme l’age, le prix, etc. C4.5 introduit le support de ce type de ca-
ractéristiques en cherchant le meilleur seuil qui peut diviser l’ensemble des valeurs
d’une caractéristique en deux. Et pour éviter le sur-apprentissage (créer un arbre
avec une grande profondeur), on peut utiliser la technique d’élagage.

• DID (Dual Information Distance ) : C’est une méthode pour la construction efficace
d’arbres de décision qui est attrayante sur le plan informatique, mais relativement
robuste au bruit. L’heuristique DID sélectionne les caractéristiques en tenant compte
à la fois de leur contribution immédiate à la classification et de leurs effets potentiels
futurs. [33]

En se référant au document ”Efficient Construction of Decision Trees by the Dual In-

formation Distance Method” élaboré par ”Irad Ben-Gal et Niv Shkolnik professeurs au
département de génie industriel à l’université de Tel-Aviv Palestine”, ”Alexandra Dana
professeur au département biomédical à l’université de Telv-Aviv” et ”Gonen Singer pro-
fesseur au département génie industriel à Afeka College of Engineering” livré par ”Quality
Technology and Quantitative Management” nous exposons l’exemple suivant qui illustre
le test des différents algorithmes tels que ID3, C4.5 et DID sur plusieurs problèmes de
classification connus.

127
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 119 : Tableau résumant la comparaison entre les arbres de décision ID3, C4.5 et DID
[33]

Comme nous pouvons le voir dans le tableau illustré de ”Efficient Construction of De-
cision Trees by the Dual In- formation Distance Method”, DID surpasse les classificateurs
ID3 et C4.5 dans presque tous les problèmes de classification considérés en termes de
profondeur moyenne de l’arbre. Pour l’ensemble de données Monk’s-1, DID aboutit à un
modèle d’arbre avec une profondeur moyenne de 2,66 décisions, tandis que les profondeurs
moyennes ID3 et C4.5 sont respectivement de 3,21 et 3,32 décisions. La différence est en-
core plus significative en ce qui concerne l’ensemble de données Connect4 - un ensemble
de données relativement volumineux, composé de plus de 67 000 instances et de 42 attri-
buts disponibles. Dans ce cas, le classificateur DID donne un arbre avec 5,64 décisions en
moyenne, tandis que le modèle du C4.5 nécessite 10,16 décisions en moyenne.
Ces algorithmes gourmands populaires (comme ID3, C4.5 et DID) se sont avérés assez
performants dans des problèmes pratiques, mais ils souffrent des défauts habituels des ap-
proches gourmandes, telles que la convergence vers des optimaux locaux. Sans oublier que
l’apprentissage par arbre de décision peut amener des arbres de décision très complexes,
qui généralisent mal l’ensemble d’apprentissage.
Quoique que l’arbre de décision est une approche de classification supervisée qui peut
être utilisée pour résoudre des problèmes de classification et d’affectation, il n’est pas la
solution la plus adéquate à notre problème à cause de sa complexité.

[Link] Troisième solution : Algorithme génétique

Etant donné que les deux solutions précendentes ne sont pas faisables, nous avons opté
à une troisième solution en utilisant l’algorithme génétique. L’Algorithme Génétique est
un algorithme d’optimisation qui s’inspire du processus d’évolution des êtres vivants. Il
fut développé par le scientifique américain John Henry Holland dans les années 1970. En

128
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

recherche opérationnelle, l’Algorithme Génétique est une métaheuristique de la grande

famille des algorithmes d’évolution (Evolutionary Algorithms) qui offrent l’avantage de
fournir des solutions de très grande qualité en un temps raisonnable [34]
Pour résoudre notre problème, nous suivons les principes de l’Algorithme Génétique
suivant les étapes du schéma ci-dessous :

Fig. 120 : Schéma de l’algorithme génétique

Comme première étape nous créons la population de base : Le procédé de création

des individus de la population est arbitraire, il doit être capable de produire une diversité
suffisante pour établir une base solide pour les générations futures.
Comme deuxième étape, nous évaluons la fitness, cette étape consiste à évaluer la
fitness de chaque individu de la population, nous devons calculer une mesure de la qualité
de l’affectation. Cette mesure est basée sur des critères tels que la capacité des salles, le
nombre d’étudiants affectés à chaque salle et l’adéquation entre la matière d’examen de
l’étudiant et la matière de l’examen de la salle.
Concernant à la troisième étape, elle consiste à appliquer les opérateurs génétiques :
La séléction - Le croisement - La mutation.
La sélection : Il s’agit de la sélection des individus qui vont participer à l’amélioration
de la population, c’est-à-dire la sélection d’individus qui deviendront « parents ». Cette
méthode sélectionne des individus en fonction de leur score de fitness relatif. Les individus
ayant un score de fitness plus élevé ont une probabilité plus élevée d’être sélectionnés pour

129
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

la reproduction.
Le croisement ou cross-over : Il manipule les chromosomes ou ensembles de pa-
ramètres de deux éléments parents en les copiant et les recombinant pour générer deux
descendants possédant les caractéristiques issues des deux parents.
La mutation : La mutation est une autre manière modifier la population en créant
de nouveaux éléments. Elle s’articule dans la modification d’un ou plusieurs paramètres
de la population en choisissant une valeur de remplacement aléatoire. Elle résulte la géné-
ration d’un nouvel individu différent ce l’individu initial. Cet opérateur permet de garder
une certaine diversité dans la population d’empêcher une convergence prématurée vers
l’extremum globale et une possible dérive génétique.
En quatrième étape, une fois les nouveaux individus crées, il faut à présent déterminer
la nouvelle population en sélectionnant les individus parmi la population initiale et les
nouveaux individus, qui feront partie de la prochaine génération.
Et finalement, après avoir obtenu une nouvelle population, nous réitérons le processus
un nombre suffisant de générations afin d’obtenir une population qui contient une ou
plusieurs solutions adéquates.

4.2.2 Sprint backlog

Le premier sprint du release 2 se prolonge du 4 Avril jusqu’au 17 Avril. Le tableau
ci-dessous représente le backlog de notre sprint.

Tab. 27 : Sprint Backlog sprint 1 release 2

ID User Story ID Tâches Durée

En tant qu’adminis- 1.1 La création de la table ExamReo 1 jour
1 trateur je veux créer
un examen de réorien-
tation
1.2 La réalisation de l’interface d’ajout d’un exa-
men
1.3 La réalisation de l’api qui permet la création
d’un nouveau examen
1.4 La liaision de la partie frontend avec la partie
backend
1.5 Le test et la validation de la création d’un
examen
En tant qu’adminis- 2.1 La réalisation de l’interface de modification 1 jour
2 trateur je veux modi- d’un examen
fier un examen
2.2 La réalisation de l’api qui permet la modifi-
cation d’un examen
2.3 La liaision de la partie frontend avec la partie
backend

130
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

2.4 Le test et la validation de la modification

d’un examen
En tant qu’adminis- 3.1 La réalisation de l’interface du calendrier 1 jour
3 trateur je veux consul-
ter le calendrier des
examens de réorienta-
tion
3.2 La réalisation de l’api qui permet de récupé-
rer la liste des examens
3.3 La liaision de la partie frontend avec la partie
backend
3.4 Le test et la validation de la consultation du
calendrier
En tant qu’adminis- 4.1 La réalisation de l’api qui permet d’archiver 1 jour
4 trateur je veux archi- un examen
ver un examen
4.2 La liaision de la partie frontend avec la partie
backend
4.3 Le test et la validation de l’archivage d’un
examen
En tant que système je 5.1 La recherche des algorithmes de classification 10 jours
5 veux affecter les étu-
diants dans des salles
d’examens
5.2 L’étude de la première solution (Algorithme
d’apparaiement stable)
5.3 L’étude de la deuxième solution (Arbre de
décision)
5.4 L’étude de la troisième solution (La solution
adoptée : l’algorithme génétique)
5.5 L’implémentation de l’algorithme génétique
dans l’application
5.6 Le test et la validation d’affectation des étu-
diants dans des salles d’examens
En tant qu’adminis- 6.1 La réalisation du traitement qui permet l’ex- 1 jour
6 trateur je veux expor- portation d’une liste des étudiants
ter la liste des étu-
diants par examen
6.2 La liaision de la partie frontend avec la partie
backend
6.3 Le test et la validation de l’exportation d’une
liste des étudiants

131
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

4.2.3 Implémentation de sprint 1

[Link] Spécification des besoins

La figure ci-après représente le diagramme cas d’utilisation de notre sprint :

Fig. 121 : Diagramme des cas d’utilisation sprint 1 release 2

Ce diagramme de cas d’utilisation représente le processus de la gestion des examens de

réorientation qui se manifeste dans l’ajout, la modification, la suppression d’un examen
de réorientation, la consultation du calendrier,l’affectation des étudiants dans des salles
d’examens et l’exportation de la liste des étudiants par salle d’examen.
Dans ce qui suit, nous allons détailler ces cas d’utilisation par leurs descriptions tex-
tuelles.

132
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Tab. 28 : Description textuelle du cas d’utilisation « Créer un examen de réorientation »

Cas d’utilisation Créer un examen de réorientation

Acteur Administrateur de l’université
Pré condition L’authentification
Post condition Message de succés
Scénario nominal
2. L’administrateur demande l’interface de création d’un exa-
men.
3. Le système affiche l’interface.
4. L’administrateur de l’université remplit les champs et valide
5. Le système vérifie les champs saisies par l’administrateur et
affiche un message de succès

Scénario alternatif
3. L’administrateur valide avec un champ obligatoire vide ou in-
valide
3.2 Le système affiche un message d’erreur
3.3 Reprise de la 2ème étape du scénario nominal

Tab. 29 : Description textuelle du cas d’utilisation « Consulter le calendrier d’examen »

Cas d’utilisation Consulter le calendrier d’examen

Acteur Administrateur de l’université
Pré condition L’authentification
Post condition Le calendrier est affiché
Scénario nominal
2. L’administrateur demande l’interface de calendrier d’examen.
3. Le système affiche le calendrier.

Scénario alternatif Néant

133
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Tab. 30 : Description textuelle du cas d’utilisation « Modifier un examen de réorientation»

Cas d’utilisation Modifier un examen

Acteur Administrateur de l’université
Pré condition L’authentification
Post condition Message de succés
Scénario nominal
2. L’administrateur consulte le calendrier
3. L’administrateur choisit l’examen à modifier et clique sur ce
dernier.
4. Le système affiche l’interface.
5. L’administrateur de l’université met à jour les données de
l’examen et valide.
6. Le système vérifie les champs saisies par l’administrateur et
affiche un message de succès.

Scénario alternatif
4. L’administrateur valide avec un champ obligatoire vide ou in-
valide
4.2 Le système affiche un message d’erreur
4.3 Reprise de la 3ème étape du scénario nominal

Tab. 31 : Description textuelle du cas d’utilisation « Supprimer un examen de réorientation »

Cas d’utilisation Supprimer un examen

Acteur Administrateur de l’université
Pré condition L’authentification
Post condition Message de succés
Scénario nominal
2. L’administrateur consulte le calendrier d’examen.
3. L’administrateur choisit l’examen à supprimer et clique sur
son icône de suppression.
4. Le système affiche un message de confirmation.
4.2 Si l’administrateur confirme la suppression le système af-
fiche un message de succès

Scénario alternatif Néant

134
 Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Tab. 32 : Description textuelle du cas d’utilisation « Affecter étudiants dans des salles d’examens »

Cas d’utilisation Affecter les étudiants dans des salles d’examens

Acteur Système
Pré condition L’authentification
Post condition Message de succés
Scénario nominal
2. L’administrateur clique sur le bouton ”Affecter étudiants”.
3. Le système applique l’algorithme génétique et affiche un mes-
sage de succès

Scénario alternatif Néant

Tab. 33 : Description textuelle du cas d’utilisation « Exporter une liste des étudiants par salle »

Cas d’utilisation Exporter la liste des étudiants par salle

Acteur Administrateur de l’université
Pré condition L’authentification
Post condition La liste des étudiants est téléchargée
Scénario nominal
2. L’administrateur clique sur l’examen qui souhaite exporter la
liste de ses étudiants.
3. L’administrateur clique sur le bouton ”Exporter”.
4. Le système télécharge un fichier excel qui contient la liste des
étudiants de la salle choisie.

Scénario alternatif Néant

Dans ce qui suit nous allons exposer quelques maquettes de notre premier sprint :
La figure suivante représente la maquette de la consultation du calendrier d’examen de
réorientation.

135
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 122 : Maquette de consultation du calendrier d’examen

La figure ci-après est la maquette de création et de modification d’un examen de

réorientation.

136
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 123 : Maquette de création et de modification d’un examen

Par la suite, nous détaillons le scénario de notre Sprint dans les diagrammes de sé-
quence système suivants :

137
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 124 : Diagramme de séquence système de cas d’utilisation «Consulter calendrier

d’examen»

Fig. 125 : Diagramme de séquence système de cas d’utilisation «Créer un examen»

138
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 126 : Diagramme de séquence système de cas d’utilisation «Modifier un examen»

139
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 127 : Diagramme de séquence système de cas d’utilisation «Supprimer un examen»

Fig. 128 : Diagramme de séquence système de cas d’utilisation «Affecter étudiants dans
des salles »

[Link] Analyse détaillée

La figure ci-après représente le diagramme de classes participantes de processus de

gestion des examens.

140
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 129 : Diagramme de classes participantes de la gestion des examens

[Link] Conception

Dans cette partie nous allons représenter le diagramme de classes de conception, ainsi
que les diagrammes de séquences de conception de notre premier Sprint.

141
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 130 : Diagramme de classes de conception de sprint 1 release 2.

142
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Ci-après le diagramme de séquence de conception de cas d’utilisation «Consulter ca-

lendrier»

Fig. 131 : Diagramme de séquence de conception de CU «Consulter calendrier»

Le diagramme suivant illustre le diagramme de séquence de conception de cas d’utili-

sation «Créer examen»

143
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 132 : Diagramme de séquence de conception de CU «Créer examen»

Ci-dessous le diagramme de séquence de conception de cas d’utilisation «Modifier

examen»

144
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 133 : Diagramme de séquence de conception de CU «Modifier examen»

Le diagramme suivant désigne le diagramme de séquence de conception de cas d’uti-

lisation «Affecter étudiants aux salles»

145
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 134 : Diagramme de séquence de conception de CU «Affecter étudiants aux salles»

[Link] Réalisation

Dans cette partie nous allons à présenter quelques interfaces graphiques de notre sprint.

Fig. 135 : Interface graphique de la consultation du calendrier

146
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 136 : Interface graphique de la modification d’un examen

4.2.4 Sprint review

A la fin de ce sprint, nous avons montré à note encadrant les tâches demandées :

• Gérer les examens de réorientation

• Affecter les étudiants dans des salles d’examens

• Exporter la liste des étudiants par salle d’examen.

4.2.5 Sprint rétrospective

Ce qui s’est bien passé : Nous avons réussi à implémenter une solution intelligente
à notre système.
Ce qui n’est pas bien passé : La recherche des algorithmes de classification nécessite
une période de travail importante.

4.3 Sprint 2 : La gestion des calendriers et des convo-

cations des examens

4.3.1 Sprint goal

Le but de ce sprint est de gérer les calendriers et des convocations des examens, une
fois que les examens de réorientation sont crées et les étudiants sont affectés aux salles,
les surveillants reçoivent leurs calendriers de surveillance par [Link], les étudiants

147
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

qui ont des dossiers conformes peuvent consulter leurs calendriers et leurs convocations à
travers leurs comptes.

4.3.2 Sprint backlog

Le deuxième sprint du release 2 se prolonge du 18 Avril jusqu’au 1 Mai. Le tableau
ci-dessous représente le backlog de notre sprint

Tab. 34 : Sprint Backlog sprint 2 release 2

ID User Story ID Tâches Durée

En tant que système je 1.1 La création du calendrier en fichier pdf 5 jours
1 veux envoyer le calen-
drier de surveillance
aux surveillants
1.2 La réalisation de l’api qui permet d’envoyer
le calendrier par email
1.3 La liaision de la partie frontend avec la partie
backend
1.4 Le test et la validation de l’envoie du calen-
drier
En tant qu’étudiant je 2.1 La création du calendrier en fichier pdf 5 jours
2 veux télécharger mon
calendrier d’examen
2.2 La réalisation de l’api qui permet la récupé-
ration des examens d’un étudiant
2.3 La liaision de la partie frontend avec la partie
backend
2.4 Le test et la validation de téléchargement
d’un calendrier
En tant qu’étudiant je 3.1 La création du calendrier en fichier pdf 5 jours
3 veux télécharger ma
convocation d’examen
3.2 La réalisation de l’api qui permet de récupé-
rer les détails d’un dossier
3.3 La liaision de la partie frontend avec la partie
backend
3.4 Le test et la validation de téléchargement
d’une convocation

148
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

4.3.3 Implémentation de sprint 2

[Link] Spécification des besoins

La figure ci-après représente le diagramme cas d’utilisation de notre sprint :

Fig. 137 : Diagramme cas d’utilisation de sprint 2 release 2

Dans la suite, nous allons détailler ces cas d’utilisation en fournissant ses descriptions
textuelles.
Tab. 35 : Description textuelle du cas d’utilisation « Télécharger la convocation d’examen »

Cas d’utilisation Télécharger la convocation d’examen

Acteur Etudiant
Pré condition L’authentification
Post condition La convocation d’examen est téléchargée
Scénario nominal
2. L’étudiant clique sur «Dossier de réorientation» dans le menu.
3. Le système affiche la page contenant la liste des demandes de
réorientation.
4. L’étudiant clique sur l’icône ”Convocation”.
5. Le système télécharge la convocation sous format PDF.

Scénario alternatif Néant

Remarque : Vu que l’analyse de cas d’utilisation «Télécharger calendrier d’examen»

est similaire à l’analyse de cas d’utilisation «Télécharger la convocation d’examen» nous
avons opté de ne pas la présenter dans notre rapport.

149
 Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Tab. 36 : Description textuelle du cas d’utilisation « Enovyer calendrier de surveillance au surveillant

par email »

Cas d’utilisation Envoyer calendrier de surveillance au surveillant par email

Acteur Système
Pré condition Planifier les examens et valider le calendrier d’examen
Post condition Un email contenant le calendrier de surveillance est envoyé au sur-
veillant
Scénario nominal
2. L’administrateur de l’université clique sur le bouton «Envoyer
calendrier aux surveillants».
3. Le système envoie un email contenant un fichier pdf qui
contient le calendrier de surveillance de chaque surveillant.

Scénario alternatif Néant

Ci-après nous illustrons les différents diagrammes de séquence système des cas d’uti-
lisation de notre deuxième sprint.

Fig. 138 : Diagramme de séquence système de CU «Télécharger convocation d’examen»

150
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 139 : Diagramme de séquence système de CU «Envoyer calendrier de surveillance

aux surveillants par email»

[Link] Analyse détaillée

Cette section est consacré pour les diagrammes de classes participantes de notre sprint.
Le diagramme ci-dessous représente le diagramme de classes participantes de cas d’uti-
lisation «Télécharger la convocation d’examen».

Fig. 140 : Diagramme de classes participantes de CU «Télécharger la convocation d’exa-

men»

151
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Ci-après le diagramme de classes participantes de cas d’utilisation «Envoyer le calen-

drier de surveillance aux surveillants par email».

Fig. 141 : Diagramme de classes participantes de CU «Envoyer calendrier de surveillance

aux surveillants par email»

[Link] Conception

Au cours de cette section, nous allons présenter le diagramme de classes de conception,

ainsi que les diagrammes de séquences de conception correspondant à notre deuxième
Sprint.

152
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 142 : Diagramme de classes de conception de sprint 2 release 2.

153
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Dans ce qui suit nous allons présenter les diagrammes de séquence de conception de
notre deuxième sprint.

Fig. 143 : Diagramme de séquence de conception de CU «Télécharger la convocation

d’examen»

Ci-dessous le diagramme de séquence de conception de cas d’utilisation «Envoyer

calendrier de surveillance aux surveillants par email».

Fig. 144 : Diagramme de séquence de conception de CU «Envoyer calendrier de sur-

veillance aux surveillants par email»

154
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

[Link] Réalisation

Dans cette section, nous allons vous montrer quelques interfaces graphiques que nous
avons développées lors de notre sprint.
Ci-après la convocation d’examen de réorientation d’un étudiant en format PDF.

Fig. 145 : La convocation d’examen en format PDF

Comme nous avant noté précédement, après avoir planifier l’horaire des examens de
réorientation l’administrateur clique sur le bouton « Envoyer calendrier aux surveillants »
pour envoyer des emails aux surveillants contenant le calendrier de surveillance de chacun.
Ci-dessous l’email que le surveillant reçoit.

155
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 146 : Email envoyé au surveillant

La figure suivante représente un exemple de calendrier de surveillance.

Fig. 147 : Un exemple de calendrier de surveillance

156
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

4.3.4 Sprint review

A la fin de ce sprint, nous avons montré les tâches demandées :

• Télécharger la convocation d’examen.

• Télécharger le calendrier d’examen.

• Envoyer le calendrier de surveillance au surveillant par email.

4.3.5 Sprint rétrospective

Ce qui s’est bien passé : Nous avons respecté les délais de ce sprint.
Ce qui n’est pas bien passé : Nous avons rencontré des difficultés lors de la géné-
ration des fichiers pdf.

4.4 Sprint 3: Le traitement des résultats finaux

4.4.1 Sprint goal

Le but ultime de ce sprint est de traiter les dossiers conformes et de générer le résultat
de concours. Le processus de traitement de résultat se fait par le passage par plusieurs
étapes ; l’administrateur de chaque université doit déposer les notes des étudiants, par
la suite le système va calculer le score de chaque dossier et affecter chaque étudiant à la
branche adéquate, le choix de la filière dépend de la capacité de cette dernière, son rang
dans le dossier et le score de l’étudiant dans cette branche.

4.4.2 Sprint backlog

Notre troisième sprint se prolonge du 2 Mai jusqu’au 15 Mai. Le tableau ci-après
représente le sprint backlog.

Tab. 37 : Sprint Backlog sprint 3 release 2

ID User Story ID Tâches Durée

En tant qu’adminis- 1.1 La création de la table markReo 1 jour
1 trateur je veux ajouter
une note
1.2 La réalisation de l’interface d’ajout d’une
note
1.3 La réalisation de l’api qui permet l’ajout
d’une nouvelle note
1.4 La liaision de la partie frontend avec la partie
backend
1.5 Le test et la validation de l’ajout d’une note

157
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

En tant qu’adminis- 2.1 La réalisation de l’interface de modification Demi journée

2 trateur je veux modi- d’une note
fier une note
2.2 La réalisation de l’api qui permet la modifi-
cation d’une note
2.3 La liaision de la partie frontend avec la partie
backend
2.4 Le test et la validation de la modification
d’une note
En tant qu’adminis- 3.1 La réalisation de l’interface de consultation 1 jour
3 trateur je veux consul- de la liste des notes
ter la liste des notes
par matière
3.2 La réalisation de l’api qui permet de récupé-
rer la liste des notes
3.3 La liaision de la partie frontend avec la partie
backend
3.4 Le test et la validation de la consultation de
la liste des notes
En tant qu’adminis- 4.1 La réalisation de l’api qui permet d’archiver Demi journée
4 trateur je veux archi- une note
ver une note
4.2 La liaision de la partie frontend avec la partie
backend
4.3 Le test et la validation de l’archivage d’une
note
En tant qu’adminis- 5.1 La réalisation du traitement qui permet l’im- 1 jour
5 trateur je veux impor- portation d’une liste des notes
ter une liste des notes
5.2 La liaision de la partie frontend avec la partie
backend
5.3 Le test et la validation de l’importation d’une
liste des notes
En tant qu’adminis- 6.1 La réalisation du traitement qui permet l’ex- 1 jour
6 trateur je veux expor- portation d’une liste des notes
ter une liste des notes
6.2 La liaision de la partie frontend avec la partie
backend
6.3 Le test et la validation de l’exportation d’une
liste des notes
En tant que système 7.1 La création de la table resultReo 4 jours
7 je veux affecter les
étudiants dans des
branches

158
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

7.2 La réalisation de l’interface de génération du

résultat
7.3 La réalisation de l’api qui permet la généra-
tion du résultat
7.4 La liaision de la partie frontend avec la partie
backend
7.5 Le test et la validation de la génération du
résultat
En tant qu’adminis- 6.1 La réalisation de l’interface de consultation 2 jours
8 trateur je veux consul- de résultat
ter le résultat de ré-
orientation de mon
université
8.2 La réalisation de l’api qui permet la récupé-
ration de résultat
8.3 La liaision de la partie frontend avec la partie
backend
8.4 Le test et la validation de la récupération de
résultat
En tant qu’étudiant 9.1 La réalisation de l’interface de consultation 2 jours
9 je veux consulter mon de résultat
résultat
9.2 La réalisation de l’api qui permet la récupé-
ration de résultat
9.3 La liaision de la partie frontend avec la partie
backend
9.4 Le test et la validation de la récupération de
résultat
En tant qu’étudiant je 10.1 La création de l’attestation en fichier pdf 2 jours
10 veux télécharger l’at-
testation de nomina-
tion
10.2 La réalisation de l’api qui permet de récupé-
rer les détails du résultat d’un étudiant
10.3 La liaision de la partie frontend avec la partie
backend
10.4 Le test et la validation de téléchargement
d’une attestation

159
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

4.4.3 Implémentation de sprint 3

[Link] Spécification des besoins

Ci-dessous nous illustrons le diagramme de cas d’utilisation de notre sprint.

Fig. 148 : Diagramme cas d’utilisation de sprint 3 release 2

Dans ce qui suit, nous allons détailler ces cas d’utilisation par quelques descriptions
textuelles.

160
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Tab. 38 : Description textuelle du cas d’utilisation « Importer une liste des notes »

Cas d’utilisation Importer une liste des notes

Acteur Administrateur de l’université
Pré condition L’authentification
Post condition Message de succés
Scénario nominal
2. L’administrateur dépose un fichier excel qui contient une liste
des notes avec les CIN des étudiants et clique sur le bouton
”Importer”.
3. Le système vérifie les lignes du fichier excel et affiche un mes-
sage de succès

Scénario alternatif
1. L’administrateur dépose un fichier qui contient un CIN inva-
lide (CIN d’un étudiant non concerné par cette matière ou
CIN introuvable par exemple )
1.2 Le système affiche un message d’erreur
1.3 Reprise de la 1ére étape du scénario nominal

Tab. 39 : Description textuelle du cas d’utilisation « Exporter une liste des notes »

Cas d’utilisation Exporter la liste des notes

Acteur Administrateur de l’université
Pré condition L’authentification
Post condition La liste des notes est téléchargée
Scénario nominal
2. L’administrateur clique sur le bouton ”Exporter”.
3. Le système télécharge un fichier excel qui contient la liste des
notes des étudiants d’une matière donnée.

Scénario alternatif Néant

161
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Tab. 40 : Description textuelle du cas d’utilisation « Affecter les étudiants dans des filières »

Cas d’utilisation Affecter étudiants aux branches adéquates

Acteur Système
Pré condition L’authentification
Post condition Les étudiants sont affectés aux filières adéquates
Scénario nominal
2. L’administrateur clique sur le bouton ”Affecter aux branches”.
3. Le système calcule le score de chaque dossier pour chaque
filière et traite les résultats.
4. Le système affiche un message de succès.

Scénario alternatif Néant

Tab. 41 : Description textuelle du cas d’utilisation «Consulter le résultat d’une université»

Cas d’utilisation Consulter résultat d’une université

Acteur Administrateur de l’université
Pré condition L’authentification
Post condition Le résultat d’une université est affiché
Scénario nominal

2. L’administrateur choisit une faculté pour consulté son résul-

tat.

3. Le système affiche la liste des branches du faculté choisi avec

quelques statistiques (nombre de candidats, taux de réussite,
etc)

4. L’administrateur clique sur le bouton télécharger devant une

branche

5. Le système télécharge la liste des étudiants qui sont acceptés

dans cette filière.

Scénario alternatif Néant

162
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Tab. 42 : Description textuelle du cas d’utilisation « Consulter résultat d’un étudiant »

Cas d’utilisation Consulter résultat d’un étudiant

Acteur Etudiant
Pré condition La liste des demandes de réorientation est affichée
Post condition Le résultat d’un étudiant est affiché
Scénario nominal

2. L’étudiant clique sur l’icone «Résultat» d’une demande.

3. Le système affiche les notes de cet étudiant avec son résultat

d’affectation.

Scénario alternatif Néant

Dans ce qui suit nous allons exposer quelques maquettes de notre troisième sprint :
La figure suivante représente la maquette de la consultation du résultat d’une université.

Fig. 149 : Maquette de consultation de résultat d’une université

Ci-après nous présentons la maquette de consultation du résultat d’un étudiant.

163
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 150 : Maquette de consultation de résultat d’un étudiant

Par la suite, nous exposons quelques diagrammes de séquence système de notre troi-
sième sprint.

164
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 151 : Diagramme de séquence système de CU «Importer une liste des notes»

Fig. 152 : Diagramme de séquence système de CU «Exporter la liste des notes»

165
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 153 : Diagramme de séquence système de CU «Affecter étudiants aux branches»

Fig. 154 : Diagramme de séquence système de CU «Consulter les résultats d’une univer-
sité»

166
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 155 : Diagramme de séquence système de CU «Consulter le résultat d’un étudiant»

[Link] Analyse détaillée

Ci-dessous nous présentons quelques diagrammes de classes participantes de sprint 3.

Fig. 156 : Diagramme de classes participantes de CU «Importer une liste des notes»

Remarque : Vu que le diagramme de classes participantes de CU «Exporter la liste

des notes» est identique au diagramme précédent, nous avons opté de ne pas le présenter
dans notre rapport.

167
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 157 : Diagramme de classes participantes de CU «Affecter étudiants aux branches»

Fig. 158 : Diagramme de classes participantes de CU «Consulter résultat d’une univer-

sité»

168
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 159 : Diagramme de classes participantes de CU «Consulter résultat d’un étudiant»

[Link] Conception

Au cours de cette partie, nous allons présenter le diagramme de classes de conception,

ainsi que les diagrammes de séquences de conception correspondant à notre troisième
Sprint.

169
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

170
Fig. 160 : Diagramme de classes de conception de sprint 3 release 2.
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 161 : Diagramme de séquence de conception de CU «Importer une liste des notes»

Remarque : La vérification des champs dans ce cas d’utilisation se fait par la vé-
rification si l’étudiant ajouté admet déjà une note ou non et s’il est concerné par cette
matière ou non.

171
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 162 : Diagramme de séquence de conception de CU «Affecter étudiants aux branches»

[Link] Réalisation

Nous allons présenter dans cette section quelques interfaces graphiques qui ont été
développées lors de notre troisième sprint.
Ci-dessous l’interface graphique de consultation de résultat d’un étudiant donné.

Fig. 163 : Interface graphique de consultation de résultat d’un étudiant

La figure suivant représente l’interface graphique de consultation de résultat d’une

université qui est affiché au administrateur de cette dernière.

172
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

Fig. 164 : Interface graphique de consultation de résultat d’une université

L’administrateur de l’université après avoir choisir la faculté qui va consulter son

résultat, il peut télécharger la liste des étudiants qui sont acceptés à une filière donné
en cliquant sur le bouton «Télécharger». La figure ci-dessous représente le fichier PDF
téléchargé.

Fig. 165 : Le fichier PDF contenant les étudiants qui sont acceptés à une branche

173
Chapitre 4. Release 2 : Planification intelligente de concours et le
traitement des résultats

4.4.4 Sprint review

Nous faisons une démonstration de notre incrément :

• Gestion des notes

• Affecter les étudiants aux branches adéquates

• Consutler résultat d’une université

• Consulter résultat d’un étudiant

4.4.5 Sprint rétrospective

Ce qui s’est bien passé : La gestion des fichiers pdf n’a pas pris beaucoup du temps
vu que nous avons habitué à la bibliothèque jsPdf dans le sprint précédent.
Ce qui n’est pas bien passé : Nous avons pris beaucoup du temps lors de l’affec-
tation des étudiants aux branches adéquates à cause de la complexité de ce processus.

Conclusion
Au cours de ce chapitre nous avons analyser notre deuxième release qui concerne la
planification intelligente de concours avec le traitement des résultats.

174
Conclusion générale et perspectives

Ce rapport est le miroir de notre projet de fin d’études à l’institut supérieur des études
technologiques de Bizerte effectué à la société Technix Informatique pendant 4 mois. Ce
projet a pour but de concevoir et de développer un module de la plateforme ScientiWorld
qui permet la gestion de la réorientation universitaire.

Afin de réussir notre projet, nous avons débuté par comprendre le contexte générale
avec les différents besoins de notre futur solution. Puis, nous avons organisé et décortiqué
les taches suivant le framework Scrum avant de commencer à réaliser notre futur système.

La réalisation de notre projet nous a offert une très riche opportunité grâce à quoi
nous avons approfondis notre savoir faire académiques acquis à l’ISET dans le domaine du
développement des systèmes d’information, de conception UML ainsi que la méthodologie
agile.

En effet, au niveau technique, nous avons eu l’opportunité de découvrir et d’utiliser

le MERN stack du JavaScript : Node JS et Express pour la réalisation de backend de
notre application, la bibliothéque React JS pour le frontend et MongoDB pour la base de
données.

Sans oublier le niveau personnel, cette exprérience professionnelle nous a permis de

découvrir le milieu professionnel avec sa discipline et ses responsabilités ce qui permet
d’enrichir nos vies professionnelles. Ainsi, elle nous a permis de connaître une équipe de
travail très compétente.

Avec le résultat d’aujourd’hui, nous ne devons pas nier que nous avons passé par
plusieurs problèmes lors de la réalisation de notre projet de fin d’études. Citons l’ex-
ploitation de l’environnement logiciel avec lequel nous avons développé notre plateforme
généralement et avec React JS plus précisément ainsi qu’à la réalisation de la partie de
l’intelligence artificielle.

Bien que notre application répond aux besoins fixés au départ, elle reste ouverte à de
nouvelles perspectives. En effet, il serait bénéfique d’ajouter des dashboards de statistiques
pour les administrateurs des universités, améliorer la partie d’affectation des étudiants
dans des salles d’examens en ajoutant des nouveaux préférences ainsi que d’implémenter
un module de paiement pour gérer le processus de paiement des demandes de réorientation.

Finalement, nous sommes reconnaissant envers Technix Informatique qui nous a per-
mis de vivre une admirable expérience tout en espérant que nous puissons rejoindre son
service de développement en tant qu’ingénieur en informatique.

175
Bibliographie et Nétographie

1] https ://[Link]/pages/fr/langage-uml UML (consulté le 11/02/2023).

[2] https ://[Link] SCRUM (consulté le 11/02/2023)
[3] https ://[Link] Piliers SCRUM (consulté le 11/02/2023)
[4] https ://[Link]/ Cérémonie SCRUM (consulté le 12/02/2023)
[5] https ://[Link]/wiki/Visual Studio Code Visual Studio Code (consulté
le 19/03/2023)
[6] https ://[Link]/wiki/Postman (logiciel) Postman (consulté le 19/03/2023)
[7] https ://[Link]/wiki/GitLab GitLab (consulté le 19/03/2023)
[8] https ://[Link]/wiki/Overleaf Overleaf (consulté le 19/03/2023)
[9] https ://[Link]/fr/base-de-connaissances/qu-est-ce-que-node-js Node JS(consulté
le 19/03/2023)
[10] https ://[Link]/wiki/Trello Trello(consulté le 19/03/2023)
[11] https ://[Link]/wiki/Odoo Odoo (consulté le 23/05/2023)
[12] https ://[Link]/tous-les-articles-er-ressources/articles-internet/819-
draw-io-un-outil-pour-dessiner-des-diagrammes-en-ligne [Link] (consulté le 19/03/2023)
[13] https ://[Link]/wireframes/desktop/docs/intro/ Balsamiq Wireframes
(consulté le 19/03/2023)
[14] https ://[Link]/wiki/HTML5 HTML5 (consulté le 19/03/2023)
[15] https ://[Link]/web-tech/dictionnaire-du-webmastering/1203277-
css-cascading-style-sheets-definition-traduction/ CSS (consulté le 19/03/2023)
[16] https ://[Link]/enUS/docs/Learn/JavaScript/First steps/What is
avaScript JavaScript (consulté le 19/03/2023)
[17] https ://[Link]/wiki/LaTeX LaTeX (consulté le 19/03/2023)
[18] https ://[Link]/en-US/docs/Learn/Server-side/Express Nodejs/Introduction
Express JS (consulté le 19/03/2023)
[19] https ://[Link]/fr-fr/what-is-mongodb MongoDB (consulté le 19/03/2023)
[20] https ://[Link]/wiki/React (JavaScript library) React JS (consulté le
19/03/2023)
[20] https ://[Link]/definition/Bootstrap Bootstrap (consulté le 19/03/2023)

176
Bibliographie et Nétrographie

[22] https ://[Link]/fr/docs/intro Axios (consulté le 19/03/2023)

[23] https ://[Link]/blog/utiliser-redux-avec-react-js/ Redux (consulté le
19/03/2023)
[24] https ://[Link]/fr/courses/ React Router (consulté le 19/03/2023)
[25] https ://[Link]/difference-between-react-bootstrap-and-reactstrap Reacts-
trap (consulté le 19/03/2023)
[26] https ://[Link]/package/react-feather React Feather (consulté le 19/03/2023)
[27] https ://[Link]/blog/glossaire/quest-ce-quun-backlog-definition-
etapes-caracteristiques-et-outils/ Product Backlog (consulté le 21/03/2023)
[28] https ://[Link]/document-oriented-database Base de données
orientée documents (consulté le 28/03/2023)
[29] https ://[Link]/fr/artificial-intelligence/what-is-artificial-intelligence/
L’intelligence artificielle (consulté le 09/04/2023)
[30] An Overview of Record Linkage Methods : Applications and Perspective on Health
Data. Journal de la Societe Française de Statistique (consulté le 09/04/2023)
[31] https ://[Link]/fr-fr/topics/decision-trees Arbre de décision (consulté
le 12/04/2023)
[32] https ://[Link]/intro-apprentissage-automatique/[Link] Les al-
gorithmes de création d’un arbre de décision (consulté le 12/04/2023)
[33] Efficient Construction of Decision Trees by the Dual In- formation Distance Me-
thod - Quality Technology and Quantitative Management DID (Consulté le 12/04/2023)
[34] https ://[Link]/algorithme-genetique/ L’algorithme génétique (Consulté
le 14/07/2023)

177
Résumé :
Ce rapport a été rédigé à l’occasion de la réalisation de notre projet de fin d’études au
sein de la société Technix Informatique en vue de l’obtention du diplôme de Licence en
technologie de l’informatique spécialité développement des systèmes d’informations. Du-
rant ce projet, notre mission s’articule au développement d’un module de la plateforme
ScientiWorld qui permet la gestion de la réorientation univrsitaire. Notre solution per-
met le processus de dépôt des demandes, planification de concours de réorientation et le
traitement des résultats. Pour la modélisation et la conception nous avons utilisé l’UML,
concernant la gestion de projet nous avons le framework Scrum et pour le développement
nous avons opté à utiliser MERN stack de JavaScript : MongoDB, Express JS, React JS
et Node JS et nous avons recours à utiliser l’intelligence artificielle pour l’affectation des
étudiants dans des salles des examens.
Mots clés : Réorientation, UML, Scrum,Java Script, MERN, Intelligence artificielle.

Abstract :
This report was written on the occasion of the realization of our end-of-studies project
within the company Technix Informatique with a view to obtaining the diploma of License
in computer technology specializing in the development of information systems. . During
this project, our mission revolves around the development of a module of the ScientiWorld
platform which allows the management of university reorientation. Our solution enables
the process of sending folders, planning exams for reorientation and processing results. For
modeling and design we used UML, for project management we have the Scrum framework
and for development we opted to use MERN stack of JavaScript : MongoDB, Express JS,
React JS and Node JS and we have resorted to using artificial intelligence for assigning
students to classrooms.
Keywords : Reorientation, UML, Scrum, Java Script, MERN, Artificial Intelligence.

ّ
: ‫الملخص‬
‫ بهدف‬Informatique Technix ‫تم كتابة هذا التقرير بمناسبة إنجاز مشروع نهاية الدراسة الخاص بنا داخل شركة‬
‫ تتمحور‬، ‫ خلال هذا المشروع‬.‫الحصول على دبلوم الاجازة في تكنولوجيا العلامية المتخصصة في تطوير نظم المعلومات‬
‫ يتيح النظام الذي‬.‫مهمتنا حول تطوير وحدة نمطية لمنصة "ساينت وورلد" التي تسمح بإدارة إعادة التوجيه الجامعي‬
UML ‫ للنمذجة والتصميم استخدمنا‬.‫تنظيم المناظرة ومعالجة النتائج‬, ‫نقدمه عملية تقديم مطالب اعادة التوجيه الجامعي‬
React ‫ و‬JS Express ‫ و‬MongoDB : MERN ‫ وللتطوير اخترنا استخدام‬Scrum ‫ لإ دارة المشاريع لدينا إطار عمل‬،
. ‫ وقد لجأنا إلى استخدام الذكاء الاصطناعي لتعيين الطلاب في القاعات‬JS Node ‫ و‬JS
‫ الذكاء الاصطناعي‬,‫ مناظرة اعادة التوجيه الجامعي‬,‫تطوير نظم المعلومات‬. :‫الكلمات المفاتيح‬