Rapport de Stage de Projet de Fin D Étude

Code : 1452 Année Universitaire : 2022/2023.
Université de la Manouba
École Supérieure d’Économie Numérique
Rapport
de projet de fin d'études
Présenté en vue de l'obtention du diplôme de

Licence en Business Computing
Sujet
Conception, développement et mise en ligne

d’un Annuaire Universitaire interactif
Élaboré par :
Bouchoucha Wiem
Organisme d'accueil :
CENTRE DE CALCUL EL KHAWAREZMI
Encadré par :
ESEN Mme Hamida Amdouni
Société M. Jamel Aloui
Remerciements
Avant de présenter notre travail, nous tenons à exprimer notre grande reconnaissance
envers les personnes qui nous ont, de prés ou de loin, apporté leurs soutiens. Qu’ils trouvent
ici collectivement et individuellement l’expression de toute notre gratitude.
Nous tenons à remercier particulièrement M. JAMEL ALOUI pour l’expérience enri-

chissante et pleine d’intérêt durant cette période de stage.
Aussi, nous exprimons notre parfaite reconnaissance et nos remerciements à notre encadrante
Mme. HAMIDA AMDOUNI. D’abord, pour le temps qu’elle a bien voulu consacrer à
l’encadrement, Aussi pour le suivi de ce travail et les conseils qu’elle nous a prodigués après
sa minutieuse lecture. Puis, les réunions qui ont rythmés les différentes étapes de la rédaction
de rapport.
Enfin, les discussions que nous avons tenues ont permis d’orienter ce travail d’une manière
sûre et pertinente. Nous la remercions vivement pour son effort, sa disponibilité et surtout
ses conseils qui ont largement contribués à rehausser la valeur de ce travail.
Que les membres de jury trouvent, ici, l’expression de nos remerciements pour l’honneur
qu’ils nous font en acceptant de juger ce travail.
Dédicaces
j’ai l’honneur d’exprimer ma gratitude à ceux qui sont toujours présents dans ma vie.
À mes chers parents, Je tiens à vous exprimer toute ma gratitude pour tout ce que
vous avez fait pour moi. Vous m’avez donné la vie, l’amour et le soutien inconditionnel dont
j’ai besoin pour grandir et réaliser mes rêves.
À mes chers frères Mohamed et Wajih, Je tiens à vous dire à quel point vous êtes
importants pour moi. Vous êtes mes amis, mes confidents et mes partenaires de vie, et je suis
chanceuse de vous avoir dans ma vie.
À mon cher frère Kais, Je tiens à te remercier du fond du cœur pour tout ce que tu
as fait pour m’aider dans mon projet. Ta contribution a été exceptionnelle et je suis très
reconnaissante de t’avoir à mes côtés. Tu m’as aidé à surmonter les obstacles, à trouver des
solutions créatives et à maintenir la motivation tout au long du processus.
Table des matières
Table des figures
Liste des tableaux
Introduction générale 2
1 Étude Préalable 3
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Organigramme de CCk : . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Description du projet : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Étude de l’existant : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.1 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.3 Solutions proposées . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6.1 Choix de la méthodologie . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6.2 Méthodes classiques vs Méthode agiles . . . . . . . . . . . . . . . . . 9
1.6.3 Les 4 valeurs d’agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6.4 Les 12 principes d’agiles . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6.5 Présentation de la méthodologie SCRUM . . . . . . . . . . . . . . . . 10
1.6.6 Les artefacts de la méthode Scrum . . . . . . . . . . . . . . . . . . . 12
1.7 Les cérémonies de la méthode Scrum . . . . . . . . . . . . . . . . . . . . . . 13
1.7.1 Langage de modélisation à adopter : . . . . . . . . . . . . . . . . . . 14
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 Planification et Architecture 16
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.2 Diagramme de contexte statique . . . . . . . . . . . . . . . . . . . . . 17
2.2.3 Identification des besoins fonctionnels . . . . . . . . . . . . . . . . . . 18
2.2.4 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Structure et découpage de projet . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.1 Identification de l’équipe SCRUM . . . . . . . . . . . . . . . . . . . . 20
2.4 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.1 Structure des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . 24
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Gestion des intervenants 26

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Backlog de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Spécification fonctionnelle de sprint . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1 Diagramme de cas d’utilisation du premier sprint . . . . . . . . . . . 28
3.4 Analyse des cas d’utilisation du premier sprint : . . . . . . . . . . . . . . . . 29
3.4.1 Analyse des cas d’utilisation «S’authentifier» . . . . . . . . . . . . . . 29
3.4.2 Analyse de cas d’utilisation « Gérer profil » : . . . . . . . . . . . . . . 30
3.4.3 Analyse de cas d’utilisation « Gérer les informations d’un établissement » 33
3.4.4 Analyse de cas d’utilisation « Gérer les établissements » . . . . . . . 37
3.4.5 Analyse de cas d’utilisation « Gérer les informations d’une université » 44
3.4.6 Analyse de cas d’utilisation « Gérer les universités » : . . . . . . . . . 48
3.4.7 Analyse de cas d’utilisation « traiter les demandes de mise à jour » . 55
3.5 Conception des cas d’utilisation : . . . . . . . . . . . . . . . . . . . . . . . . 58
3.5.1 Diagramme des classes participantes : . . . . . . . . . . . . . . . . . . 58
3.5.2 Diagramme de séquence détaillé : . . . . . . . . . . . . . . . . . . . . 61
3.6 Diagramme de classe globale du premier sprint . . . . . . . . . . . . . . . . . 74
3.7 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.7.1 Les Schéma de la base de données . . . . . . . . . . . . . . . . . . . . 76
3.7.2 Maquettes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.7.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.7.4 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.7.5 Revue de sprint - Diagramme de « Burn down Chart » . . . . . . . . 91
3.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4 « Sprint 2 : Consultation, réclamation et évaluation des informations de

l’annuaire » 94
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.2 Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.2.1 Backlog de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.3 Spécification fonctionnelle de sprint . . . . . . . . . . . . . . . . . . . . . . . 95
4.3.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . 95
4.4 Analyse des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.4.1 Analyse de cas d’utilisation « Consulter les établissements » . . . . . 96
4.4.2 Analyse de cas d’utilisation « Chercher établissement » . . . . . . . . 97
4.4.3 Analyse de cas d’utilisation « Chercher spécialité » . . . . . . . . . . 99
4.4.4 Analyse de cas d’utilisation « Recommander établissement » . . . . . 100
4.4.5 Analyse de cas d’utilisation « Évaluer établissement » . . . . . . . . . 102
4.4.6 Analyse de cas d’utilisation « Consulter les les statistiques » . . . . . 104
4.5 Conception des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.5.1 Diagramme de classes participantes . . . . . . . . . . . . . . . . . . . 105
4.5.2 Diagramme de séquence détaillé . . . . . . . . . . . . . . . . . . . . . 106
4.6 Diagramme de classe globale du deuxième sprint . . . . . . . . . . . . . . . . 111
4.6.1 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.6.2 Maquettes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.6.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.6.4 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.6.5 Revue de sprint - Diagramme de « Burndown Chart » . . . . . . . . 118
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5 Phase de clôture 121

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.2.2 Environnement de développement et de modélisation . . . . . . . . . 122
5.2.3 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.3 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.3.1 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.3.2 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.3.3 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Conclusion générale 130

Table des figures
1.1 Logo de CCK [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Organigramme de CCK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Site de l’annuaire universitaire . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Les valeurs d’agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Cycle de vie de méthode SCRUM [2] . . . . . . . . . . . . . . . . . . . . . . 11
1.6 Les rôles dans SCRUM [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.7 Les cérémonies de la méthode Scrum [4] . . . . . . . . . . . . . . . . . . . . 13
1.8 Logo UML [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Diagramme de contexte statique . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Les rôles dans SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . 24
3.1 Diagramme de cas d’utilisation du premier sprint . . . . . . . . . . . . . . . 28

3.2 Diagramme de séquence de s’authentifier . . . . . . . . . . . . . . . . . . . . 30
3.3 Raffinement du cas d’utilisation « Gérer profil» . . . . . . . . . . . . . . . . 30
3.4 Diagramme de séquence système de cas d’utilisation « Consulter profil » . . 31
3.5 Diagramme de séquence système du cas d’utilisation «Modifier profil» . . . . 33
3.6 Raffinement du cas d’utilisation «Gérer les informations d’un établissement» 33
3.7 Diagramme de séquence « consulter un établissement » . . . . . . . . . . . . 34
3.8 Diagramme de séquence « Demander des modifications des informations d’un
établissement » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.9 Diagramme de séquence « Gérer les établissements » . . . . . . . . . . . . . 37
3.10 Diagramme de séquence « Consulter les établissements » . . . . . . . . . . . 38
3.11 Diagramme de séquence « Ajouter établissement » . . . . . . . . . . . . . . . 40
3.12 Diagramme de séquence « Modifier établissement » . . . . . . . . . . . . . . 42
3.13 Diagramme de séquence «Supprimer établissement» . . . . . . . . . . . . . . 43
3.14 Raffinement du cas d’utilisation « Gérer les informations d’une université » . 44
3.15 Diagramme de séquence « Consulter une université » . . . . . . . . . . . . . 45
3.16 Diagramme de séquence « Demander des modifications des informations d’une
université » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.17 Raffinement du cas d’utilisation « Gérer les universités » . . . . . . . . . . . 48
3.18 Diagramme de séquence du cas d’utilisation « Consulter les universités » . . 49
3.19 Diagramme de séquence « Ajouter université » . . . . . . . . . . . . . . . . . 51
3.20 Diagramme de séquence « Modifier université » . . . . . . . . . . . . . . . . 53
3.21 Diagramme de séquence « Supprimer université » . . . . . . . . . . . . . . . 55
3.22 Raffinement du cas d’utilisation « traiter les demandes de mise à jour » . . . 55
3.23 Diagramme de séquence « Consulter les demandes de mise à jour » . . . . . 56
3.24 Diagramme de séquence « Approuver/Refuser les demandes de mise à jour » 58
3.25 Diagramme de classes participants par acteur «Utilisateur» . . . . . . . . . . 59
3.26 Diagramme de classes participants par acteur «Directeur d’établissement» . 59
3.27 Diagramme de classes participants par acteur «Directeur d’université» . . . . 60
3.28 Diagramme de classes participants par acteur «Administrateur» . . . . . . . 60
3.29 Diagrammes de séquence détaillé de cas d’utilisation « S’authentifier » . . . 61
3.30 Diagramme de séquence détaillé de cas d’utilisation « Consulter profil» . . . 62
3.31 Diagramme de séquence détaillé de cas d’utilisation « Modifier profil» . . . . 62
3.32 Diagramme de séquence détaillé de cas d’utilisation «Consulter établissement» 63
3.33 Diagramme de séquence détaillé de cas d’utilisation «Demande des modifica-
tions des informations d’un établissement» . . . . . . . . . . . . . . . . . . . 64
3.34 Diagramme de séquence détaillé de cas d’utilisation « Afficher la liste des
établissements » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.35 Diagramme de séquence détaillé de cas d’utilisation «Ajouter établissement» 66
3.36 Diagramme de séquence détaillé de cas d’utilisation «Modifier établissement» 67
3.37 Diagramme de séquence détaillé de cas d’utilisation «Supprimer établissement» 68
3.38 Diagramme de séquence détaillé de cas d’utilisation « Consulter université » 68
3.39 Diagramme de séquence détaillé de cas d’utilisation «Demande des modifica-
tions des informations d’une université» . . . . . . . . . . . . . . . . . . . . 69
3.40 Diagramme de séquence détaillé de cas d’utilisation «Afficher la liste des
universités » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.41 Diagramme de séquence détaillé de cas d’utilisation «Ajouter université » . . 71
3.42 Diagramme de séquence détaillé de cas d’utilisation «Modifier université » . 72
3.43 Diagramme de séquence détaillé de cas d’utilisation « Supprimer université » 73
3.44 Diagramme de séquence détaillé de cas d’utilisation «Consulter les demandes
de mise à jour» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.45 Diagramme de séquence détaillé de cas d’utilisation «Approuver/Refuser un
demande de mise à jour» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.46 Diagramme de classe globale du premier sprint . . . . . . . . . . . . . . . . . 75
3.47 Maquette de l’interface «Authentification» . . . . . . . . . . . . . . . . . . . 78
3.48 Maquette de l’interface «Consulter profil» . . . . . . . . . . . . . . . . . . . 78
3.49 Maquette de l’interface «Liste des universités» . . . . . . . . . . . . . . . . . 79
3.50 Maquette de l’interface «Ajouter université» . . . . . . . . . . . . . . . . . . 79
3.51 Maquette de l’interface «Modifier université» . . . . . . . . . . . . . . . . . . 80
3.52 Maquette de l’interface «Supprimer université» . . . . . . . . . . . . . . . . 80
3.53 Maquette de l’interface «Demande de modification» . . . . . . . . . . . . . . 81
3.54 Maquette de l’interface «Traiter les demandes de MAJ» . . . . . . . . . . . . 81
3.55 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.56 Interface de la liste des universités . . . . . . . . . . . . . . . . . . . . . . . . 83
3.57 Interface «Liste des établissements» . . . . . . . . . . . . . . . . . . . . . . . 84
3.58 Code de source de la méthode de test d’ajout d’une université. . . . . . . . . 85
3.60 Interface de résultat du test d’ajout d’une université. . . . . . . . . . . . . . 86
3.63 Interface de résultat du test d’ajout d’une université. . . . . . . . . . . . . . 87
3.64 Code de source de la méthode de test de modification d’une université. . . . 87
3.66 Interface de résultat du test de modification d’une université. . . . . . . . . . 88
3.69 Interface de résultat du test de modification d’une université. . . . . . . . . . 89
3.70 Code de source de la méthode de test de suppression d’une université. . . . . 90
3.71 Interface de résultat du test de suppression d’une université. . . . . . . . . . 90
3.72 Code de source de la méthode de test de suppression d’une université. . . . . 91
3.73 Interface de résultat du test de suppression d’une université. . . . . . . . . . 91
3.74 Tableau de valeurs de Brundown Chart du sprint 1. . . . . . . . . . . . . . . 92
3.75 Diagramme de Burn down Chart du sprint 1. . . . . . . . . . . . . . . . . . 93
4.1 Diagramme de cas d’utilisation de sprint 2 . . . . . . . . . . . . . . . . . . . 95

4.2 Diagramme de séquence système du cas d’utilisation « Consulter les établisse-
ments » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.3 Diagramme de séquence système du cas d’utilisation «Chercher établissement» 98
4.4 Diagramme de séquence système du cas d’utilisation «Chercher spécialité» . 100
4.5 Diagramme de séquence système du cas d’utilisation «Recommander établisse-
ment» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.6 Diagramme de séquence système du cas d’utilisation «Évaluer établissement» 103
4.7 Diagramme de séquence système du cas d’utilisation «Consulter les statistiques»104
4.8 Diagramme de classes participantes par acteur « Visiteur » . . . . . . . . . . 105
4.9 Diagramme de séquence détaillé du cas d’utilisation «Consulter les établisse-
ments» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.10 Diagramme de séquence détaillé du cas d’utilisation «Chercher établissement» 107
4.11 Diagramme de séquence détaillé du cas d’utilisation «Chercher spécialité» . . 108
4.12 Diagramme de séquence détaillé du cas d’utilisation «Recommander établisse-
ment» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.13 Diagramme de séquence détaillé du cas d’utilisation «Évaluer établissement» 110
4.14 Diagramme de séquence détaillé du cas d’utilisation «Consulter les statistiques»111
4.15 Diagramme de classe globale du deuxième sprint . . . . . . . . . . . . . . . . 112
4.16 Maquette de l’interface «Accueil» . . . . . . . . . . . . . . . . . . . . . . . . 113
4.17 Maquette de l’interface «Consulter établissement» . . . . . . . . . . . . . . . 114
4.18 Maquette de l’interface «Consulter Statistiques» . . . . . . . . . . . . . . . . 114
4.19 Interface de la liste universités . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.20 Interface d’inviter un membre . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.21 Code de source de la méthode de test «Chercher établissement». . . . . . . . 116
4.22 Interface de résultat du test de recherche d’un établissement. . . . . . . . . . 117
4.25 Tableau de valeurs de Brundown Chart du sprint 2. . . . . . . . . . . . . . . 119
4.26 Diagramme de Burn down Chart du sprint 1. . . . . . . . . . . . . . . . . . 120
5.1 logo de Spring Tool Suit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

5.2 logo de Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.3 logo de Taiga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.4 logo de Draw io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.5 logo de Lucidchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.6 logo de Latex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.7 logo de Balsamiq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.8 logo de Xampp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.9 logo de phpMyAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.10 Logo d’Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.11 Logo de Spring Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.12 Architecture MVC [20] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.13 Architecture physique de l’application . . . . . . . . . . . . . . . . . . . . . . 128
5.14 Diagramme des taches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Liste des tableaux
1.1 Étude comparative entre Méthodes classiques et Méthode agiles . . . . . . . 9
2.1 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1 Backlog de sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Description textuelle de cas d’utilisation «s’authentifier» . . . . . . . . . . . 29
3.3 Description textuelle de cas d’utilisation de consulter profil . . . . . . . . . . 31
3.4 Description textuelle de cas d’utilisation de modifier profil . . . . . . . . . . 32
3.5 Description textuelle de cas d’utilisation « Consulter un établissement » . . . 34
3.6 Description textuelle de cas d’utilisation «Demander des modifications d’un
établissement» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.7 Description textuelle de cas d’utilisation « Consulter les établissements » . . 37
3.8 Description textuelle de cas d’utilisation « Ajouter établissement » . . . . . . 39
3.9 Description textuelle de cas d’utilisation « Modifier établissement » . . . . . 41
3.10 Description textuelle de cas d’utilisation « Supprimer établissement » . . . . 43
3.11 Description textuelle de cas d’utilisation « Consulter une université » . . . . 44
3.12 Description textuelle de cas d’utilisation « Demander des modifications d’une
université » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.13 Description textuelle de cas d’utilisation « Consulter les universités » . . . . 48
3.14 Description textuelle de cas d’utilisation « Ajouter université » . . . . . . . . 50
3.15 Description textuelle de cas d’utilisation « Modifier université » . . . . . . . 52
3.16 Description textuelle de cas d’utilisation « Supprimer université » . . . . . . 54
3.17 Description textuelle de cas d’utilisation « Consulter les demandes de mise à
jour » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.18 Description textuelle de cas d’utilisation « Approuver/Refuser les demandes
de mise à jour » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.19 Table « User ». . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.20 Table « Role ». . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.21 Table « Université ». . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.22 Table « Etablissement ». . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.23 Table « Date-mandat ». . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.1 Backlog de sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

4.2 Description textuelle du cas d’utilisation « Consulter les établissements ». . . 96
4.3 Description textuelle du cas d’utilisation « Chercher établissement ». . . . . 98
4.4 Description textuelle du cas d’utilisation « Chercher spécialité ». . . . . . . . 99
4.5 Description textuelle du cas d’utilisation « Recommander établissement ». . 101
4.6 Description textuelle du cas d’utilisation « Évaluer établissement ». . . . . . 103
4.7 Description textuelle du cas d’utilisation « Consulter les statistiques ». . . . 104
4.8 Table « EvaluationEtablissement ». . . . . . . . . . . . . . . . . . . . . . . . 112
4.9 Table « RecommandationEtablissement ». . . . . . . . . . . . . . . . . . . . 113
Introduction générale
Ces dernières années, les nouvelles technologies ont rencontrées un grand succès et offrent
des capacités de plus en plus avancées. Ils facilitent la création et le déploiement d’applications
web innovantes qui répondent aux besoins des utilisateurs.
le Centre de Calcul elKhawarezmi est l’un des plus grands entreprises de Tunisie,
promouvant et facilitant l’utilisation des technologies numériques dans les universités et la
communauté scientifique. Il est également responsable de la recherche pour améliorer l’utili-
sation des technologies de l’information numérique dans l’enseignement supérieur au profit
des enseignants et des étudiants. Faciliter et peut aider les étudiants à trouver facilement des
informations sur les universités et les établissements en Tunisie.
C’est dans ce cadre, que le "CCK" nous a chargé et de concevoir, de développer et de mettre
en ligne un annuaire universitaire interactif qui comporte des détails et des informations
sur les universités et les établissements.
Ce rapport présente les différentes étapes de la réalisation de notre projet. Il est divisé en
5 chapitres.
Un premier chapitre intitulé « Étude de projet » consacré à la présentation du cadre général
du projet : l’organisme d’accueil, l’étude de l’existant et la solution adoptée. Puis, il aborde
la méthodologie appliquée pour assurer le bon déroulement de notre travail, ainsi que
l’architecture de notre projet.
Le deuxième chapitre « Planification et architecture » présente le backlog du produit de
notre projet. Il détaille les besoins fonctionnels et non fonctionnels, le diagramme de cas
d’utilisation générale ainsi que l’affectation des rôles de chaque membre de l’équipe SCRUM.
Nous passons ensuite au troisième chapitre « Sprint 1 : Gestion des intervenants » qui
représente notre premier sprint suivi par le quatrième chapitre « Sprint 2 : Consultation,
1
réclamation et évaluation des informations de l’annuaire » qui représente le deuxième sprint
de la plateforme.
Le cinquième et le dernier chapitre « Phase de Clôture » qui résume les divers outils utilisés
lors de la conception et le développement de la plateforme ainsi que les technologies que nous
avons inclues pour enrichir notre projet.
Et finalement, nous clôturons notre rapport par une conclusion générale qui résume le travail
effectué tout au long de la période de stage de projet de fin d’études.
2
Chapitre 1
Étude Préalable
1.1 Introduction
Pour qu’un projet aboutisse, il doit fournir une bonne étude préalable visant à approfondir
l’analyse de ses différentes dimensions d’innovation. Dans ce chapitre nous nous intéressons à
présenter le cadre général de notre projet. Il s’agit d’abord de présenter l’entreprise qui a
réalisé les travaux. Nous nous sommes ensuite attachés à examiner les solutions existantes et
adoptées. Enfin, nous commençons ce chapitre par une introduction à la méthodologie de
gestion du projet employé.
1.2 Cadre du projet

La société "CCK" nous a offert l’opportunité de développer un projet intitulé «Annuaire
Universitaire : Conception, développement et mise en ligne d’un Annuaire Universitaire
interactif», dans lequel nous exploitons nos connaissances pratiques et nos théories acquises
durant 3 années d’éducation et d’apprentissage au sein de l’École Supérieure d’Économie
Numérique. Ce projet est dans le but d’obtenir un diplôme de licence en business computing.
3
1.3 Présentation de l’organisme d’accueil
Le Centre de Calcul el-Khawarizmi (CCK) créé en octobre 1976 à la suite de
l’introduction de l’informatique en tant que spécialité universitaire à la faculté des sciences
de Tunis, le CCK avait pour vocation initiale de fournir des services de calcul aux éta-
blissements, agences et administrations relevant des ministères de l’éducation nationale et
de l’enseignement supérieur. Depuis lors, le CCK s’est engagé à promouvoir l’utilisation
des technologies numériques dans le milieu universitaire et scientifique en général, tout en
encourageant leur développement et leur optimisation. En tant qu’organisme de recherche, le
CCK poursuit son objectif d’améliorer l’utilisation des technologies de l’information et de la
communication dans le milieu universitaire, dans le but de favoriser l’épanouissement des
enseignants et des étudiants.[1]
La figure 1.1, nous trouvons le logo de l’entreprise CCK.
Figure 1.1 – Logo de CCK [1]
Le Centre de Calcul ElKhawarezmi offre un ensemble de services tels que :
• Gestion du réseau national universitaire.
• Gestion et motoring de la sécurité du réseau RNU.
• Hébergement des applications nationales et sites web des EER.
• Formation-Production Numérique et veille technologique.
4
1.3.1 Organigramme de CCk :
L’organigramme de CCK représente les différents départements qui la composent.
Figure 1.2 – Organigramme de CCK
1.4 Description du projet :

Notre projet intitulé " Conception, développement et mise en ligne d’un Annuaire
Universitaire interactif" : Il s’agit d’une application web qui permettra de mettre en
oeuvre un annuaire universitaire interactif bien référencé.
ce portail permettra également aux utilisateurs d’accéder facilement à l’annuaire.
1.5 Étude de l’existant :

Au niveau de cette partie, nous nous basons sur les orientations fonctionnelles de notre
cahier des charges présenté par la société CCK. Nous présentons en détail l’analyse et le
critique de l’existant ainsi que la solution adoptée de notre projet.
5
1.5.1 Analyse de l’existant
En effet, la CCK dispose d’un annuaire universitaire en ligne disponible dans l’adresse (
http ://www.annuaire.rnu.tn/ ).
Figure 1.3 – Site de l’annuaire universitaire
Afin de préciser les fonctionnalités de notre application web, nous avons effectué une
étude des fonctionnalités disponible sur le site d’annuaire universitaire existant :
• Administrateur :
Il a pour missions de gérer son profil, gérer les universités et gérer les établissements.
• Visiteur :
Il a pour missions de consulter le site, chercher des établissements.
6
1.5.2 Critique de l’existant
La critique existante est une méthode analytique qui consiste à évaluer objectivement les
forces et les faiblesses des systèmes, organisations, processus ou produits existants. Il vise
à identifier les problèmes et les opportunités d’amélioration afin de mettre en œuvre des
solutions appropriées et efficaces.
L’étude des différentes solutions existantes est une étape importante pour accomplir le
bon déroulement du projet et nous permettre d’atteindre nos objectifs. Dans cette partie
nous commençons par critiquer les fonctionnalités existantes dans l’application web.
L’un des avantages de l’annuaire universitaire est sa fonction de recherche qui permet aux
intervenants de trouver rapidement et facilement les informations qu’ils cherchent. Cependant,
malgré cet avantage, l’annuaire universitaire peut présenter quelques inconvénients. Tout
d’abord, certaines informations peuvent être obsolètes, incomplètes ou inexactes. Les utilisa-
teurs doivent donc être prudents lors de l’utilisation de l’annuaire et vérifier les informations
auprès des sources officielles.
De plus, l’annuaire universitaire n’est pas entièrement à jour et peut ne pas inclure toutes
les informations dont les utilisateurs ont besoin. Par exemple, les nouvelles recherches.
Enfin, cet annuaire universitaire n’est pas suffisamment interactif pour encourager l’enga-
gement des intervenants. Par exemple, il n’offre pas des fonctionnalités de mise en réseau
social ou de partage de contenu qui pourraient être utiles pour les étudiants et les enseignants.
En conclusion, l’annuaire universitaire actuel peut être une source utile pour les membres
de la communauté universitaire. Cependant, il peut présenter des inconvénients tels que des
informations obsolètes ou incomplètes, une accessibilité limitée et une interaction insuffisante.
d’ajouter des fonctionnalités interactives pour encourager l’engagement des utilisateurs.
7
1.5.3 Solutions proposées
Pour remédier aux problèmes évoqués précédemment, nous proposons de développer une
application web qui permet :
-L’actualisation des données et leur mise à jour : Pour garantir l’exactitude et la
pertinence des informations fournies par l’annuaire universitaire.
-Utiliser les filtres de recherche : pour filtrer les résultats en fonction de la localisation et
de la spécialité.
-L’ajout des fonctionnalités interactives : Pour améliorer l’engagement des utilisateurs,
il serait judicieux d’ajouter des fonctionnalités interactives à l’annuaire comme les fonction-
nalités de mise en réseau social ou de partage du contenu.
En intégrant l’ensemble de ces fonctionnalités, l’annuaire universitaire peut

devenir une source plus utile et plus pertinente.
1.6 Méthodologie de travail

Dans le contexte de notre projet, nous avons besoin de collaborer et dialoguer avec le
reste des membres de l’équipe. L’utilisation d’une méthode agile est une priorité pour pouvoir
réussir la mission dans les meilleures conditions. Nous avons choisi de travailler avec la
méthode Scrum qui présente une implémentation de l’approche agile. [2]
1.6.1 Choix de la méthodologie
Le choix entre les différentes méthodes de gestion de projet dépend de plusieurs facteurs
tels que la nature du projet et sa taille. Pour les projets de petite envergure, impliquant un
domaine bien maîtrisé, un cycle de vie en cascade peut suffire. Toutefois, pour les projets
dont les données ne sont pas disponibles dès le départ ou dont les besoins sont flous, une
méthode itérative ou orientée prototypes est plus appropriée. Les méthodes AGILE sont
largement utilisées aujourd’hui dans le monde et sont considérées comme des méthodes
itératives efficaces. Les méthodes AGILE sont collaboratives et s’adaptent aux approches
incrémentales, ce qui permet de produire des produits de haute qualité tout en tenant compte
8
de l’évolution des besoins du client. Elles assurent une meilleure communication avec le
client et une meilleure visibilité du produit livrable. Elles permettent également de détecter
les problèmes dès le début, ce qui permet de prendre des mesures correctives sans trop de
pénalités en termes de coûts et de délais. Étant donné la nature évolutive du projet, nous
avons opté pour une méthode AGILE, en particulier SCRUM. [2]
1.6.2 Méthodes classiques vs Méthode agiles
Méthodes Classiques Méthode Agiles

Modèles stricts Les modèles incrémentaux et itératifs
Etape claire et définie Des livraisons petites et fréquentes
Vaste Documentation Se concentrer sur le code
Fonctionne bien avec les grands projets et les Adapté aux projets de petite et moyenne taille
projets gouvernementaux
Table 1.1 – Étude comparative entre Méthodes classiques et Méthode agiles
1.6.3 Les 4 valeurs d’agiles
Figure 1.4 – Les valeurs d’agile
9
1.6.4 Les 12 principes d’agiles
Les 12 principes du manifeste agile :

1.Satisfaire le client en premier lieu.
2.Accueillir les demandes de changement.
3.Livrer le plus tôt possible des versions opérationnelles de l’application.
4.Assurer une coopération efficace entre les deux parties (client et l’équipe de projet).
5.Créer des projets avec des personnes motivées et dynamiques
6.Mettre l’accent sur la conversation en face à face.
7.Mesurer la progression du projet en fonction des fonctionnalités de l’application.
8.Faire progresser le projet à un rythme durable et régulier.
9.Une attention constante à l’excellence technique et à la conception.
10.La simplicité.
11.Renforcer et responsabiliser les équipes.
12.Ajuster régulièrement les comportements et les processus en vue d’améliorer l’efficacité.
Afin de bien gérer notre projet et de réaliser un produit de bonne qualité

dans le délai prévu, nous avons choisi la méthodologie SCRUM car c’est la plus
utilisée dans la majorité des entreprises.
1.6.5 Présentation de la méthodologie SCRUM
La méthodologie SCRUM est basée sur un processus de développement itératif qui consiste
à réaliser des livraisons fréquentes de logiciel en ajoutant de nouvelles fonctionnalités à chaque
itération. La transparence est une valeur clé de SCRUM, qui maintient une liste visible de
toutes les demandes de corrections et d’évolutions à implémenter. Ainsi, le client peut suivre
l’avancement du projet et recevoir un logiciel fonctionnel à chaque itération, environ toutes
les 4 semaines. Au fur et à mesure que le projet avance, le logiciel est enrichi de nouvelles
fonctionnalités et devient de plus en plus complet. [2]
Pour cela, la méthode s’appuie sur des développements itératifs à un rythme constant
d’une durée de 2 à 4 semaines. La figure 1.5 illustre le cycle de vie de la méthode SCRUM.
La figure illustre le processus de mise en œuvre de la méthode SCRUM, qui commence par
la définition des fonctionnalités de l’application pour former le backlog du produit. Ensuite,
10
Figure 1.5 – Cycle de vie de méthode SCRUM [2]
la planification du sprint est effectuée pour élaborer un plan détaillé de chaque itération,
généralement d’une durée de deux à quatre semaines. Tout au long du sprint, les membres
de l’équipe tiennent des réunions quotidiennes pour présenter l’état d’avancement de leurs
tâches respectives, discuter des difficultés rencontrées et planifier les tâches restantes. Une
fois le sprint terminé, le produit partiel est examiné pour assurer sa conformité et l’améliorer
en fonction des résultats de la rétrospective..
Principes essentiels de la méthode
Nous pouvons remarquer quatre valeurs principales dans les méthodes agiles [3] :
L’équipe : nous nous concentrons sur les personnes et leurs interactions plutôt que sur
les processus et les outils.
L’application : le plus important c’est d’avoir une application fonctionnelle plutôt que
d’avoir une documentation complète.
La collaboration : cette méthode se base sur la collaboration avec le client.
L’acceptation du chagement : nous ne suivons pas un plan fixe nous réagissons à

chaque nouveau changement.
Organisation
La méthodologie SCRUM [3] fait intervenir 3 rôles principaux qui sont :
— Le « Product Owner » est le responsable de l’équipe projet client. Il va définir et

prioriser la liste des fonctionnalités du produit et choisir la date et le contenu de chaque
11
sprint sur la base des valeurs (charges) qui lui sont communiquées par l’équipe.
— Le « Scrum Master » veille à ce que chacun puisse travailler au maximum de

ses capacités en éliminant les obstacles et en protégeant l’équipe des perturbations
extérieures. Il porte également une attention particulière au respect des différents phases
de SCRUM.
— Equipe s’organise elle-même et elle reste inchangée pendant toute la durée d’un sprint.
Elle doit tout faire pour délivrer le produit.
— Intervenant observe et donne des conseils à l’équipe.
La figure 1.6 présente les rôles dans SCRUM.
Figure 1.6 – Les rôles dans SCRUM [3]
1.6.6 Les artefacts de la méthode Scrum
Les artefacts de la méthode Scrum sont trois :
• «Product Backlog» :Contient toutes les exigences fonctionnelles de notre application,

ces exigences sont nommées Users Stories dans le jargon Scrum.
• «Sprint Backlog» : Représente une partie des Users Stories indiquées dans le Product
Backlog qui ont été prises en charge par l’équipe Scrum.
• «Incrément» : En plus des artefacts qui ont été achevés dans le sprint précédent,
l’incrément Scrum représente tous les éléments "achevés" du sprint actuel.
12
1.7 Les cérémonies de la méthode Scrum
Les cérémonies de la méthode Scrum sont :
• «Sprint» :Il s’agit d’une itération ou d’une période de développement qui est fixe et
qui ne peut pas varier pendant le travail, elle contient un ensemble d’exigences (User
Stories) à développer.
• «Sprint Reviw» : C’est une réunion pour la présentation et la démonstration du

sprint, les améliorations préconisées et les problèmes rencontrés sont priorisés dans le
prochain sprint.
• «Sprint Rétrospective» :Fait référence à un bilan des tâches complétées et non

complétées, ou au manque de performance et d’efficacité, afin d’éviter et de réviser ces
problèmes dans les futurs sprints.
• «Sprint planning meeting» :Il s’agit d’une session au cours de laquelle il est nécessaire
de définir l’objectif du sprint et les éléments prioritaires du Backlog de produit.
• «Daily Scrum» : : est une réunion qui a lieu au début de chaque journée entre les
membres de l’équipe pour échanger et partager ce qu’ils ont fait, ce sur quoi ils vont
travailler et les obstacles auxquels ils sont confrontés.
Figure 1.7 – Les cérémonies de la méthode Scrum [4]
13
1.7.1 Langage de modélisation à adopter :
Afin de faciliter la transmission d’informations et améliorer la compréhension du projet,

l’utilisation d’une représentation visuelle est essentielle. Pour cela, il est recommandé d’utiliser
l’outil UML pour une modélisation unifiée. Cette notation graphique se compose de plusieurs
schémas appelés "diagrammes", chacun offrant une vue différente du projet à traiter. Les
diagrammes UML permettent de représenter le fonctionnement et la mise en place des applica-
tions web à développer. Bien que le langage UML ne recommande pas de méthode spécifique,
chacun est libre d’utiliser les types de diagramme souhaités et dans l’ordre qu’il préfère,
à condition que les diagrammes soient cohérents entre eux avant de procéder à la réalisation.[5]
Ce langage a les caractéristiques suivantes [5] :
— Un langage sans ambiguïtés.

— Un langage universel pouvant servir de support pour tout langage orienté objet.
— Un moyen de définir la structure d’un programme.
— Une représentation visuelle permettant la communication entre les acteurs d’un même
projet.
Figure 1.8 – Logo UML [6]
14
1.8 Conclusion
Au début de ce chapitre, nous avons exposé le contexte général de notre projet ainsi que
présenté l’organisme d’accueil.
Ensuite, Nous avons effectué une analyse de l’existant pour identifier les points forts et les
points faibles du système en place chez CCK. Cette analyse a conduit à la proposition de la
solution que nous avons présentée précédemment. Enfin, nous avons déterminé notre choix de
méthodologie et de langage de modélisation pour ce projet. Le prochain chapitre portera sur
la présentation des acteurs impliqués dans le système et de leurs interactions avec celui-ci,
ainsi que sur l’exposition des besoins fonctionnels et non-fonctionnels de notre projet.
15
Chapitre 2
Planification et Architecture
2.1 Introduction
Ce chapitre se concentre sur l’analyse et la spécification des besoins. Nous commençons
par la spécification des besoins fonctionnels et non fonctionnels de notre projet. Ensuite,
notre backlog de produit. Puis, nous présentons l’environnement de travail et les technologies
utilisées. Enfin, nous terminons ce chapitre par une présentation de l’architecture de notre
application.
2.2 Identification des besoins

L’identification des besoins comprend l’identification des acteurs et la détermination des
besoins fonctionnels et non fonctionnels.
2.2.1 Identification des acteurs
Dans cette partie, nous décrivons les différents intervenants qui interagissent avec notre
système. En effet, un intervenant peut accéder et/ou modifier directement l’état du système
en émettant ou en recevant des messages, potentiellement par l’intermédiaire de porteurs de
données.
16
Les principaux acteurs du notre système et ses rôles :
• Visiteur : il a pour mission de consulter les actualités, et les détails concernant les
universités ainsi que leur établissements, des recommandations et des évaluations sur le
contenu des établissements.
• Directeur de l’établissement : il a pour mission de gérer son profil et de gérer les

informations de son établissement.
• Directeur de l’université : il a pour mission de gérer son profil et de gérer les

établissements.
• Administrateur : il a pour missions de gérer son profil, gérer les universités et traiter
les demandes de modifications effectués par le directeur de l’université ou le directeur
de l’établissement.
2.2.2 Diagramme de contexte statique
Le diagramme de contexte statique est un diagramme de la vue statique d’un système. Il

représente les acteurs qui interagissent avec le système ainsi que les relations entre ces acteurs
et le système. Notre diagramme de contexte statique est le suivant :
Figure 2.1 – Diagramme de contexte statique
17
2.2.3 Identification des besoins fonctionnels
Nous pouvons décrire les exigences fonctionnelles ou les cas d’utilisation en utilisant
le langage de modélisation UML comme suit : "Un cas d’utilisation (ou use case) est une
séquence d’actions effectuées par le système pour produire un résultat observable qui est
important pour un acteur particulier. Chaque cas d’utilisation spécifie le comportement
attendu du système dans son ensemble, sans imposer de contraintes sur la façon dont ce
comportement doit être implémenté". Chaque exigence fonctionnelle représente donc un
ensemble d’actions réalisées par le système pour répondre aux besoins de l’utilisateur.[7]
Les Besoins fonctionnels de l’acteur«Visiteur»

–Consulter les détails des établissements : La plateforme permet au visiteur de consulter
les établissements.
–Chercher des établissements : La plateforme permet au visiteur de chercher des établis-
sements en spécifiant ses besoins(emplacements, spécialités).
–Recommander des établissements : La plateforme permet au visiteur de recommander
des établissements.
–Évaluer établissements : La plateforme permet au visiteur d’évaluer le contenu des infor-
mations disponible sur les établissements.
Les Besoins fonctionnels de l’acteur«Directeur d’établissement» :

–S’authentifier : Pour pouvoir accéder à son profil, le directeur d’établissement doit s’au-
thentifier en spécifiant un login et un mot de passe.
–Gérer son profil :La plateforme permet au directeur d’établissement de gérer son profil.
–Gérer les informations de l’établissement : La plateforme permet au directeur d’établis-
sement de gérer les informations de son établissement liées à l’emplacement, les spécialités,
l’historique, contact.
–Gérer des demandes de modifications de son établissement : La plateforme permet au
directeur d’établissement d’envoyer des demandes de modification des informations concernant
son établissement à l’administrateur.
18
Les Besoins fonctionnels de l’acteur«Directeur d’université» :
–S’authentifier : Pour pouvoir accéder à son profil, le directeur d’université doit s’authentifier
en spécifiant un login et un mot de passe.
–Gérer son profil : La plateforme permet au directeur d’université de gérer son profil.
–Gérer les informations de l’université : la plateforme permet au directeur d’université de
gérer les informations de son université comme l’emplacement, l’historique, les établissements
liés à cet université.
–Gérer les établissements : La plateforme permet au directeur d’université d’ajouter, de
modifier et de supprimer les établissements ainsi que leur directeur d’établissement.
Gérer les demandes de modifications de son université : La plateforme permet au
directeur de l’université d’envoyer une demande de modification des informations à l’adminis-
trateur.
Les Besoins fonctionnels de l’acteur«Administrateur» :

–S’authentifier : Pour pouvoir accéder à son profil, l’administrateur doit s’authentifier en
spécifiant un login et un mot de passe.
–Gérer son profil : La plateforme permet à l’administrateur de gèrer son profil.
–Gérer les universités : La plateforme permet à l’administrateur d’ajouter, de modifier et
de supprimer une université ainsi que leur directeur d’université.
–Traiter les demandes de mise à jour : La plateforme permet à l’administrateur de traiter
les demandes de mise à jour des directeurs d’universités et des directeurs d’établissements.
2.2.4 Besoins non fonctionnels
Les besoins non fonctionnels font référence aux exigences qui ne sont pas directement
liées aux fonctionnalités de l’application, mais qui ont une importance cruciale pour garantir
la qualité, la fiabilité et la performance du système.
Nous énumérons dans ce qui suit les principaux besoins non fonctionnels de notre l’application :
— Sécurité : L’application devra être sécurisée, les projets ne devront pas être accessible
à tous les utilisateurs. En effet l’application est accessible par un identifiant et un mot
de passe attribué à chaque rôle (User / Admin). Notons que les deux rôles n’ont pas
19
les même accès à l’application et n’ont pas aussi la même gestion des permissions par
projet.
— Performance : L’application devra être performante. En effet, le système doit réagir

dans un délai précis, quel que soit l’action de l’utilisateur (déploiement, configura-
tion,. . .).
— Convivialité : L’application doit être simple et facile à manipuler même pour les non
initiés.
— L’ergonomie : Le thème de l’application doit offrir une interface conviviale et rapide

pour manipuler les différents projets déployés.
— L’extensibilité : L’application devra être extensible, c’est-à-dire qu’il pourra y avoir

une possibilité d’ajouter ou de modifier de nouvelles fonctionnalités ou des services.
2.3 Structure et découpage de projet
2.3.1 Identification de l’équipe SCRUM
L’équipe SCRUM est essentiellement composée de trois acteurs.

Dans notre projet, nous pouvons distinguer les rôles suivants :
–Product Owner : M.Jamel ALOUI.
–Scrum Master : Mme.Hamida AMDDOUNI.
–Développeur : Wiem Bouchoucha.
Figure 2.2 – Les rôles dans SCRUM
20
2.4 Backlog de produit
Nous amorçons le processus en établissant le backlog de produit, qui consiste en une liste
de fonctionnalités à implémenter, classées par ordre de priorité. Les priorités sont établies en
concertation avec le client et le chef de projet lors de réunions dédiées. Le backlog de produit
sert également à établir le plan de chaque sprint en incluant les fonctionnalités à réaliser d’ici
la date butoir de chaque itération.
La complexité des tâches est fait à l’aide de la suite Fibonacci. Cette dernière est une suite
d’entiers , dont chaque valeur est la somme des deux précédentes, en considérant les deux
valeurs initiales 0 et 1. Le début de cette suite est : 0, 1, 2, 3, 5, 8, 13, ... jusqu’à l’infini. La
priorité du user story selon la valeur métier et l’ordre de réalisation.
Le tableau 2.1 expose le Backlog de produit de notre solution. La lettre «P» signifie Priorité
et la lettre «C» signifie Complexité.
Id Titre User Story P C

1 Gestion d’authentifica- En tant qu’utilisateur,qui peut être adminis- 3 5
tion trateur, directeur d’université ou directeur
d’établissement, je veux m’authentifier pour
accéder à la plateforme.
2 Gérer le profil En tant qu’utilisateur, qui peut être admi- 2 2
nistrateur, directeur d’université ou directeur
d’établissement, je peux consulter, modifier
mon profil.
3 Gérer les Universités En tant qu’administrateur, je peux ajouter, 3 3
modifier, supprimer une université ainsi que
son directeur.
4 Gérer les informations En tant que directeur d’université, je peux 2 3
d’une université gérer les informations de mon université.
5 Gérer les établissements En tant que directeur d’université, je peux 3 5
consulter, modifier, supprimer un établisse-
ments ainsi que son directeur.
21
6 Gérer les informations En tant que directeur d’université, je peux 3 2
d’un établissement gérer les informations de mon établissement
7 Traiter les demandes de En tant qu’administrateur je peux traiter les 2 3
modifications demandes de mise à jour du directeur d’uni-
versité et du directeur d’établissement.
8 Consulter les établisse- En tant que visiteur, je peux consulter les 1 2
ments établissements.
9 Chercher établissements En tant que visiteur, je peux chercher des 3 3
établissements en spécifiant le nom.
10 Recommander des établis- En tant que visiteur, je peux recommander 2 1
sements des établissements.
11 Évaluer les informations En tant que visiteur, je peux évaluer des éta- 2 3
des établissements blissements.
12 Consulter les statistiques En tant que visiteur, je peux consulter les 1 2
statistiques.
Table 2.1 – Backlog de produit
2.4.1 Structure des sprints
Une fois que nous avons terminé le backlog du produit, nous avons établis une réunion de
planification. Le but de cette réunion est de construire le backlog de sprint en se basant sur
le backlog de produit réalisé par le Product Owner. A la fin, nous avons identifié, les durées
prévisionnelles du travail à effectuer durant chaque sprint.
Nous choisissons d’effectuer deux Sprints dans notre projet :
La répartition se fait comme suit :
Sprint 1 : Gestion des intervenants :

–Authentification.
–Gérer profil.
22
– Gérer universités.
–Gérer établissements.
–Traiter les demandes de mise à jour.
–Date début : 11 Mars 2022
–Date fin : 31 Mars 2022.
Sprint 2 : Consultation, recommandation et évaluation des informations de

l’annuaire :
–Consulter les établissements.
–Chercher des établissements.
–Chercher des spécialités.
–Recommander des établissements.
–Évaluer des établissements.
–Consulter les statistiques.
–Date début : 1 avril Mars 2022
–Date fin : 20 Avril 2022.
Figure 2.3 – Planification des sprints
23
2.5 Diagramme de cas d’utilisation global
Le diagramme de cas d’utilisation, présenté par la figure 2.4, permet de synthétiser les
spécifications générales de notre application web ainsi que les fonctionnalités de chaque acteur
du système. Il présente les différentes fonctionnalités de l’utilisateur et le visiteur de notre
application. L’utilisateur doit s’authentifier pour accéder à son espace.
Figure 2.4 – Diagramme de cas d’utilisation global
24
2.6 Conclusion
Au sein de ce chapitre, nous avons déterminé les acteurs et identifié le backlog du produit
à travers l’identification des besoins fonctionnels et non-fonctionnels de notre projet. Ensuite,
nous avons fait la première étape de Scrum en déterminant l’équipe, réalisant le diagramme
global des cas d’utilisation, enfin, nous avons identifié le backlog produit et les sprints de
notre projet.
Dans le prochain chapitre, nous passerons à notre premier sprint, qui finit par être la première
version possible.
25
Chapitre 3
Gestion des intervenants
3.1 Introduction
Après avoir effectué une analyse et une spécification des besoins globaux de notre projet,
ce chapitre se concentre sur les différentes étapes du premier sprint nommé «Gestion des
intervenants». Nous commençerons par exposer le backlog de sprint, suivi d’une analyse
détaillée, d’une spécification fonctionnelle, de la conception, de l’implémentation et des tests.
Le sprint "gestion des intervenants" vise à mettre en place un système d’authentification
sécurisé pour les utilisateurs qui accèdent à l’application développée dans le cadre du projet.
Cela implique notamment l’identification des différents types d’utilisateurs qui ont accès à
notre application web.
3.2 Backlog de sprint

Nous commençons, tout d’abord, par présenter le backlog de sprint suivi d’une analyse
détaillée et d’une conception. Par la suite, nous exposons les maquettes et les interfaces
réalisées durant ce sprint.
Le tableau 3.1 décrit les stories de notre backlog de sprint 1.
26
Id Titre User Story Priorité
1 S’authentifier En tant qu’utilisateur, qui peut être ad- 3
ministrateur, directeur d’université ou
directeur d’établissement je dois m’au-
thentifier pour accéder à la plateforme.
2 Gérer profil En tant qu’utilisateur, qui peut être ad- 2
ministrateur, directeur d’université ou
directeur d’établissement, je peux gérer
mon profil.
3 Gérer université En tant qu’administrateur, je peux ajou- 3
ter, modifier ou supprimer une univer-
sité ainsi que son directeur.
4 Gérer les informations d’une En tant que directeur d’université, je 2
université peux ajouter, modifier ou supprimer des
informations sur mon université par l’en-
voie d’une demande de mise à jour à
l’administrateur.
5 Gérer établissement En tant que directeur d’université, je 3
peux ajouter, modifier, supprimer un
établissement, ainsi que son directeur.
6 Gérer les informations d’un En tant que directeur d’établissement, 3
établissement je peux ajouter, modifier ou supprimer
des informations sur mon établissement
par l’envoie d’un demande de mise à
jour à l’administrateur.
7 Traiter les demander de mise En tant qu’administrateur, je peux trai- 2
à jour ter les demandes de mise à jour de di-
recteur d’université ou directeur d’éta-
blissement.
Table 3.1 – Backlog de sprint 1
3.3 Spécification fonctionnelle de sprint

Afin d’assurer une spécification claire et précise des besoins, nous privilégions l’utilisation
des diagrammes UML tels que les diagrammes de cas d’utilisation et les diagrammes de
séquence. Ces outils visuels nous permettent de mieux comprendre les interactions entre les
différents acteurs impliqués dans notre système, ainsi que les différentes étapes du processus.
Grâce à ces diagrammes, nous pourrons mieux communiquer avec les parties prenantes et
les membres de l’équipe de développement, en assurant une vision commune et partagée du
projet.
27
3.3.1 Diagramme de cas d’utilisation du premier sprint
Le diagramme de cas d’utilisation du premier sprint représente de manière claire et

exhaustive les différentes fonctionnalités que notre application offre à l’utilisateur. La figure
3.1, qui illustre en détail ce diagramme, permettra à l’équipe de développement de mieux
comprendre les besoins et les attentes des utilisateurs finaux, ainsi que de concevoir une
expérience utilisateur optimale en conséquence.
Figure 3.1 – Diagramme de cas d’utilisation du premier sprint
28
3.4 Analyse des cas d’utilisation du premier sprint :
3.4.1 Analyse des cas d’utilisation «S’authentifier»
Description textuelle de cas d’utilisation «s’authentifier»
Cas d’utilisation S’authentifier

Acteurs Utilisateur(Administrateur, directeur d’université,
directeur d’établissement)
Pré-conditions L’utilisateur doit avoir un compte.
Post-conditions L’utilisateur authentifié.
Scénario nominal 1. L’utilisateur clique sur «connexion».
2. Le système affiche le formulaire de connexion.
3. L’utilisateur doit saisir son email et son mot de passe.
4. L’utilisateur valide le formulaire en clinquant sur(Connexion).
5. Le système vérifie les informations saisies par l’utilisateur.
6. Le système redirige vers la page d’accueil.
Scénario alternatif 5.a- L’utilisateur saisit des données incomplètes.
5.a.1- Le système affiche un message d’erreur.
5.a.2- Reprise de l’étape 2 du scénario nominal
5.b- L’utilisateur saisit des données invalides.
5.b.1- Le système affiche un message d’erreur.
5.b.2- Reprise de l’étape 2 du scénario nominal.
Table 3.2 – Description textuelle de cas d’utilisation «s’authentifier»
29
Diagramme de séquence de s’authentifier
Figure 3.2 – Diagramme de séquence de s’authentifier
3.4.2 Analyse de cas d’utilisation « Gérer profil » :
Raffinement du cas d’utilisation « Gérer profil » :
Figure 3.3 – Raffinement du cas d’utilisation « Gérer profil»
30
Analyse de cas d’utilisation « Consulter profil » :
Description textuelle de cas d’utilisation « Consulter profil » :
Cas d’utilisation Consulter profil

Acteurs Utilisateur(Administrateur, directeur d’université, directeur d’éta-
blissement)
Pré-conditions L’utilisateur déjà authentifié .
Post-conditions Les informations de l’utilisateur sont affichées à l’écran.
Scénario nominal 1. L’utilisateur accéde à son profil.
2. Le système affiche les données de son profil.
Scénario alternatif pas d’exceptions.
Table 3.3 – Description textuelle de cas d’utilisation de consulter profil
Diagramme de séquence système de cas d’utilisation « Consulter profil » :
Figure 3.4 – Diagramme de séquence système de cas d’utilisation « Consulter profil »
31
Description textuelle de cas d’utilisation « Modifier profil » :
Cas d’utilisation Modifier profil

Acteurs Utilisateur(Administrateur, directeur d’université,
directeur d’établissement)
Pré-conditions Consulter profil.
Post-conditions Profil modifié.
Scénario nominal 1.L’utilisateur clique sur «Modifier».
2.Le système affiche le formulaire de modification.
3.L’utilisateur modifie l’information qu’il souhaite.
4.L’utilisateur clique sur «Confirmer».
5.Le système vérifie les informations saisies.
6.Le système affiche un message de réussite.
Scénario alternatif 4.a-L’utilisateur clique sur annuler.
4.a.1-Le système annule la modification.
4.a.2-Reprise de l’étape 2 du scénario nominal.
5.a-L’utilisateur saisit des données incorrectes.
5.a.1-Le système affiche un message d’erreur.
Table 3.4 – Description textuelle de cas d’utilisation de modifier profil
32
Diagramme de séquence système du cas d’utilisation « Modifier profil »
Figure 3.5 – Diagramme de séquence système du cas d’utilisation «Modifier profil»
3.4.3 Analyse de cas d’utilisation « Gérer les informations d’un

établissement »
Raffinement du cas d’utilisation « Gérer les informations d’un établissement »
Figure 3.6 – Raffinement du cas d’utilisation «Gérer les informations d’un établissement»
33
Analyse de cas d’utilisation « Consulter les informations d’un établissement »
Description textuelle du cas d’utilisation « Consulter un établissement »
Cas d’utilisation Consulter un établissement

Acteurs Directeur d’établissement
Pré-conditions Directeur d’établissement déjà authentifié.
Post-conditions établissement est affiché à l’écran.
Scénario nominal 1.Le directeur de l’établissement clique sur « Mon établisse-
ment».
2.Le système affiche l’établissement.
Scénario alternatif Pas d’exceptions .
Table 3.5 – Description textuelle de cas d’utilisation « Consulter un établissement »
Diagramme de séquence « consulter un établissement »
Figure 3.7 – Diagramme de séquence « consulter un établissement »
34
Analyse de cas d’utilisation Demander des modifications sur un établissement
Description textuelle de cas d’utilisation « Demande de Modification des infor-

mations sur un établissement »
Cas d’utilisation Demander des modifications des informations d’un établisse-

ment.
Acteurs Directeur d’établissement
Pré-conditions Directeur d’établissement authentifié.
établissement affiché.
Post-conditions des informations modifiée.
Scénario nominal 1.Le directeur d’établissement clique sur « Modifier ».
2.Le système affiche le formulaire de modification d’un
établissement.
3.Le directeur d’établissement rempli le formulaire.
4.Le directeur de l’etablissement clique sur « Envoyer la de-
mande ».
6.Le système affiche un message indiquant que la demande est
envoyée.
Scénario alternatif 4.a-Le directeur de l’établissement clique sur «annuler».
4.a.1-Le système annule l’envoi de la demande.
5.a-Un des champs obligatoires est vide.
5.a.2- Reprise de l’étape 3 du scénario nominal.
5.b-Le directeur de l’établissement saisit les données d’un
établissement déjà existant.
5.b.1-Le système affiche un message d’erreur.
5.b.2-Reprise de l’étape 3 du scénario nominal.
Table 3.6 – Description textuelle de cas d’utilisation «Demander des modifications d’un
établissement»
35
Diagramme de séquence « Demander des modifications des informations d’un
établissement »
Figure 3.8 – Diagramme de séquence « Demander des modifications des informations d’un
établissement »
36
3.4.4 Analyse de cas d’utilisation « Gérer les établissements »
Raffinement du cas d’utilisation « Gérer les établissements »
Figure 3.9 – Diagramme de séquence « Gérer les établissements »
Analyse de cas d’utilisation « Consulter les établissements »
Description textuelle de cas d’utilisation « consulter les établissements »
Cas d’utilisation Consulter les établissements

Acteurs Directeur d’université
Pré-conditions directeur d’université déjà authentifié.
Post-conditions Les établissements sont affichés à l’écran.
Scénario nominal 1.Le directeur d’université clique sur «Liste des
établissements».
2.Le système affiche les établissements.
Table 3.7 – Description textuelle de cas d’utilisation « Consulter les établissements »
37
Diagramme de séquence du cas d’utilisaion « Consulter les établissements »
Figure 3.10 – Diagramme de séquence « Consulter les établissements »
38
Analyse de cas d’utilisation « Ajouter établissement »
Description textuelle de cas d’utilisation « Ajouter établissement »
Cas d’utilisation Ajouter établissement

Pré-conditions directeur d’université authentifié.
Liste des établissements affiché
Post-conditions établissement ajoutée.
Scénario nominal 1. Le directeur d’université clique sur « Ajouter établissement».
2.Le système affiche le formulaire d’ajout d’un établissement
ainsi que les informations de son directeur.
3.Le directeur d’université rempli le formulaire.
4.Le directeur d’université clique sur « confirmer ».
6.Le système affiche un message indiquant que l’établissement
est ajouté avec succès.
Scénario alternatif 3.a-L’adiministrateur clique sur annuler .
3.a.1-Le système annule l’ajout.
5.b-Le directeur de l’université saisit les données d’un
établissement déjà existante.
Table 3.8 – Description textuelle de cas d’utilisation « Ajouter établissement »
39
Diagramme de séquence du cas d’utilisation « Ajouter établissement»
Figure 3.11 – Diagramme de séquence « Ajouter établissement »
40
Analyse de cas d’utilisation « Modifier établissement »
Description textuelle de cas d’utilisation « Modifier établissement »
Cas d’utilisation Modifier établissement

établissement affiché
Post-conditions établissement modifié.
Scénario nominal 1.Le directeur de l’université clique sur « Modifier établisse-
ment ».
2.Le système affiche le formulaire de modification d’un
établissement ainsi que les informations de son directeur.
3.Le directeur de l’université rempli le formulaire.
4.Le directeur de l’université clique sur « confirmer ».
6.Le système affiche un message indiquant que l’établissement
est modifié avec succès.
Scénario alternatif 4.a-Le directeur de l’université clique sur annuler.
5.b-Le directeur d’université saisit les données invalides.
Table 3.9 – Description textuelle de cas d’utilisation « Modifier établissement »
Diagramme de séquence du cas d’utilisation « Modifier établissement »
41
Figure 3.12 – Diagramme de séquence « Modifier établissement »
Analyse de cas d’utilisation « Supprimer établissement »
Description textuelle de cas d’utilisation « Supprimer établissement »
Cas d’utilisation Supprimer établissement

établissement affiché.
Post-conditions établissement supprimé.
42
Scénario nominal 1-Directeur d’université clique sur «Supprimer établissement».
2-Le système affiche la suppression d’un établissement ainsi
que son directeur.
3-Directeur d’université valide la suppression.
4-Le système affiche un message indiquant que l’établissement
est supprimé.
Scénario alternatif 3.a-Directeur d’université annule la suppression.
3.a.1-Le système annule la suppression.
Table 3.10 – Description textuelle de cas d’utilisation « Supprimer établissement »
Diagramme de séquence du cas d’utilisation « Supprimer établissement
Figure 3.13 – Diagramme de séquence «Supprimer établissement»
43
3.4.5 Analyse de cas d’utilisation « Gérer les informations d’une
université »
Raffinement du cas d’utilisation « Gérer les informations d’une université »
Figure 3.14 – Raffinement du cas d’utilisation « Gérer les informations d’une université »
Analyse de cas d’utilisation « Consulter les informations d’une université »
Description textuelle du cas d’utilisation « Consulter une université »
Cas d’utilisation Consulter une université

Pré-conditions Directeur d’université déjà authentifié.
Post-conditions Universités sont affichées à l’écran.
Scénario nominal 1.Le directeur de l’université clique sur « Mon université».
2.Le système affiche l’université.
Table 3.11 – Description textuelle de cas d’utilisation « Consulter une université »
44
Diagramme de séquence « consulter une université »
Figure 3.15 – Diagramme de séquence « Consulter une université »
45
Analyse de cas d’utilisation Demander des modifications sur une université
Description textuelle de cas d’utilisation « Modifier des informations sur une

université »
Cas d’utilisation Demander des modifications des informations d’une université.

Pré-conditions Directeur d’université authentifié.
université affichée
Post-conditions des informations modifiée.
Scénario nominal 1.Le directeur d’université clique sur « Modifier ».
2.Le système affiche le formulaire de modification d’une
université.
3.Le directeur d’univesité rempli le formulaire.
4.Le directeur d’université clique sur « Envoyer le demande ».
6.Le système affiche un message indiquant que le demande est
envoyé.
Scénario alternatif 4.a-Le directeur de l’université clique sur annuler.
4.a.1-Le système annule la demande de modification.
5.b-Le directeur d’université saisit les données d’une université
existante déjà.
Table 3.12 – Description textuelle de cas d’utilisation « Demander des modifications d’une
université »
46
Diagramme de séquence « Demander des modifications des informations d’une
université »
Figure 3.16 – Diagramme de séquence « Demander des modifications des informations

d’une université »
47
3.4.6 Analyse de cas d’utilisation « Gérer les universités » :
Raffinement du cas d’utilisation « Gérer les universités »
Figure 3.17 – Raffinement du cas d’utilisation « Gérer les universités »
Analyse de cas d’utilisation « Consulter les informations d’une université »
Description textuelle de cas d’utilisation «Consulter les universités »
Cas d’utilisation Consulter les universités

Acteurs Administrateur
Pré-conditions Administrateur déjà authentifié.
Post-conditions Les universités sont affichées à l’écran.
Scénario nominal 1.L’administrateur clique sur «Liste des universités».
2.Le système affiche les universités.
Table 3.13 – Description textuelle de cas d’utilisation « Consulter les universités »
48
Diagramme de séquence du cas d’utilisation « Consulter les universités »
Figure 3.18 – Diagramme de séquence du cas d’utilisation « Consulter les universités »
49
Analyse de cas d’utilisation « Ajouter université »
Description textuelle du cas d’utilisation « Ajouter université »
Cas d’utilisation Ajouter université

Pré-conditions Administrateur authentifié.
Liste des universités affichée
Post-conditions Université ajoutée.
Scénario nominal 1.L’administrateur clique sur « Ajouter université».
2.Le système affiche le formulaire d’ajout d’une université ainsi
que les informations de son directeur.
3.L’administrateur rempli le formulaire.
4.L’administrateur clique sur « confirmer ».
6.Le système affiche un message indiquant que l’université est
ajoutée avec succès.
Scénario alternatif 4.a-L’administrateur clique sur annuler.
4.a.1-Le système annule l’ajout.
4.a.2Reprise de l’étape 1 du scénario nominal.
5.b-L’utilisateur saisit les données d’une université existante
déjà.
Table 3.14 – Description textuelle de cas d’utilisation « Ajouter université »
50
Diagramme de séquence du cas d’utilisation « Ajouter université »
Figure 3.19 – Diagramme de séquence « Ajouter université »
51
Analyse de cas d’utilisation « Modifier université »
Description textuelle du cas d’utilisation « Modifier université »
Cas d’utilisation Modifier université

Post-conditions Université modifiée.
Scénario nominal 1. L’administrateur clique sur « Modifier université».
2.Le système affiche le formulaire de modification d’une
université ainsi que les informations de son directeur.
3.L’administrateur rempli le formulaire.
4.L’administrateur clique sur « confirmer ».
modifiée avec succès.
Scénario alternatif 4.a-L’administrateur clique sur annuler.
5.b-L’utilisateur saisit les données invalide.
Table 3.15 – Description textuelle de cas d’utilisation « Modifier université »
52
Diagramme de séquence du cas d’utilisation « Modifier université »
Figure 3.20 – Diagramme de séquence « Modifier université »
53
Analyse de cas d’utilisation « Supprimer université »
Description textuelle du cas d’utilisation « Supprimer université »
Cas d’utilisation Supprimer université

Post-conditions Université supprimée.
Scénario nominal 1.L’administrateur clique sur « Supprimer université».
2.Le système affiche la suppression d’une université ainsi que
son directeur.
3.L’administrateur valide son choix.
4.Le système supprime les établissements liée à l’université
ainsi que l’université.
supprimée.
Scénario alternatif 3.a-L’administrateur annule la supression.
3.a.1-Le système annule la suppression.
Table 3.16 – Description textuelle de cas d’utilisation « Supprimer université »
54
Diagramme de séquence « Supprimer université »
Figure 3.21 – Diagramme de séquence « Supprimer université »
3.4.7 Analyse de cas d’utilisation « traiter les demandes de mise

à jour »
Raffinement du cas d’utilisation « traiter les demandes de mise à jour »
Figure 3.22 – Raffinement du cas d’utilisation « traiter les demandes de mise à jour »
55
Analyse de cas d’utilisation « Consulter les demandes de mise à jour »
escription textuelle du cas d’utilisation « Consulter les demandes de mise à jour

»
Cas d’utilisation Consulter les demandes de mise à jour

Post-conditions La liste des demandes est affichée sur l’écran.
Scénario nominal 1.L’administrateur clique sur «Traiter les demandes de mise à
jour».
2.L’administrateur doit choisir de traiter les demandes liée à
l’établissement ou à l’université.
3.Le système affiche la liste des demandes de mise à jour.
Table 3.17 – Description textuelle de cas d’utilisation « Consulter les demandes de mise à
jour »
Diagramme de séquence « Consulter les demandes de mise à jour »
Figure 3.23 – Diagramme de séquence « Consulter les demandes de mise à jour »
56
Analyse de cas d’utilisation « Approuver/Refuser les demandes de mise à jour »
Description textuelle du cas d’utilisation «Approuver/Refuser les demandes de

mise à jour»
Cas d’utilisation Approuver/Refuser les demandes de mise à jour

Liste des demandes consultée
Post-conditions La demande est approuvée/refusée.
Scénario nominal 1.L’administrateur choisi la demande à traiter.
2.L’administrateur confirme son choix.
Scénario alternatif Pas d’exceptions.
Table 3.18 – Description textuelle de cas d’utilisation « Approuver/Refuser les demandes

de mise à jour »
57
Diagramme de séquence « Approuver/Refuser les demandes de mise à jour »
Figure 3.24 – Diagramme de séquence « Approuver/Refuser les demandes de mise à jour »
3.5 Conception des cas d’utilisation :

Afin de réaliser les diagrammes de séquences système et les descriptions textuelles des cas
d’utilisation, nous allons élaborez les diagrammes de classes participantes pour chaque acteur
et les diagrammes de séquence détaillé pour chacun des cas d’utilisation étudiés.
3.5.1 Diagramme des classes participantes :
Le diagramme des classes participantes est un élément clé qui relie les cas d’utilisation
aux diagrammes de conception logicielle tels que les diagrammes d’interaction et de classes.
Il représente trois types de classes d’analyse, à savoir les classes de dialogue, de contrôle et
d’entité, ainsi que leurs relations. C’est une étape importante dans la modélisation de notre
système car elle permet de visualiser l’interaction entre les différentes classes et de mieux
comprendre le fonctionnement global du système.[8]
58
Diagramme de classes participants par acteur «Utilisateur».
Figure 3.25 – Diagramme de classes participants par acteur «Utilisateur»
Diagramme de classes participants par acteur «Directeur d’établissement».
Figure 3.26 – Diagramme de classes participants par acteur «Directeur d’établissement»
59
Diagramme de classes participants par acteur «Directeur d’université».
Figure 3.27 – Diagramme de classes participants par acteur «Directeur d’université»
Diagramme de classes participants par acteur «Administrateur».
Figure 3.28 – Diagramme de classes participants par acteur «Administrateur»
60
3.5.2 Diagramme de séquence détaillé :
Un diagramme de séquence détaillé est une représentation graphique de l’interaction entre

des objets ou des acteurs dans un système. Il montre comment les messages sont envoyés
entre les objets ou les acteurs et comment ils répondent aux messages reçus.
Diagrammes de séquence détaillé de cas d’utilisation « S’authentifier »
Figure 3.29 – Diagrammes de séquence détaillé de cas d’utilisation « S’authentifier »
61
Diagramme de séquence détaillé de cas d’utilisation « Consulter profil»
Figure 3.30 – Diagramme de séquence détaillé de cas d’utilisation « Consulter profil»
Diagramme de séquence détaillé de cas d’utilisation « Modifier profil »
Figure 3.31 – Diagramme de séquence détaillé de cas d’utilisation « Modifier profil»
62
Diagramme de séquence détaillé « Gérer les informations d’un établissement »
Diagramme de séquence détaillée du cas d’utilisation «Consulter établissement»
Figure 3.32 – Diagramme de séquence détaillé de cas d’utilisation «Consulter établissement»
63
Diagramme de séquence détaillée du cas d’utilisation «Demande des modifications
des informations d’un établissement»
Figure 3.33 – Diagramme de séquence détaillé de cas d’utilisation «Demande des modifica-
tions des informations d’un établissement»
64
Diagramme de séquence détaillé « Gérer établissement »
Diagramme de séquence détaillé du cas d’utilisation « Afficher la liste des éta-

blissements »
Figure 3.34 – Diagramme de séquence détaillé de cas d’utilisation « Afficher la liste des
établissements »
65
Diagramme de séquence détaillé du cas d’utilisation « Ajouter établissement »
Figure 3.35 – Diagramme de séquence détaillé de cas d’utilisation «Ajouter établissement»
66
Diagramme de séquence détaillé de cas d’utilisation « Modifier établissement »
Figure 3.36 – Diagramme de séquence détaillé de cas d’utilisation «Modifier établissement»
67
Diagramme de séquence détaillé de cas d’utilisation « Supprimer établissement »
Figure 3.37 – Diagramme de séquence détaillé de cas d’utilisation «Supprimer établissement»
Diagramme de séquence détaillé « Gérer les informations d’une université »
Diagramme de séquence détaillée du cas d’utilisation «Consulter université»
Figure 3.38 – Diagramme de séquence détaillé de cas d’utilisation « Consulter université »
68
Diagramme de séquence détaillé de cas d’utilisation «Demande des modifications
des informations d’une université»
Figure 3.39 – Diagramme de séquence détaillé de cas d’utilisation «Demande des modifica-
tions des informations d’une université»
69
Diagramme de séquence détaillé « Gérer les université»
Diagramme de séquence détaillé du cas d’utilisation « Afficher la liste des univer-

sités »
Figure 3.40 – Diagramme de séquence détaillé de cas d’utilisation «Afficher la liste des
universités »
70
Diagramme de séquence détaillé du cas d’utilisation « Ajouter université »
Figure 3.41 – Diagramme de séquence détaillé de cas d’utilisation «Ajouter université »
71
Diagramme de séquence détaillé du cas d’utilisation « Modifier université »
Figure 3.42 – Diagramme de séquence détaillé de cas d’utilisation «Modifier université »
72
Diagramme de séquence détaillé du cas d’utilisation « Supprimer université »
Figure 3.43 – Diagramme de séquence détaillé de cas d’utilisation « Supprimer université »
Diagramme de séquence détaillé « Traiter les demandes de mise à jour »
Diagramme de séquence détaillée du cas d’utilisation «Consulter les demandes

de mise à jour»
Figure 3.44 – Diagramme de séquence détaillé de cas d’utilisation «Consulter les demandes
de mise à jour»
73
Diagramme de séquence détaillée du cas d’utilisation «Approuver/Refuser un
demande de mise à jour»
Figure 3.45 – Diagramme de séquence détaillé de cas d’utilisation «Approuver/Refuser un

demande de mise à jour»
3.6 Diagramme de classe globale du premier sprint

Ce diagramme de classes est considéré comme le plus important de la modélisation
orientée objet. Il permet de fournir une représentation abstraite des objets du système qui
vont interagir entre eux. La figure 3.46 illustre le diagramme de classes de notre premier
sprint et les relations qui existent entre ses différentes classes.
74
Figure 3.46 – Diagramme de classe globale du premier sprint
3.7 Implémentation
L’étape d’implémentation ou de "codage" consiste à mettre en œuvre les "user stories" qui
ont été traitées lors du premier sprint. Pendant cette étape, nous allons définir la structure
de la base de données pour le sprint en cours, tout en appliquant les règles de transformation
du modèle entité/association en modèle relationnel.
Règle 1 : Chaque entité du modèle entité/association est transformée en une relation

dans le modèle relationnel.
Règle 2 : Lorsqu’il y a une association "un à plusieurs", la clé primaire de la relation mère
est migrée vers la relation fille en tant que clé étrangère.
Règle 3 : Lorsqu’il y a une association "plusieurs à plusieurs", une relation est créée avec
une clé primaire composée des clés primaires des relations associées.
75
3.7.1 Les Schéma de la base de données
Attribut Type Contrainte

id INT(20) PRIMARY KEY
email VARCHAR(255) -
firstname VARCHAR(255) -
lastname VARCHAR(255) -
password VARCHAR(255) -
Table 3.19 – Table « User ».

idrole INT(20) PRIMARY KEY
role-name VARCHAR(255) -
userr-role INT(20) FOREIGN KEY
Table 3.20 – Table « Role ».

adresse VARCHAR(255) -
description VARCHAR(255) -
fax VARCHAR(255) -
name VARCHAR(255) -
téléphone VARCHAR(255) -
Table 3.21 – Table « Université ».
76
adresse VARCHAR(255) -
description VARCHAR(255) -
fax VARCHAR(255) -
name VARCHAR(255) -
téléphone VARCHAR(255) -
établissement-id INT(20) FOREIGN KEY
Table 3.22 – Table « Etablissement ».

date-debut INT(20) FOREIGN KEY
date-fin INT(20) FOREIGN KEY
Table 3.23 – Table « Date-mandat ».
3.7.2 Maquettes
Cette section a pour but de présenter les différentes interfaces développées au cours de ce
sprint sous forme de maquettes. Le maquettage est une technique de conception d’interface
qui permet de simuler de manière complète ou partielle les interfaces utilisateur attendues
afin d’obtenir une idée de la manière dont les utilisateurs interagiront avec l’application à
venir.
77
Maquette de l’interface «Authentification»
Figure 3.47 – Maquette de l’interface «Authentification»
Maquette de l’interface «Consulter profil»
Figure 3.48 – Maquette de l’interface «Consulter profil»
78
Maquette de l’interface «Liste des universités»
Figure 3.49 – Maquette de l’interface «Liste des universités»
Maquette de l’interface «Ajouter université»
Figure 3.50 – Maquette de l’interface «Ajouter université»
79
Maquette de l’interface «Modifier université»
Figure 3.51 – Maquette de l’interface «Modifier université»
Maquette de l’interface «Supprimer université»
Figure 3.52 – Maquette de l’interface «Supprimer université»
80
Maquette de l’interface «Demande de modification»
Figure 3.53 – Maquette de l’interface «Demande de modification»
Maquette de l’interface «Traiter les demandes de MAJ»
Figure 3.54 – Maquette de l’interface «Traiter les demandes de MAJ»
Les figures 3.47/ 3.48/ 3.49/ 3.50,/ 3.51/ 3.52/ 3.53/ 3.54 présente les maquettes des
interfaces réalisées de sprint 1 qui sont la maquette de l’interface d’authentification, la
maquette de l’interface "Consulter profil", la maquette de l’interface "Modifier profil", la
maquette de l’interface de "liste des universités", la maquette de l’interface de "Ajouter
université", la maquette de l’interface de "Modifier université", la maquette de l’interface de
"Supprimer université", la maquette de l’interface de "Consulter établissement, la maquette
de l’interface de "Demander des modifications", et la maquette de l’interface de "Traiter les
demandes de mise à jour".
81
3.7.3 Réalisation
Cette partie est consacrée à l’exposition du travail achevé à travers des captures d’écrans
de différentes interfaces développées durant ce sprint.
Figure 3.55 – Interface d’authentification
82
La figure 3.55 présente l’interface d’authentification et l’interface de récupération de mot
de passe. Pour s’authentifier, l’utilisateur doit saisir son email et son mot de passe. Puis,
il doit collectionner sur le bouton "se connecter". S’il a oublié son mot de passe, il doit
sélectionner sur le lien "Mot de passe oublié ?" pour récupérer son mot de passe.
Figure 3.56 – Interface de la liste des universités
La figure 3.56 présente l’interface de la page d’accueil. Aprés l’authentification de l’uti-

lisateur, le système va rediriger vers la page d’accueil où l’utilisateur peut choisir une
fonctionnalité.
83
Figure 3.57 – Interface «Liste des établissements»
La figure 3.57 présente l’interface de «liste des établissements».
3.7.4 Test
Dans la méthode agile, les tests jouent un rôle crucial pour assurer la fiabilité des fonc-
tionnalités développées. Il est impératif de les effectuer avant chaque sprint afin de garantir
que le développement se déroule sans encombre. En d’autres termes, l’importance des tests
ne peut être sous-estimée dans le processus de développement agile.
Les tests unitaires
Un test unitaire est une méthode qui permet de vérifier le bon fonctionnement d’une
unité de programme. En d’autres termes, il s’agit d’un processus qui permet de confirmer
que l’unité de code testée fonctionne comme prévu.
En utilisant Spring Boot pour développer notre application web, nous avons l’avantage
de bénéficier de fonctionnalités intégrées pour effectuer différents types de tests. Pour tester
les API REST, nous pouvons utiliser l’outil de test Postman qui nous permet de vérifier
84
facilement le fonctionnement de nos endpoints. En outre, Spring Boot offre des options de test
unitaire et d’intégration avec des classes de test intégrées pour s’assurer que notre application
fonctionne correctement à tous les niveaux.
Le test unitaire du cas d’utilisation « Ajouter Université »
Cas de succès de test « Ajouter Université »
Figure 3.58 – Code de source de la méthode de test d’ajout d’une université.
85
Figure 3.60 – Interface de résultat du test d’ajout d’une université.
Cas d’échec de test « Ajouter Université »
En cas d’échec, notre méthode de test doit retourner un message indiquant que l’université
est déjà existe.
86
Figure 3.63 – Interface de résultat du test d’ajout d’une université.
Le test unitaire du cas d’utilisation « Modifier Université »
Cas de succès de test « Modifier Université »
Figure 3.64 – Code de source de la méthode de test de modification d’une université.
87
Figure 3.66 – Interface de résultat du test de modification d’une université.
Cas d’échec de test « Modifier Université »
En cas d’échec, notre méthode de test doit retourner un message indiquant que la méthode
testée n’a pas retourné le résultat prévu. Nous avons essayé de modifier une université en
déclarant l’attribut ‘adresse’ est NULL et nous avons eu un message d’échec.
88
Figure 3.69 – Interface de résultat du test de modification d’une université.
89
Le test unitaire du cas d’utilisation « Supprimer Université »
Cas de succès de test « Supprimer Université »
Figure 3.70 – Code de source de la méthode de test de suppression d’une université.
Figure 3.71 – Interface de résultat du test de suppression d’une université.
Cas d’échec de test « Supprimer Université »
En cas d’échec, notre méthode de test doit retourner un message indiquant que l’université
n’existe pas.
90
Figure 3.72 – Code de source de la méthode de test de suppression d’une université.
Figure 3.73 – Interface de résultat du test de suppression d’une université.
3.7.5 Revue de sprint - Diagramme de « Burn down Chart »
Le Burndown Chart s’avère être un graphique succinct reflétant le niveau d’accomplisse-

ment de diverses tâches. Autrement dit, il s’agit d’une illustration graphique de la progression
de la quantité de travail restant à effectuer, en fonction du temps, tout au long d’une période
donnée.
91
Figure 3.74 – Tableau de valeurs de Brundown Chart du sprint 1.
92
Figure 3.75 – Diagramme de Burn down Chart du sprint 1.
3.8 Conclusion
A travers ce chapitre, nous avons présenté notre conception du premier sprint de notre
application. Nous avons fourni, dans un premier lieu, une conception globale de l’organisation
de notre système. Ensuite, nous avons présenté la conception détaillée à travers des diagrammes
UML et des tableaux du cas d’utilisation. Enfin, nous avons présenté les maquettes et les
interfaces réalisées.
Dans le chapitre suivant nous allons passer à la mise en œuvre du deuxième sprint de notre
projet.
93
Chapitre 4
« Sprint 2 : Consultation, réclamation

et évaluation des informations de
l’annuaire »
4.1 Introduction
Maintenant, que le premier sprint de notre projet est terminé, nous nous tournons vers la
mise en œuvre du deuxième sprint.
Nous commençons par présenter le backlog de sprint suivi d’une analyse détaillée et d’une
conception.
4.2 Sprint 2
le but de sprint est de mettre en oeuvre les stories qui sont présentées par le tableau de
backlog de sprint.
4.2.1 Backlog de sprint
Nous commençons cette partie en présentant le backlog de sprint, suivi d’une analyse
approfondie et d’une phase de conception. Nous illustrons ensuite cette partie avec des
maquettes et des interfaces créées au cours de ce sprint.
Le tableau 4.1 décrit les stories de notre backlog de sprint 2.
94
Id Titre User Story Priorité
1 Consulter les établissementsEn tant que visiteur, je veux consulter 1
les établissements
3 Chercher des établissements En tant que visiteur, je veux chercher 3
des spécialités.
4 Chercher les spécialités En tant que visiteur, je veux chercher 3
des spécialité.
5 Recommander établissement En tant que visiteur je veux recomman- 2
der un établissement.
6 Evaluer établissement En tant que visiteur, je veux évaluer un 2
établissement.
2 Consulter les statistiques En tant que visiteur, je veux consulter 1
les statistiques.
Table 4.1 – Backlog de sprint 2
4.3 Spécification fonctionnelle de sprint

Pour la spécification des besoins, nous nous référerons aux diagrammes d’UML : les
diagrammes de cas d’utilisation les descriptions textuelles et les diagrammes de séquence.
4.3.1 Diagramme de cas d’utilisation
La figure 4.1 représente le diagramme de cas d’utilisation de sprint 3.
Figure 4.1 – Diagramme de cas d’utilisation de sprint 2
95
Ce diagramme de cas d’utilisation présente les différentes fonctionnalités qu’un visiteur
peut effectuer. Il peut :
✓Consulter les établissements.
✓Chercher des établissements.
✓Chercher des spécialités.
✓Recommander établissement.
✓Évaluer établissement.
✓Consulter les statistiques.
4.4 Analyse des cas d’utilisation
4.4.1 Analyse de cas d’utilisation « Consulter les établissements »
Description textuelle de cas d’utilisation « Consulter les établissements »
Le tableau 4.2 expose les acteurs et les différents scénarios du cas d’utilisation de consulter
les établissements.

Acteurs Visiteur
Pré-conditions visiteur accède à l’annuaire.
Post conditions liste des établissements affiché.
Scénario nominal 1-Le visiteur accède à la page "Accueil".
2-Le visiteur choisis l’université.
3-Le système affiche la liste des établissements.
Scénario alternatif Néant.
Table 4.2 – Description textuelle du cas d’utilisation « Consulter les établissements ».
96
Diagramme de séquence système du cas d’utilisation «Consulter les établisse-
ments»
Figure 4.2 – Diagramme de séquence système du cas d’utilisation « Consulter les établisse-
ments »
4.4.2 Analyse de cas d’utilisation « Chercher établissement »
Description textuelle de cas d’utilisation « Chercher établissement »
Le tableau 4.4 expose les acteurs et les différents scénarios du cas d’utilisation « Chercher
établissement ».
Cas d’utilisation Chercher établissement

Acteurs Visiteur
Pré-conditions Visiteur accède à l’annuaire.
Post-conditions Recherche effectuée.
Scénario nominal 1-Le visiteur clique sur « Recherche ».
2-Le système affiche l’espace de recherche.
3-Le visiteur saisir les mots clés souhaités.
4-le système vérifie les données saisies.
5-Le système affiche l’établissement recherché.
97
Scénario alternatif 4.a-Données manquantes.
4.a.2-Reprise de l’étape 3 du Scénario nominal.
4.b-Données introuvables.
Table 4.3 – Description textuelle du cas d’utilisation « Chercher établissement ».
Diagramme de séquence système du cas d’utilisation « Chercher établissement »
Figure 4.3 – Diagramme de séquence système du cas d’utilisation «Chercher établissement»
98
4.4.3 Analyse de cas d’utilisation « Chercher spécialité »
Description textuelle de cas d’utilisation « Chercher spécialité »
Le tableau 4.5 expose les acteurs et les différents scénarios du cas d’utilisation « Chercher
spécialité ».
Cas d’utilisation Chercher spécialité

Acteurs Visiteur
Post-conditions Recherche effectuée.
Scénario nominal 1-Le visiteur clique sur « Recherche ».
2-Le système affiche l’espace de recherche.
3-Le visiteur saisir les mots clés souhaités.
4-le système vérifie les informations saisies.
5-Le système affiche les établissements associé à la spécialité.
4.b-Données introuvables.
Table 4.4 – Description textuelle du cas d’utilisation « Chercher spécialité ».
99
Diagramme de séquence système du cas d’utilisation « Chercher spécialité »
Figure 4.4 – Diagramme de séquence système du cas d’utilisation «Chercher spécialité»
4.4.4 Analyse de cas d’utilisation « Recommander établissement »
Description textuelle de cas d’utilisation « Recommander établissement »
Le tableau 4.3 expose les acteurs et les différents scénarios du cas d’utilisation « Recom-
mander établissement ».
100
Cas d’utilisation Recommander établissement
Acteurs Visiteur
Pré-conditions Établissement consulté.
Post-conditions Recommandation effectuée.
Scénario nominal 1-Le visiteur clique sur « Recommandation établissement ».
2-Le système affiche le formulaire de recommandation.
3-Le visiteur remplis le formulaire et clique sur «Envoyer».
4-le système vérifie les informations saisies.
5-le système affiche ("Recommandation envoyée").
Table 4.5 – Description textuelle du cas d’utilisation « Recommander établissement ».
101
Diagramme de séquence système du cas d’utilisation « Recommander établisse-
ment »
Figure 4.5 – Diagramme de séquence système du cas d’utilisation «Recommander établisse-

ment»
4.4.5 Analyse de cas d’utilisation « Évaluer établissement »
Description textuelle de cas d’utilisation « Évaluer établissement »
Le tableau 4.3 expose les acteurs et les différents scénarios du cas d’utilisation « Évaluer
établissement ».
102
Cas d’utilisation Évaluer établissement
Acteurs Visiteur
Pré-conditions Établissement consulté.
Post-conditions Évaluation effectuée.
Scénario nominal 1-Le visiteur clique sur « Évaluer ».
2-Le système affiche le champ d’évaluation.
3-Le visiteur donne son avis et clique sur «Envoyer».
4-Le système enregistre la réponse.
Table 4.6 – Description textuelle du cas d’utilisation « Évaluer établissement ».
Diagramme de séquence système du cas d’utilisation « Évaluer établissement »
Figure 4.6 – Diagramme de séquence système du cas d’utilisation «Évaluer établissement»
103
4.4.6 Analyse de cas d’utilisation « Consulter les les statistiques »
Description textuelle du cas d’utilisation « Consulter les statistiques ».

Acteurs Visiteur
Post-conditions Statistiques consultées.
Scénario nominal 1-Le visiteur clique sur l’élément du menu (Statistiques).
2-Le système affiche les statistiques détaillées.
Table 4.7 – Description textuelle du cas d’utilisation « Consulter les statistiques ».
Diagramme de séquence système du cas d’utilisation « Consulter les statistiques

»
Figure 4.7 – Diagramme de séquence système du cas d’utilisation «Consulter les statistiques»
Ce tableau contient la description de la fonctionnalité "Gérer les membres des projets"

sous la forme d’une séquence de messages échangés entre les acteurs et le système. Il contient
aussi une séquence nominale qui décrit le déroulement normal de cette fonctionnalité.
104
4.5 Conception des cas d’utilisation
4.5.1 Diagramme de classes participantes
Le diagramme des classes participantes est un élément clé qui relie les cas d’utilisation
aux diagrammes de conception logicielle tels que les diagrammes d’interaction et de classes.
Il représente trois types de classes d’analyse, à savoir les classes de dialogue, de contrôle et
d’entité, ainsi que leurs relations. C’est une étape importante dans la modélisation de notre
système car elle permet de visualiser l’interaction entre les différentes classes et de mieux
comprendre le fonctionnement global du système.[8]
Diagramme de classes participantes par acteur « Visiteur »
Figure 4.8 – Diagramme de classes participantes par acteur « Visiteur »
105
4.5.2 Diagramme de séquence détaillé
Un diagramme de séquence détaillé est une représentation graphique de l’interaction entre

des objets ou des acteurs dans un système. Il montre comment les messages sont envoyés
entre les objets ou les acteurs et comment ils répondent aux messages reçus.
Diagramme de séquence détaillé du cas d’utilisation «Consulter les établisse-

ments».
Figure 4.9 – Diagramme de séquence détaillé du cas d’utilisation «Consulter les établisse-
ments»
106
Diagramme de séquence détaillé du cas d’utilisation « chercher établissement ».
Figure 4.10 – Diagramme de séquence détaillé du cas d’utilisation «Chercher établissement»
107
Diagramme de séquence détaillé du cas d’utilisation «chercher spécialité».
Figure 4.11 – Diagramme de séquence détaillé du cas d’utilisation «Chercher spécialité»
108
Diagramme de séquence détaillé du cas d’utilisation «Recommander établisse-
ment».
Figure 4.12 – Diagramme de séquence détaillé du cas d’utilisation «Recommander établis-

sement»
109
Diagramme de séquence détaillé du cas d’utilisation « Évaluer établissement ».
Figure 4.13 – Diagramme de séquence détaillé du cas d’utilisation «Évaluer établissement»
110
Diagramme de séquence détaillé du cas d’utilisation «Consulter les statistiques».
Figure 4.14 – Diagramme de séquence détaillé du cas d’utilisation «Consulter les statis-
tiques»
4.6 Diagramme de classe globale du deuxième sprint

Le diagramme de classes est considéré comme l’un des éléments les plus essentiels de
la modélisation orientée objet. Il permet de représenter de manière abstraite les objets du
système qui interagissent les uns avec les autres. Dans la figure 4.15, nous pouvons observer
le diagramme de classes que nous avons élaboré pour notre deuxième sprint.
111
Figure 4.15 – Diagramme de classe globale du deuxième sprint
4.6.1 Implémentation
Au cours de cette étape, nous allons utiliser les règles de conversion du modèle en-
tité/association vers le modèle relationnel pour déterminer la structure de la base de données
qui sera utilisée durant le sprint actuel.
Les Schéma de la base de données

name VARCHAR(255) -
Table 4.8 – Table « EvaluationEtablissement ».
112
name VARCHAR(255) -
Table 4.9 – Table « RecommandationEtablissement ».
4.6.2 Maquettes
Dans cette partie, nous présentons les différentes maquettes des interfaces à développer
pendant ce sprint. La figure 4.16 expose les trois maquettes de ce sprint qui sont la maquette
de l’interface de gestion des permissions, la maquette de l’interface d’affectation d’un rôle à
un utilisateur et la maquette l’interface de gestion des membres dans un projet.
Maquette de l’interface «Accueil»
Figure 4.16 – Maquette de l’interface «Accueil»
113
Maquette de l’interface «Consulter établissement»
Figure 4.17 – Maquette de l’interface «Consulter établissement»
Maquette de l’interface «Consulter Statistiques»
Figure 4.18 – Maquette de l’interface «Consulter Statistiques»
114
4.6.3 Réalisation
L’implémentation ou la réalisation est une phase la plus importante après celle de la

conception.
Dans cette partie, nous illustrons le travail achevé par des captures d’écrans pendant ce
sprint.
Figure 4.19 – Interface de la liste universités
Figure 4.20 – Interface d’inviter un membre
115
4.6.4 Test
Pendant cette étape, nous allons confronter les résultats escomptés avec ceux que nous
avons obtenus. Cela nous permettra de vérifier que les méthodes que nous avons implémentées
auparavant fonctionnent correctement.
Les tests unitaires
Dans cette section, nous allons utiliser le Framework de tests unitaires open source
Postman pour présenter plusieurs exemples de tests unitaires que nous avons effectués, ainsi
que la méthodologie que nous avons suivie pour les réaliser.
Cas de succès de test « Chercher établissement »
Figure 4.21 – Code de source de la méthode de test «Chercher établissement».
116
Figure 4.22 – Interface de résultat du test de recherche d’un établissement.
Cas d’échec de test « Chercher établissement »
117
4.6.5 Revue de sprint - Diagramme de « Burndown Chart »
La revue de sprint a pour but d’examiner les résultats obtenus au cours de cette itération.
118
Figure 4.25 – Tableau de valeurs de Brundown Chart du sprint 2.
119
Figure 4.26 – Diagramme de Burn down Chart du sprint 1.
4.7 Conclusion
A travers ce chapitre, nous avons présenté notre conception du deuxième sprint de notre
application. D’abord, nous avons fourni une conception détaillée à travers les diagrammes
UML et les tableaux du cas d’utilisation. Ensuite, nous avons présenté les maquettes qui
nous aident à la réalisation de l’application. Enfin, nous avons exposé les interfaces réalisées.
120
Chapitre 5
Phase de clôture
5.1 Introduction
Le chapitre final couvrira les dernières étapes du cycle de développement Scrum. Nous
commencerons par dresser la liste des environnements matériels et logiciels utilisés pour la
mise en œuvre du projet. Ensuite, nous présenterons un schéma de déploiement illustrant
l’architecture de notre application, ainsi qu’un diagramme des différentes tâches accomplies
tout au long du projet.
5.2 Environnement de travail

Dans cette partie, nous décrivons l’environnement et les outils du travail. Par la suite nous
exposons l’environnement matériel et l’environnement de développement de notre application.
5.2.1 Environnement matériel
Tout au long de notre projet, nous avons utilisé comme environnement matériel un
ordinateur portable qui dispose les caractéristique suivantes :
— Marque : DELL
— Processeur : Intel(R) Core(TM) i3-3217U CPU @ 1.80GHz.
— Mémoire physique (RAM) installé : 6.00 Go
— Disque Dur : 512
121
5.2.2 Environnement de développement et de modélisation
Nous présentons les outils utilisés pendant le développement de notre application.
• Spring Tool Suit [9] : Spring Tool Suite est un framework open source conçu pour
faciliter la définition et la construction de l’infrastructure d’une application Java, tout
en simplifiant le processus de développement et de test. La figure 2.5 met en avant le
logo de Spring Tool Suite.
Figure 5.1 – logo de Spring Tool Suit
• Visual Studio Code [10] : C’est un éditeur de code extensible développé par Microsoft
pour Windows, Linux et macOS et orienté pour les langages Web. Il offre plusieurs
fonctionnalités telles que l’auto complétion, la détection d’erreurs, le formatage de
code,...etc. La figure 2.6 présente le logo de Visual Studio Code.
Figure 5.2 – logo de Visual Studio Code
• Taiga [11] : C’est une plateforme de gestion de projet, open source qui facilite la
gestion et l’organisation de projet. Il dispose une interface claire, simple et facile à
comprendre l’état d’avancements des tâches du projet. La figure 2.7 présente le logo de
Taiga.
122
Figure 5.3 – logo de Taiga
• Draw.io [12] :Draw.io est une application gratuite en ligne, accessible via un navigateur
web sécurisé en protocole https. Cet outil permet de créer facilement des diagrammes
et des organigrammes. Il offre une grande variété de fonctions permettant de concevoir
des dessins vectoriels et de les sauvegarder au format XML, ainsi que de les exporter
selon différents formats. La figure 2.8 présente le logo de Draw.io.
Figure 5.4 – logo de Draw io
• Lucidchart [13] :Lucidchart est une plateforme de collaboration en ligne basée sur
le cloud, qui permet de créer des diagrammes, des visualisations de données ainsi que
d’autres schémas conceptuels. La figure 2.8 illustre le logo de Lucidchart.
123
Figure 5.5 – logo de Lucidchart
• Latex [14] :Le LaTeX (représenté par le logo LATEX) est un langage et un système
de composition de documents. Il se compose d’une série de macro-commandes conçues
pour simplifier l’utilisation du traitement de texte. La figure 2.8 montre le logo de LaTeX.
Figure 5.6 – logo de Latex
• Balsamiq [15] :Balsamiq est un logiciel de conception de wireframes, qui permet aux
équipes de créer des maquettes et des prototypes interactifs, ainsi que de réaliser des
tests utilisateur. Cet outil est destiné à tous ceux qui souhaitent créer des wireframes,
sans avoir besoin de compétences particulières en web design. La figure 2.8 présente le
logo de Balsamiq.
124
Figure 5.7 – logo de Balsamiq
• Xampp [16] :XAMPP est une suite de logiciels qui permet de configurer facilement
un serveur Web local, un serveur FTP et un serveur de messagerie électronique. Cette
distribution de logiciels libres est connue pour sa grande flexibilité d’utilisation et pour
son installation rapide et facile. La figure 2.8 présente le logo de XAMPP.
Figure 5.8 – logo de Xampp
• phpMyAdmin [17] :Il s’agit d’une application Web de gestion des systèmes de gestion
de base de données MySQL et MariaDB, principalement développée en PHP, appelée
phpMyAdmin. Cette application permet de gérer les bases de données de manière
conviviale et intuitive. La figure 2.8 présente le logo de phpMyAdmin.
Figure 5.9 – logo de phpMyAdmin
125
5.2.3 Environnement logiciel
Nous présentons les frameworks et les logiciels utilisés dans notre application.
• Angular [18] : Il s’agit d’un Framework JavaScript Open Source nommé Angular,
développé par Google. Il offre de nombreuses fonctionnalités avancées qui permettent de
créer des applications Web puissantes. De plus, il propose des services pour l’animation,
les requêtes HTTP et d’autres encore. La figure 2.9 présente le logo d’Angular.
Figure 5.10 – Logo d’Angular
• Spring Boot [19] : Le Framework Java Spring (Spring Framework) est une infrastruc-
ture open source fréquemment utilisée en entreprise pour développer des applications
autonomes de production qui s’exécutent sur la machine virtuelle Java (JVM). Le logo
de Spring Boot est présenté dans la figure 2.10.
Figure 5.11 – Logo de Spring Boot
5.3 Architecture de l’application

Dans cette partie, nous présentons l’architecture physique et logique de notre projet.
126
5.3.1 Architecture logique
Afin de concevoir l’architecture logique de notre système, nous avons choisi d’utiliser le
pattern d’architecture MVC (Modèle - Vue - Contrôleur), qui est une méthode permettant
d’organiser l’interface d’un programme en trois entités distinctes : le modèle, la vue et le
contrôleur. Chacune de ces entités a un rôle bien défini dans la gestion de l’interface. Dans
l’architecture MVC, les rôles des trois entités sont les suivants :
• Modèle : données (accès et mise à jour)
• Vue : interface utilisateur (entrées et sorties)
• Contrôleur : gestion des événements et synchronisation
La figure 2.12 expose l’architecture MVC.
Figure 5.12 – Architecture MVC [20]
5.3.2 Architecture physique
Nous nous basons sur les orientations techniques de notre application, dans cette partie
nous présentons l’architecture physique de l’application et les technologies utilisées.
127
Figure 5.13 – Architecture physique de l’application
La figure 2.13 présente l’architecture physique de notre application qui est construite par
deux parties :
Côté Serveur avec Spring Boot :
— Gestion des requêtes HTTP.
— Sécurité avec Spring Security.
— Persistance des données avec JPA et Hibernate.
— Intégration de services tiers.
Côté Client avec Angular :
— Gère plusieurs modules.
— Gère un composant service injecté dans différents composants.
— Gère un composant qui fait office de contrôleur.
Les notions de modules, de composants et d’injection de services sont les points les plus
intéressants dans le Framework Angular.
5.3.3 Diagramme de Gantt
Le diagramme de Gantt est un outil couramment utilisé en gestion de projet pour visualiser
l’état d’avancement des différentes activités qui constituent un projet. Ce diagramme se
128
compose d’une colonne de gauche qui énumère toutes les tâches à effectuer, et d’une ligne
d’en-tête qui représente les unités de temps les plus adaptées au projet, telles que les jours,
les semaines ou les mois. Chaque tâche est représentée par une barre horizontale dont la
position et la longueur reflètent la date de début, la durée et la date de fin. En somme, le
diagramme de Gantt est considéré comme l’un des outils les plus efficaces pour représenter
visuellement l’avancement d’un projet.[21]
Figure 5.14 – Diagramme des taches.
5.4 Conclusion
Dans ce chapitre, nous avons exposé en détail l’environnement de travail que nous avons
mis en place pour notre application, ainsi que l’architecture globale de celle-ci. Nous avons
décrit les différentes technologies utilisées, les outils de développement, les systèmes d’exploi-
tation, les langages de programmation, les frameworks et les librairies, afin de donner une
vue d’ensemble précise de l’environnement technique de notre projet. Nous avons également
présenté l’architecture logicielle de l’application, en décrivant les différentes couches fonction-
nelles et leur rôle dans le fonctionnement global de l’application.
129
Conclusion générale
Dans ce rapport, nous présentons notre travail et notre expérience de stage au sein de
CCK dans le cadre de notre projet de fin d’études, dans le but d’obtenir notre Licence
Appliquée en Informatique de Gestion à l’École Supérieure d’Economie Numérique (ESEN).
Ce stage de fin d’études représente une expérience incontournable pour tout étudiant sou-
haitant s’acclimater à la vie professionnelle et découvrir l’environnement de travail au sein
d’une entreprise. Pendant cette période, nous avons eu l’occasion de mettre en pratique les
connaissances acquises au cours de notre parcours académique. Cette expérience a été rendue
possible grâce à l’encadrement et au soutien de nos tuteurs, qui ont joués un rôle important
dans notre réussite.
Dans le cadre de notre projet de fin d’étude effectué au sein du CCK, nous avons développé
une application web dont l’objectif est de mettre en oeuvre un annuaire universitaire interactif
bien référencé.
Ce présent rapport commence par une présentation sur le contexte général de notre stage au
sein de l’entreprise CCK. Après avoir identifié les besoins à travers la capture des exigences,
nous avons divisé notre projet en deux sprints puisque nous avons choisi d’utiliser la mé-
thodologie Agile "SCRUM". Le premier consiste à gérer les intervenants du système, et le
deuxième consiste à consulter, recommander et évaluer des informations de l’annuaire.
Enfin, le dernier chapitre de notre rapport a porté sur la phase de clôture.
Finalement, notre plateforme ne s’arrête pas à ce niveau. En effet, plusieurs fonctionnalités

peuvent être ajoutées notamment des fonctionnalités de comparaison, et aider les établisse-
ments eux-mêmes à mieux comprendre leur propre performance et leur positionnement sur le
marché de l’enseignement supérieur.
130
Références bibliographiques
[1] : https://cck.rnu.tn/about (consulté le 30/04/2023).
[2] : http://www.pentalog.fr/notre-demarche/methode-agile-scrum.htm/ (consulté le 30/04/2023).
[3] : http ://www.nutcache.com/fr/blog/sprint-agile/ (consulté le 30/04/2023).
[4] : https://blog.myagilepartner.fr/index.php/2018/08/17/ceremonies-sprint-scrum/ (consulté

le 30/04/2023).
[5] : https ://www.memoireonline.com/ (consulté le 30/04/2023).
[6] : https://fr.m.wikipedia.org/wiki/Fichier:UMLl ogo.svg (consulté le 30/04/2023).
[7] :https ://www.eyrolles.com/Chapitres/9782212136418/Chap-1/Roques.pdf (consulté le

30/04/2023).
[8] : https://laurent-audibert.developpez.com/Cours-UML/?page=mise-en-oeuvre-uml / (consulté

le 30/04/2023).
[9] : https://fr.wikipedia.org/wiki/Spring( f ramework) / (consulté le 30/04/2023).
[10] : https://code.visualstudio.com/docs/ (consulté le 15/04/2023).
[11] : https://taigaio.github.io/taiga-doc/dist/ (consulté le 01/04/2023).
[12] : https ://www.tice-education.fr/tous-les-articles-er-ressources/articles-internet/819-draw-

io-un-outil-pour-dessiner-des-diagrammes-en-ligne/ (consulté le 01/04/2023)..
[13] : https://fr.wikipedia.org/wiki/Lucidchart (consulté le 01/04/2023).
[14] : https://fr.wikipedia.org/wiki/LaTeX (consulté le 01/04/2023).
[15] : https ://www.blogdumoderateur.com/tools/balsamiq/ (consulté le 01/04/2023).
[16] : https://fr.wikipedia.org/wiki/XAMPP (consulté le 01/04/2023).
[17] : https://fr.wikipedia.org/wiki/PhpMyAdmin (consulté le 01/04/2023).
[18] : https://angular.io/docs/ (consulté le 01/04/2023).
131
[19] : https ://www.ibm.com/fr-fr/topics/java-spring-boot/ (consulté le 01/04/2023).
[20] : https ://www.supinfo.com/articles/single/8729-architecture-mvc-qu-est-ce-que-c-est /(consulté

le 01/05/2023).
[21] : https ://www.gantt.com/fr /(consulté le 14/05/2023).
132

Rapport de Stage de Projet de Fin D Étude

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport de Stage de Projet de Fin D Étude

Transféré par

Droits d'auteur :

Formats disponibles

Code : 1452 Année Universitaire : 2022/2023.

École Supérieure d’Économie Numérique

Présenté en vue de l'obtention du diplôme de

Conception, développement et mise en ligne

Nous tenons à remercier particulièrement M. JAMEL ALOUI pour l’expérience enri-

Table des figures

Liste des tableaux

3 Gestion des intervenants 26

4 « Sprint 2 : Consultation, réclamation et évaluation des informations de

5 Phase de clôture 121

Conclusion générale 130

1.1 Logo de CCK [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Diagramme de contexte statique . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Diagramme de cas d’utilisation du premier sprint . . . . . . . . . . . . . . . 28

4.1 Diagramme de cas d’utilisation de sprint 2 . . . . . . . . . . . . . . . . . . . 95

5.1 logo de Spring Tool Suit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

1.1 Étude comparative entre Méthodes classiques et Méthode agiles . . . . . . . 9

2.1 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1 Backlog de sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1 Backlog de sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

1.2 Cadre du projet

La figure 1.1, nous trouvons le logo de l’entreprise CCK.

Figure 1.1 – Logo de CCK [1]

Le Centre de Calcul ElKhawarezmi offre un ensemble de services tels que :

• Gestion du réseau national universitaire.

• Gestion et motoring de la sécurité du réseau RNU.

• Hébergement des applications nationales et sites web des EER.

• Formation-Production Numérique et veille technologique.

L’organigramme de CCK représente les différents départements qui la composent.

Figure 1.2 – Organigramme de CCK

1.4 Description du projet :

1.5 Étude de l’existant :

Figure 1.3 – Site de l’annuaire universitaire

Il a pour missions de consulter le site, chercher des établissements.

En intégrant l’ensemble de ces fonctionnalités, l’annuaire universitaire peut

1.6 Méthodologie de travail

1.6.1 Choix de la méthodologie

1.6.2 Méthodes classiques vs Méthode agiles

Méthodes Classiques Méthode Agiles

Etape claire et définie Des livraisons petites et fréquentes

Vaste Documentation Se concentrer sur le code

Table 1.1 – Étude comparative entre Méthodes classiques et Méthode agiles

1.6.3 Les 4 valeurs d’agiles

Figure 1.4 – Les valeurs d’agile

Les 12 principes du manifeste agile :

Afin de bien gérer notre projet et de réaliser un produit de bonne qualité

1.6.5 Présentation de la méthodologie SCRUM

Principes essentiels de la méthode

La collaboration : cette méthode se base sur la collaboration avec le client.

L’acceptation du chagement : nous ne suivons pas un plan fixe nous réagissons à

La méthodologie SCRUM [3] fait intervenir 3 rôles principaux qui sont :

— Le « Product Owner » est le responsable de l’équipe projet client. Il va définir et

— Le « Scrum Master » veille à ce que chacun puisse travailler au maximum de

— Intervenant observe et donne des conseils à l’équipe.

La figure 1.6 présente les rôles dans SCRUM.

Figure 1.6 – Les rôles dans SCRUM [3]

1.6.6 Les artefacts de la méthode Scrum

Les artefacts de la méthode Scrum sont trois :

• «Product Backlog» :Contient toutes les exigences fonctionnelles de notre application,

• «Sprint Reviw» : C’est une réunion pour la présentation et la démonstration du

• «Sprint Rétrospective» :Fait référence à un bilan des tâches complétées et non

Figure 1.7 – Les cérémonies de la méthode Scrum [4]

Afin de faciliter la transmission d’informations et améliorer la compréhension du projet,