République Algérienne Démocratique et Populaire

Ministère de l'Enseignement Supérieur et de la Recherche Scientique

Mémoire de n de cycle
En vue de l'obtention du diplôme de Licence en Informatique

Conception et réalisation d'une application

web/mobile pour la gestion d'un complexe sportif

Année Universitaire : 2023/2024

Acknowledgements
First and foremost, we thank Almighty God for granting us the health, energy, and perseverance
required to bring this project to fruition.
We wish to express our deepest gratitude and immense appreciation to our supervisor, Dr. Bra-
him Benabderrahmane, for his invaluable guidance and unwavering patience. We thank him for
being an inspiring role model throughout this research journey ; his insightful directions were truly a
beacon of light on our path to knowledge.
Heartfelt thanks go to our families, who have been an unconditional source of strength and support
at every moment. To our parents, who believed in us even during times of self-doubt : the fruit of
your sacrices has nally ripened today.
We also thank our teammates and classmates for the immense collective eort and dedication
put into this project. This success would not have been possible without our mutual support and the
encouragement of everyone who stood by our side, even with a single kind word.
Finally, a special thanks to ourselves, as a team, for our resilience, the long nights of hard work,
and the unwavering belief in our vision. Today, we turn the page on fatigue to open the book of our
greatest dreams.

1
Table des matières

Acknowledgements 1
Introduction Générale 9
1 Capture des besoins fonctionnels et analyse (Phase d'Initialisation) 11
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Phase de spécication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.1 Identication des Acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.2 Identication des Cas d'Utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.3 Diagramme des Cas d'Utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Spécication détaillée des cas d'utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.1 Acteur : Gérant (Manager) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.2 Acteur : Responsable de Club (Club Leader) . . . . . . . . . . . . . . . . . . . 42
1.3.3 Acteur : Athlète (Athlete) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
1.3.4 Acteur : Utilisateur Public (Public User) . . . . . . . . . . . . . . . . . . . . . . 76
1.4 Conception des Interfaces Homme-Machine (IHM) . . . . . . . . . . . . . . . . . . . . 83
1.4.1 Interface d'Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
1.4.2 Interface de Réservation d'Infrastructure . . . . . . . . . . . . . . . . . . . . . . 83
1.4.3 Interface de Gestion des Groupes . . . . . . . . . . . . . . . . . . . . . . . . . . 83
1.4.4 Interface de Décision sur les Réservations . . . . . . . . . . . . . . . . . . . . . 83
1.4.5 Interface de Demande d'Adhésion . . . . . . . . . . . . . . . . . . . . . . . . . . 86
1.4.6 Interface de Gestion des Infrastructures . . . . . . . . . . . . . . . . . . . . . . 86
1.4.7 Interface de Gestion des Demandes d'Athlètes . . . . . . . . . . . . . . . . . . . 86
1.4.8 Interface de Gestion des Responsables de Clubs . . . . . . . . . . . . . . . . . . 87
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

2 Conception (Phase d'Élaboration) 89

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
2.2 Analyse (Modèle MVC / BCE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
2.2.1 Diagrammes de Classes Participantes . . . . . . . . . . . . . . . . . . . . . . . . 89
2.3 Conception Détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
2.3.1 Diagrammes de Séquence Détaillés . . . . . . . . . . . . . . . . . . . . . . . . . 96
2.3.2 Diagramme de Classes Global (Conception) . . . . . . . . . . . . . . . . . . . . 117
2.4 Modèle Relationnel (Base de données) . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
2.4.1 Règles de passage du modèle objet au modèle relationnel . . . . . . . . . . . . . 119
2.4.2 Le Modèle Logique de Données (MLD / ERD) . . . . . . . . . . . . . . . . . . 119
2.4.3 Dictionnaire des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

3 Réalisation / Implémentation (Phase de Construction) 123

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3.2 Architecture du Système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3.2.1 Description des trois couches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3.2.2 Flux de travail et Communication (Workow) . . . . . . . . . . . . . . . . . . . 124

2
 3.3 Environnement Matériel et Logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
3.3.1 Environnement Matériel (Hardware) . . . . . . . . . . . . . . . . . . . . . . . . 124
3.3.2 Environnement Logiciel et Système . . . . . . . . . . . . . . . . . . . . . . . . . 125
3.3.3 Stack Technique (Technologies de développement) . . . . . . . . . . . . . . . . 125
3.3.4 Outils d'aide au développement . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
3.4 Réalisation des Interfaces (Résultat Final) . . . . . . . . . . . . . . . . . . . . . . . . . 126
3.4.1 Interfaces de l'Utilisateur Public (Visiteur) . . . . . . . . . . . . . . . . . . . . 126
3.4.2 Interfaces de l'Athlète . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
3.4.3 Interfaces du Responsable de Club (Club Leader) . . . . . . . . . . . . . . . . . 131
3.4.4 Interfaces du Gérant (Manager) . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Conclusion Générale 142

3
Table des gures
1.1 Diagramme des cas d'utilisation global du système SportSync . . . . . . . . . . . . . . 13
1.2 Diagramme de Séquence Système : Mettre à jour une infrastructure . . . . . . . . . . . 15
1.3 DSS : Consulter l'annuaire des gérants . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4 DSS : Modier un groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.5 DSS : Eectuer une réservation (Gérant) . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.6 DSS : Créer un gérant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.7 DSS : Gérer les infrastructures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.8 DSS : Modier les informations d'un gérant . . . . . . . . . . . . . . . . . . . . . . . . 24
1.9 DSS : Gérer les responsables de clubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.10 DSS : Gérer les gérants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.11 DSS : Ajouter un responsable de club . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.12 DSS : Supprimer un responsable de club . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.13 DSS : Gérer les clubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.14 DSS : Ajouter un club . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.15 DSS : Supprimer un gérant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.16 DSS : Supprimer une infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1.17 DSS : Aecter un responsable de club . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.18 DSS : Supprimer un responsable de club . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.19 DSS : Ajouter un groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
1.20 DSS : Sélectionner une date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
1.21 DSS : Vérier la disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
1.22 DSS : Supprimer un groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
1.23 DSS : Modier la date de réservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
1.24 DSS : Demander une réservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
1.25 DSS : Modier l'infrastructure de réservation . . . . . . . . . . . . . . . . . . . . . . . 52
1.26 DSS : Modier un groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
1.27 DSS : Consulter les groupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
1.28 DSS : Examiner les demandes d'adhésion . . . . . . . . . . . . . . . . . . . . . . . . . . 56
1.29 DSS : Gérer les groupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
1.30 DSS : Demander la modication d'une réservation . . . . . . . . . . . . . . . . . . . . 59
1.31 DSS : Gérer les demandes des athlètes . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
1.32 DSS : Prendre une décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
1.33 DSS : Consulter les groupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
1.34 DSS : Se déconnecter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
1.35 DSS : Demander à rejoindre un groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
1.36 DSS : Consulter les groupes rejoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
1.37 DSS : Consulter les détails d'un groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
1.38 DSS : Consulter les notications de groupe . . . . . . . . . . . . . . . . . . . . . . . . . 69
1.39 DSS : Valider les identiants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
1.40 DSS : Parcourir les groupes (Athlète) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
1.41 DSS : Notication du responsable de club . . . . . . . . . . . . . . . . . . . . . . . . . 74
1.42 DSS : S'authentier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
1.43 DSS : Naviguer sur le site (Public User) . . . . . . . . . . . . . . . . . . . . . . . . . . 77
1.44 DSS : Consulter les ores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4
1.45 DSS : Laisser un avis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
1.46 DSS : Consulter les infrastructures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
1.47 Maquette de l'interface : Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 84
1.48 Maquette de l'interface : Eectuer une réservation . . . . . . . . . . . . . . . . . . . . 84
1.49 Maquette de l'interface : Gérer les groupes . . . . . . . . . . . . . . . . . . . . . . . . . 85
1.50 Maquette de l'interface : Décision sur une réservation . . . . . . . . . . . . . . . . . . . 85
1.51 Maquette de l'interface : Demander à rejoindre un groupe . . . . . . . . . . . . . . . . 86
1.52 Maquette de l'interface : Gérer les infrastructures . . . . . . . . . . . . . . . . . . . . . 87
1.53 Maquette de l'interface : Gérer les demandes des athlètes . . . . . . . . . . . . . . . . . 87
1.54 Maquette de l'interface : Gérer les responsables de clubs . . . . . . . . . . . . . . . . . 87
2.1 Diagramme des classes participantes : Authentication . . . . . . . . . . . . . . . . . . 90
2.2 Diagramme des classes participantes : Eectuer une réservation . . . . . . . . . . . . . 91
2.3 Diagramme des classes participantes : Gérer les groupes . . . . . . . . . . . . . . . . . 92
2.4 Diagramme des classes participantes : Décision sur une réservation . . . . . . . . . . . 93
2.5 Diagramme des classes participantes : Rejoindre un groupe . . . . . . . . . . . . . . . . 93
2.6 Diagramme des classes participantes : Gérer les infrastructures . . . . . . . . . . . . . 94
2.7 Diagramme des classes participantes : Gérer les demandes d'athlètes . . . . . . . . . . 95
2.8 Diagramme de Séquence Détaillé : Mettre à jour une infrastructure . . . . . . . . . . . 96
2.9 Diagramme de Séquence Détaillé : Modier un groupe . . . . . . . . . . . . . . . . . . 97
2.10 Diagramme de Séquence Détaillé : Eectuer une réservation (Gérant) . . . . . . . . . . 97
2.11 Diagramme de Séquence Détaillé : Créer un gérant . . . . . . . . . . . . . . . . . . . . 98
2.12 Diagramme de Séquence Détaillé : Gérer les infrastructures . . . . . . . . . . . . . . . 98
2.13 Diagramme de Séquence Détaillé : Gérer les responsables de clubs . . . . . . . . . . . . 99
2.14 Diagramme de Séquence Détaillé : Gérer les gérants . . . . . . . . . . . . . . . . . . . . 100
2.15 Diagramme de Séquence Détaillé : Ajouter un responsable de club . . . . . . . . . . . . 101
2.16 Diagramme de Séquence Détaillé : Supprimer un responsable de club . . . . . . . . . . 101
2.17 Diagramme de Séquence Détaillé : Gérer les clubs . . . . . . . . . . . . . . . . . . . . . 102
2.18 Diagramme de Séquence Détaillé : Ajouter un club . . . . . . . . . . . . . . . . . . . . 103
2.19 Diagramme de Séquence Détaillé : Supprimer un gérant . . . . . . . . . . . . . . . . . 104
2.20 Diagramme de Séquence Détaillé : Supprimer une infrastructure . . . . . . . . . . . . . 105
2.21 Diagramme de Séquence Détaillé : Aecter un responsable de club . . . . . . . . . . . 105
2.22 Diagramme de Séquence Détaillé : Ajouter un groupe . . . . . . . . . . . . . . . . . . . 106
2.23 Diagramme de Séquence Détaillé : Sélectionner une date . . . . . . . . . . . . . . . . . 106
2.24 Diagramme de Séquence Détaillé : Vérier la disponibilité . . . . . . . . . . . . . . . . 107
2.25 Diagramme de Séquence Détaillé : Supprimer un groupe . . . . . . . . . . . . . . . . . 107
2.26 Diagramme de Séquence Détaillé : Modier la date de réservation . . . . . . . . . . . . 108
2.27 Diagramme de Séquence Détaillé : Demander une réservation . . . . . . . . . . . . . . 108
2.28 Diagramme de Séquence Détaillé : Consulter les groupes . . . . . . . . . . . . . . . . . 109
2.29 Diagramme de Séquence Détaillé : Examiner les demandes d'adhésion . . . . . . . . . 109
2.30 Diagramme de Séquence Détaillé : Gérer les clubs . . . . . . . . . . . . . . . . . . . . . 110
2.31 Diagramme de Séquence Détaillé : Demander la modication d'une réservation . . . . 111
2.32 Diagramme de Séquence Détaillé : Gérer les demandes des athlètes . . . . . . . . . . . 111
2.33 Diagramme de Séquence Détaillé : Prendre une décision . . . . . . . . . . . . . . . . . 112
2.34 Diagramme de Séquence Détaillé : Se déconnecter . . . . . . . . . . . . . . . . . . . . . 112
2.35 Diagramme de Séquence Détaillé : Consulter les groupes rejoints . . . . . . . . . . . . 113
2.36 Diagramme de Séquence Détaillé : Consulter les détails d'un groupe . . . . . . . . . . . 113
2.37 Diagramme de Séquence Détaillé : Consulter les notications de groupe . . . . . . . . . 114
2.38 Diagramme de Séquence Détaillé : Valider les identiants . . . . . . . . . . . . . . . . . 114
2.39 Diagramme de Séquence Détaillé : Parcourir les groupes (Athlète) . . . . . . . . . . . . 115
2.40 Diagramme de Séquence Détaillé : Notication du responsable de club . . . . . . . . . 115
2.41 Diagramme de Séquence Détaillé : S'authentier . . . . . . . . . . . . . . . . . . . . . 116
2.42 Diagramme de Séquence Détaillé : Naviguer sur le site (Public User) . . . . . . . . . . 116
2.43 Diagramme de Séquence Détaillé : Consulter les ores . . . . . . . . . . . . . . . . . . 117

5
2.44 Diagramme de Séquence Détaillé : Laisser un avis . . . . . . . . . . . . . . . . . . . . . 117
2.45 Diagramme de classes global du système . . . . . . . . . . . . . . . . . . . . . . . . . . 118
3.1 Schéma détaillé de l'architecture 3-Tiers et du ux de données . . . . . . . . . . . . . . 124
3.2 Page d'accueil principale (User Dashboard) . . . . . . . . . . . . . . . . . . . . . . . . 126
3.3 Aperçu secondaire de la page d'accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
3.4 Consultation des infrastructures disponibles . . . . . . . . . . . . . . . . . . . . . . . . 127
3.5 Formulaire pour laisser un avis (Feedback) . . . . . . . . . . . . . . . . . . . . . . . . . 127
3.6 Page d'inscription (Sign-in / Register) pour les athlètes . . . . . . . . . . . . . . . . . 128
3.7 Page de connexion (Login) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
3.8 Tableau de bord de l'athlète . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
3.9 Consultation de la liste des groupes (Check Groups) . . . . . . . . . . . . . . . . . . . 129
3.10 Détails d'un groupe avant d'envoyer une demande . . . . . . . . . . . . . . . . . . . . . 129
3.11 Conrmation de l'envoi de la demande d'adhésion . . . . . . . . . . . . . . . . . . . . . 130
3.12 Consultation des notications de groupe . . . . . . . . . . . . . . . . . . . . . . . . . . 130
3.13 Tableau de bord du Leader de Club (Vue principale) . . . . . . . . . . . . . . . . . . . 131
3.14 Tableau de bord du Leader de Club (Vue détaillée) . . . . . . . . . . . . . . . . . . . . 131
3.15 Gestion des groupes existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
3.16 Formulaire de création d'un nouveau groupe . . . . . . . . . . . . . . . . . . . . . . . . 132
3.17 Gestion des demandes d'adhésion des athlètes . . . . . . . . . . . . . . . . . . . . . . . 133
3.18 Notications de nouvelles demandes d'athlètes . . . . . . . . . . . . . . . . . . . . . . . 134
3.19 Sélection d'une date et d'une infrastructure . . . . . . . . . . . . . . . . . . . . . . . . 135
3.20 Formulaire de demande de réservation d'infrastructure . . . . . . . . . . . . . . . . . . 135
3.21 Interface de gestion des infrastructures sportives . . . . . . . . . . . . . . . . . . . . . . 136
3.22 Ajout d'une nouvelle infrastructure au complexe . . . . . . . . . . . . . . . . . . . . . . 137
3.23 Liste et gestion des clubs inscrits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
3.24 Création d'un nouveau prol de club . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
3.25 Gestion des comptes des responsables de clubs . . . . . . . . . . . . . . . . . . . . . . . 139
3.26 Ajout d'un nouveau responsable de club . . . . . . . . . . . . . . . . . . . . . . . . . . 139
3.27 Gestion des administrateurs (Managers) du système . . . . . . . . . . . . . . . . . . . 140
3.28 Création d'un nouveau compte Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 140
3.29 Prise de décision (Validation/Refus) sur les requêtes système . . . . . . . . . . . . . . 141

6
Liste des tableaux
1.1 Description textuelle : Mettre à jour une infrastructure . . . . . . . . . . . . . . . . . . 14
1.2 Description textuelle : Consultation de l'annuaire des gérants . . . . . . . . . . . . . . 16
1.3 Description textuelle : Mise à jour d'un groupe . . . . . . . . . . . . . . . . . . . . . . 18
1.4 Description textuelle : Eectuer une réservation (Gérant) . . . . . . . . . . . . . . . . . 19
1.5 Description textuelle : Création d'un nouveau gérant . . . . . . . . . . . . . . . . . . . 20
1.6 Description textuelle : Gestion globale des infrastructures . . . . . . . . . . . . . . . . 22
1.7 Description textuelle : Mise à jour des informations d'un gérant . . . . . . . . . . . . . 23
1.8 Description textuelle : Gestion des responsables de clubs . . . . . . . . . . . . . . . . . 25
1.9 Description textuelle : Gestion des comptes gérants . . . . . . . . . . . . . . . . . . . . 26
1.10 Description textuelle : Ajout d'un responsable de club . . . . . . . . . . . . . . . . . . 28
1.11 Description textuelle : Suppression d'un responsable de club . . . . . . . . . . . . . . . 30
1.12 Description textuelle : Gestion des clubs . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.13 Description textuelle : Ajout d'un club . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.14 Description textuelle : Suppression d'un gérant . . . . . . . . . . . . . . . . . . . . . . 37
1.15 Description textuelle : Suppression d'une infrastructure . . . . . . . . . . . . . . . . . . 37
1.16 Description textuelle : Aectation d'un responsable de club . . . . . . . . . . . . . . . 39
1.17 Description textuelle : Suppression d'un responsable de club (Asma) . . . . . . . . . . 40
1.18 Description textuelle : Ajout d'un nouveau groupe . . . . . . . . . . . . . . . . . . . . 42
1.19 Description textuelle : Sélection et vérication d'une date . . . . . . . . . . . . . . . . 43
1.20 Description textuelle : Vérication des disponibilités . . . . . . . . . . . . . . . . . . . 45
1.21 Description textuelle : Suppression d'un groupe . . . . . . . . . . . . . . . . . . . . . . 46
1.22 Description textuelle : Modication d'une date de réservation . . . . . . . . . . . . . . 48
1.23 Description textuelle : Demande de réservation . . . . . . . . . . . . . . . . . . . . . . 49
1.24 Description textuelle : Demande de modication d'infrastructure . . . . . . . . . . . . 51
1.25 Description textuelle : Mise à jour d'un groupe . . . . . . . . . . . . . . . . . . . . . . 53
1.26 Description textuelle : Consultation des groupes . . . . . . . . . . . . . . . . . . . . . . 54
1.27 Description textuelle : Examen des demandes d'adhésion . . . . . . . . . . . . . . . . . 55
1.28 Description textuelle : Gestion des groupes (Roumeissa) . . . . . . . . . . . . . . . . . 57
1.29 Description textuelle : Modication d'une réservation (Bessam) . . . . . . . . . . . . . 58
1.30 Description textuelle : Gestion des demandes des athlètes . . . . . . . . . . . . . . . . 60
1.31 Description textuelle : Prise de décision sur les adhésions . . . . . . . . . . . . . . . . . 61
1.32 Description textuelle : Consultation des groupes par l'athlète . . . . . . . . . . . . . . 63
1.33 Description textuelle : Déconnexion de l'utilisateur . . . . . . . . . . . . . . . . . . . . 64
1.34 Description textuelle : Demander à rejoindre un groupe . . . . . . . . . . . . . . . . . . 66
1.35 Description textuelle : Consultation des adhésions par l'athlète . . . . . . . . . . . . . 67
1.36 Description textuelle : Consultation des détails d'un groupe . . . . . . . . . . . . . . . 68
1.37 Description textuelle : Consultation des notications . . . . . . . . . . . . . . . . . . . 70
1.38 Description textuelle : Validation des identiants . . . . . . . . . . . . . . . . . . . . . 71
1.39 Description textuelle : Parcourir les groupes (Roumeissa) . . . . . . . . . . . . . . . . . 73
1.40 Description textuelle : Notication automatique du responsable . . . . . . . . . . . . . 74
1.41 Description textuelle : Authentication de l'utilisateur . . . . . . . . . . . . . . . . . . 75
1.42 Description textuelle : Navigation publique . . . . . . . . . . . . . . . . . . . . . . . . 77
1.43 Description textuelle : Consultation des ores par le public . . . . . . . . . . . . . . . . 78
1.44 Description textuelle : Envoi d'un feedback . . . . . . . . . . . . . . . . . . . . . . . . 80

7
1.45 Description textuelle : Consulter les infrastructures . . . . . . . . . . . . . . . . . . . . 82
2.1 Dictionnaire des données : Table User . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
2.2 Dictionnaire des données : Table Facility . . . . . . . . . . . . . . . . . . . . . . . . . 120
2.3 Dictionnaire des données : Table Club . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
2.4 Dictionnaire des données : Table Club_Group . . . . . . . . . . . . . . . . . . . . . . 121
2.5 Dictionnaire des données : Table Reservation . . . . . . . . . . . . . . . . . . . . . . 121
2.6 Dictionnaire des données : Table Notication . . . . . . . . . . . . . . . . . . . . . . 121

8
Introduction Générale

Contexte Général
De nos jours, le sport occupe une place primordiale dans la société moderne, non seulement en
tant que levier de santé publique, mais également comme vecteur fondamental de cohésion sociale et
d'éducation. Pour répondre à cet engouement croissant, les infrastructures se sont multipliées, donnant
naissance à de vastes complexes sportifs capables d'accueillir simultanément plusieurs disciplines, de
nombreux clubs, et des centaines d'athlètes au quotidien.
Cependant, l'évolution de la taille et de la fréquentation de ces structures a rendu leur gestion
quotidienne particulièrement complexe. L'administration d'un complexe sportif moderne implique une
coordination rigoureuse des ressources matérielles (terrains, salles, équipements) et humaines (gérants,
entraîneurs, sportifs). Dans ce contexte d'expansion, la transition numérique ne relève plus du simple
confort, mais s'impose comme une nécessité absolue. L'intégration des Technologies de l'Information
et de la Communication (TIC) dans le domaine sportif devient le seul moyen ecace de moderniser
les processus organisationnels, de garantir une utilisation optimale des infrastructures, et d'assurer une
circulation uide de l'information entre toutes les parties prenantes.

Problématique
Malgré les avancées technologiques, de nombreux complexes sportifs continuent de gérer leurs infra-
structures de manière traditionnelle (registres papier, appels téléphoniques). Cette méthode archaïque
engendre plusieurs dicultés majeures, dont la principale est la rupture de la chaîne d'information
entre les diérents acteurs. Plus précisément, nous avons identié les problèmes suivants :
 Décit de communication et d'accès à l'information : Les athlètes et les responsables de
clubs n'ont aucune visibilité en temps réel sur la disponibilité des infrastructures ou sur l'état de
leurs demandes.
 Risque élevé d'incohérence des données : La gestion manuelle entraîne fréquemment des
conits de réservation (chevauchements) et des doubles saisies, créant des tensions entre les clubs.
 Lourdeur administrative : Le gérant est submergé par le traitement manuel des requêtes, ce
qui ralentit la prise de décision et la transmission de l'information aux parties concernées.
Face à ces contraintes, la question qui se pose est la suivante : Comment concevoir un système informa-
tisé capable de centraliser l'information pour garantir une communication uide et transparente entre
tous les acteurs d'un complexe sportif ?

Objectifs du projet
Pour répondre à cette problématique centrée sur l'accès à l'information, notre projet vise à concevoir
et développer une plateforme web et mobile nommée SportSync. L'objectif global est de combler le
fossé de communication entre le gérant, les responsables de clubs et les athlètes. Nos sous-objectifs se
déclinent comme suit :
 Centraliser l'information : Créer une base de données unique et able regroupant l'ensemble
des infrastructures, des clubs, et des plannings, éliminant ainsi les données fragmentées.

9
  Garantir la transparence par des espaces dédiés : Orir des tableaux de bord spéci-
ques (rôles Gérant, Responsable, Athlète) permettant à chacun de consulter les informations
qui le concernent (disponibilités, statuts des requêtes, plannings) sans nécessiter d'intervention
humaine.
 Automatiser la gestion des réservations : Remplacer les appels et les papiers par un pro-
cessus numérique de demande et de validation, où l'information circule instantanément de la
soumission par le responsable jusqu'à la décision du gérant.

Méthodologie de travail
Pour mener à bien ce projet de manière rigoureuse, nous avons adopté une méthodologie de dévelop-
pement basée sur le Processus Unié (UP) allégé, particulièrement adaptée aux applications Web.
La modélisation du système a été réalisée à l'aide du langage standard UML (Unied Modeling Lan-
guage). Sur le plan architectural, nous avons opté pour une architecture 3-Tiers (Client-Serveur) en
nous appuyant sur les technologies modernes telles que ReactJS pour l'interface utilisateur, ExpressJS
([Link]) pour la logique métier, et PostgreSQL pour la persistance des données.

Organisation du mémoire
An de présenter notre travail de manière claire et structurée, ce manuscrit est divisé en trois
chapitres principaux :
 Le premier chapitre est consacré à la capture des besoins fonctionnels et à l'analyse (Phase
d'initialisation). Il dénit les acteurs, les cas d'utilisation et présente les premières maquettes des
interfaces.
 Le deuxième chapitre aborde la phase de conception (Phase d'élaboration). Il détaille l'ar-
chitecture du système à travers les diagrammes de classes participantes (Pattern BCE), les dia-
grammes de séquence et le modèle relationnel de la base de données.
 Le troisième chapitre présente la phase de réalisation. Il expose l'environnement de dévelop-
pement, les outils utilisés, ainsi que les interfaces nales de notre application.
Enn, une conclusion générale viendra clôturer ce mémoire en dressant le bilan du travail accompli
et en proposant des perspectives d'évolution.

10
Chapitre 1

Capture des besoins fonctionnels et

analyse (Phase d'Initialisation)

1.1 Introduction
Ce premier chapitre est consacré à la phase d'initialisation, étape fondamentale du Processus Unié
(UP). L'objectif principal de cette phase est de dénir clairement les frontières de notre système
SportSync et de capturer de manière exhaustive les besoins fonctionnels des futurs utilisateurs. Pour
ce faire, nous allons d'abord identier les diérents acteurs qui interagiront avec l'application, puis
nous recenserons les cas d'utilisation associés à chaque prol. Cela nous permettra d'établir un modèle
fonctionnel solide qui servira de socle pour les phases de conception et de réalisation.

1.2 Phase de spécication

La phase de spécication consiste à modéliser les exigences du système en se basant sur la nota-
tion standard UML. Elle s'articule autour de deux axes majeurs : la dénition des entités externes
interagissant avec le système (les acteurs) et la description des fonctionnalités que le système doit leur
fournir (les cas d'utilisation).

1.2.1 Identication des Acteurs

En UML, un acteur représente l'abstraction d'un rôle joué par une entité externe (utilisateur
humain, dispositif matériel ou système tiers) qui interagit directement avec le système étudié. Dans le
cadre de notre projet de centralisation des informations pour le complexe sportif, nous avons identié
quatre acteurs principaux :
 Le Gérant (Manager) : C'est l'administrateur principal de la plateforme. Il possède le plus haut
niveau de privilèges. Son rôle est de superviser l'ensemble du complexe : il gère les infrastructures,
les diérents clubs partenaires, les responsables de ces clubs, et détient le pouvoir décisionnel nal
(approbation ou refus) sur les demandes de réservation.
 Le Responsable de Club (Club Leader) : Il représente un club sportif utilisateur du com-
plexe. Il utilise le système pour organiser ses équipes (création et gestion de groupes d'athlètes)
et agit comme l'intermédiaire principal pour soumettre des demandes de réservation d'infrastruc-
tures en fonction des plannings de son club.
 L'Athlète (Athlete) : C'est le membre nal d'un club sportif. Il interagit avec le système pour
accéder à l'information de manière transparente. Son rôle lui permet de consulter ses plannings,
de demander à rejoindre des groupes, et d'être tenu informé de l'état des activités de son club.
 L'Utilisateur Public (Public User) : Il s'agit de tout visiteur non authentié qui accède à la
plateforme. Il navigue sur la partie "vitrine" du système pour découvrir le complexe, consulter
les infrastructures disponibles, explorer les ores, et éventuellement laisser des avis.

11
1.2.2 Identication des Cas d'Utilisation
Un cas d'utilisation (Use Case) décrit une unité cohérente de fonctionnalités fournies par le système.
Il représente une interaction spécique et un objectif précis qu'un acteur souhaite atteindre. Sur la base
des besoins recueillis, voici les principales actions du système, réparties selon nos acteurs :
1. Cas d'utilisation de l'Utilisateur Public :
 Parcourir le site web (Browse Website).
 Consulter les infrastructures (Check Facilities) et les ores (Check Oers).
 Laisser un avis (Leave Feedback).
2. Cas d'utilisation de l'Athlète :
 S'authentier sur le système (Login / Validate Credentials) et se déconnecter (Logout).
 Parcourir les groupes existants (Browse Groups) et soumettre une demande pour en rejoindre un
(Request to join a group).
 Consulter les groupes rejoints (View Joined Groups) et leurs détails.
 Contacter ou notier son responsable de club.
3. Cas d'utilisation du Responsable de Club :
 Gérer ses groupes (Ajouter, Mettre à jour, Supprimer).
 Gérer les requêtes d'adhésion provenant des athlètes.
 Formuler une demande de réservation (Sélectionner une infrastructure, vérier la disponibilité,
sélectionner une date).
 Demander une modication sur une réservation existante (Changer de date, changer d'infrastruc-
ture).
4. Cas d'utilisation du Gérant :
 Gérer les infrastructures du complexe (Ajouter, Mettre à jour, Supprimer).
 Gérer les autres gérants (Ajouter, Mettre à jour, Supprimer).
 Gérer les clubs et assigner/supprimer des responsables de clubs.
 Prendre une décision sur les requêtes de réservation soumises par les responsables (Approuver ou
Refuser).

1.2.3 Diagramme des Cas d'Utilisation

Le diagramme suivant illustre de manière globale les interactions entre nos quatre acteurs principaux
(Gérant, Responsable de Club, Athlète, Utilisateur Public) et le système SportSync.

12
Figure 1.1  Diagramme des cas d'utilisation global du système SportSync

13
1.3 Spécication détaillée des cas d'utilisation
Dans cette section, nous détaillons les scénarios des cas d'utilisation du système. An d'organiser
le travail de conception, chaque cas d'utilisation a été attribué à un membre de l'équipe.

1.3.1 Acteur : Gérant (Manager)

Mettre à jour une infrastructure (Update facilities)
Réalisé par : AMOURA BARAA
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Mettre à jour une infrastructure (Update facility)
Acteur Principal Gérant (Manager)
Préconditions
 Le Gérant est authentié.
 L'infrastructure cible existe dans la base de données.
Scénario Nominal
1. Le gérant parcourt la liste des infrastructures.
2. Le gérant sélectionne l'infrastructure à modier.
3. Le gérant clique sur  Modier .
4. Le système ache le formulaire pré-rempli.
5. Le gérant modie les informations et valide.
6. Le système enregistre les changements et conrme.
Scénarios Alternatifs Erreur 4.1 : Si des champs obligatoires sont laissés vides, le système
bloque la validation et ache un message d'erreur.
Postconditions Les données de l'infrastructure sont mises à jour dans la base.
Table 1.1  Description textuelle : Mettre à jour une infrastructure

B. Diagramme de Séquence Système (DSS)

La gure suivante illustre les échanges de messages temporels entre le Gérant et le Système global
(considéré comme une boîte noire) lors de la mise à jour d'une infrastructure.

14
Figure 1.2  Diagramme de Séquence Système : Mettre à jour une infrastructure

15
Consulter l'annuaire des gérants (View Managers Directory)
Réalisé par : AYACHI
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Consulter l'annuaire des gérants
Acteur Principal Gérant (Manager)
Objectif Permettre au gérant de visualiser la liste complète de ses pairs (autres
gérants) inscrits dans le système.
Préconditions Le gérant doit être authentié et posséder les droits d'accès nécessaires.
Scénario Nominal
1. Le gérant demande à consulter l'annuaire des gérants.
2. Le système vérie les permissions de l'acteur.
3. Le système récupère la liste des gérants depuis la base de données.
4. Le système ache la liste des gérants à l'écran.
Scénarios Alternatifs 2-a. Permissions invalides : Le système ache un message  Accès
refusé  et interrompt l'action.
3-a. Erreur interne : Si les données ne peuvent pas être récupérées, le
système ache  Impossible de récupérer les données pour le moment .
Postconditions La liste des gérants est achée avec succès.

Table 1.2  Description textuelle : Consultation de l'annuaire des gérants

B. Diagramme de Séquence Système (DSS)

16
 Figure 1.3  DSS : Consulter l'annuaire des gérants

Modier un groupe (Update Group)

Réalisé par : AYECHE MOHAMMED
A. Description textuelle du scénario
B. Diagramme de Séquence Système (DSS)

Figure 1.4  DSS : Modier un groupe

17
 Propriété Description
Cas d'utilisation Modier un groupe (Update Group)
Acteur Principal Responsable de club (Club Leader)
Objectif Permettre au responsable de modier ou de mettre à jour les informations
d'un groupe existant.
Préconditions
 Le responsable de club est authentié.
 Le groupe ciblé existe déjà dans le système.
Scénario Nominal
1. Le responsable de club modie les données du groupe et soumet la
mise à jour.
2. Le système vérie la validité des nouvelles données.
3. Le système conrme que les données sont valides.
4. Le système ache un message de succès ( Success ).
Scénarios Alternatifs Données invalides : Si les nouvelles données ne sont pas conformes
(not OK), le système ache un message d'erreur ( Error ) et aucune
modication n'est enregistrée en base de données.
Postconditions Les informations du groupe sont mises à jour avec succès dans la base de
données.
Table 1.3  Description textuelle : Mise à jour d'un groupe

Prendre une décision sur une réservation (Reservation Request Decision)

Réalisé par : BAOUT REBIHA
A. Description textuelle du scénario
B. Diagramme de Séquence Système (DSS)

18
Propriété Description
Cas d'utilisation Eectuer une réservation (Reservation Request)
Acteur Principal Gérant (Manager)
Objectif Permettre au gérant de réserver des infrastructures pour une date ou un
créneau horaire spécique.
Préconditions
 Le gérant doit être connecté au système de gestion.
 Les infrastructures doivent être congurées dans le système.
Scénario Nominal
1. Le gérant clique sur le bouton de réservation.
2. Le gérant sélectionne l'infrastructure à réserver.
3. Le gérant saisit les détails de la réservation (date, heure de début,
heure de n, nom du groupe).
4. Le système vérie la disponibilité de l'infrastructure.
5. Le système ache une boîte de conrmation.
6. Le gérant clique sur le bouton  OK .
7. Un message apparaît à l'écran :  Réservation créée avec succès .
Scénarios Alternatifs
 1. Indisponibilité : Si le système détecte que l'infrastructure est
déjà réservée sur ce créneau, un message d'erreur d'indisponibilité
apparaît.
 2. Correction : Le gérant choisit un autre horaire ou une autre
infrastructure.
Postconditions La réservation est eectuée et enregistrée avec succès dans la base de
données.
Table 1.4  Description textuelle : Eectuer une réservation (Gérant)

Figure 1.5  DSS : Eectuer une réservation (Gérant)

19
Créer un gérant (Create manager)
Réalisé par : BAOUTA ANIS
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Créer un gérant (Create Manager)
Acteur Principal Gérant (Manager)
Objectif Créer et ajouter un nouveau compte de gestion (Gérant) dans le système.
Préconditions
 Le gérant est connecté au système.
 Le gérant possède les privilèges nécessaires pour la création de comptes
administratifs.
Scénario Nominal
1. Le gérant ouvre la page de création de gérant.
2. Le système ache un formulaire de saisie d'informations.
3. Le gérant saisit les données du nouveau gérant (nom, e-mail, mot de
passe).
4. Le gérant clique sur le bouton de soumission (Submit).
5. Le système valide les données saisies.
6. Le système crée le nouveau compte gérant dans la base de données.
7. Le système ache un message de conrmation.
Scénarios Alternatifs 5.1. Données invalides ou doublon : Si les données sont incorrectes
(ex : format d'email invalide) ou si le gérant existe déjà, le système ache
un message d'erreur et bloque la création.
Postconditions Un nouveau compte gérant est créé avec succès dans le système.
Table 1.5  Description textuelle : Création d'un nouveau gérant

B. Diagramme de Séquence Système (DSS)

20
Figure 1.6  DSS : Créer un gérant

21
Gérer les infrastructures (Manage Facilities)
Réalisé par : BENCHEKHCHOUKH MOHYIDDINE
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Gérer les infrastructures (Manage Facilities)
Acteur Principal Gérant (Manager)
Objectif Permettre au gérant d'eectuer les opérations CRUD (Création, Lecture,
Mise à jour, Suppression) sur les infrastructures du complexe.
Préconditions
 Le système est en mode  Administration .
 Le gérant est authentié avec les privilèges requis.
Scénario Nominal
1. Le gérant accède au tableau de bord des infrastructures (Facility Da-
shboard).
2. Le gérant envoie une requête pour recevoir la liste des infrastructures.
3. Le système récupère et retourne la liste complète des infrastructures
depuis la base de données.
4. Le système ache la liste à l'écran, permettant au gérant de choisir
une action spécique (Ajouter, Modier ou Supprimer).
Scénarios Alternatifs Liste vide : Si aucune infrastructure n'est enregistrée, le système ache
un message indiquant que la liste est vide et propose d'en créer une nou-
velle.
Postconditions Les infrastructures sont listées et prêtes pour une gestion détaillée ; toute
modication est persistée en base de données.
Table 1.6  Description textuelle : Gestion globale des infrastructures

B. Diagramme de Séquence Système (DSS)

Figure 1.7  DSS : Gérer les infrastructures

Modier les informations d'un gérant (Update manager)

Réalisé par : Berghouth Amel

22
 A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Modier les informations d'un gérant (Update manager)
Acteur Principal Gérant (Manager)
Objectif Permettre à un gérant de mettre à jour les informations de son compte
ou d'un autre compte de gestion.
Préconditions
 Le gérant doit être authentié sur le système.
 Le compte à modier doit exister dans la base de données.
Scénario Nominal
1. Le gérant s'identie sur le système (Login).
2. Le gérant accède au prol ou à la liste des gérants.
3. Le gérant saisit les nouvelles données de mise à jour (data).
4. Le gérant soumet la modication au système (UpdateManagerInfo).
5. Le système valide les données et met à jour les informations en base
de données.
6. Le système renvoie un message de conrmation (UpdateConrmation).
Scénarios Alternatifs Erreur de validation : Si les données envoyées sont incomplètes ou
invalides, le système rejette la modication et ache un message d'erreur.
Postconditions Les informations du gérant sont mises à jour avec succès dans le système.
Table 1.7  Description textuelle : Mise à jour des informations d'un gérant

B. Diagramme de Séquence Système (DSS)

23
 Figure 1.8  DSS : Modier les informations d'un gérant

Gérer les responsables de clubs (Manage Club Leaders)

Réalisé par : BOUKHETINI MOUSTAFA
A. Description textuelle du scénario
B. Diagramme de Séquence Système (DSS)

24
Propriété Description
Cas d'utilisation Gérer les responsables de clubs (Manage Club Leaders)
Acteur Principal Gérant (Manager)
Objectif Permettre au gérant d'ajouter, de consulter, de modier ou de supprimer
les comptes des responsables de clubs.
Préconditions Le gérant doit être authentié et avoir accès au panneau d'administration.
Scénario Nominal
1. Le gérant accède à la section  Gestion des Leaders .
2. Le système ache la liste de tous les responsables de clubs enregistrés.
3. Le gérant choisit d'ajouter un nouveau leader ou d'en modier un
existant.
4. Le gérant saisit les informations requises (Nom, Email, Club associé).
5. Le système valide les données et met à jour la base de données.
6. Le système conrme la réussite de l'opération.
Scénarios Alternatifs Données invalides : Si un champ obligatoire est manquant ou si l'email
existe déjà, le système ache un message d'erreur et demande de corriger
les informations.
Postconditions Les informations du responsable de club sont mises à jour et ses droits
d'accès sont congurés.
Table 1.8  Description textuelle : Gestion des responsables de clubs

Figure 1.9  DSS : Gérer les responsables de clubs

25
Gérer les gérants (Manage managers)
Réalisé par : BOULEMZAOUD IYAD
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Gérer les gérants (Manage managers)
Acteur Principal Administrateur (Admin/Manager)
Objectif Permettre à l'administrateur de visualiser, créer, mettre à jour et suppri-
mer des comptes de gérants.
Préconditions
 L'administrateur est connecté au système.
 L'administrateur possède les privilèges de gestion administrative.
Scénario Nominal
1. L'administrateur demande la liste de tous les gérants actuels.
2. Le système récupère et ache les informations des gérants.
3. L'administrateur sélectionne une action : Créer, Modier ou Suppri-
mer.
ˆ Créer : Saisie des détails du nouveau gérant.
ˆ Modier : Modication des informations existantes.
ˆ Supprimer : Sélection du compte à supprimer.
4. Le système valide les données saisies ou conrme l'action demandée.
5. Le système met à jour la base de données et ache un message de
succès.
Scénarios Alternatifs 4.1. Erreur de saisie ou de manipulation : Si l'administrateur saisit
des informations erronées ou tente de supprimer un compte par erreur, le
système permet l'annulation ou ache une erreur de validation.
Postconditions Les données relatives aux gérants sont mises à jour avec succès dans la
base de données.
Table 1.9  Description textuelle : Gestion des comptes gérants

B. Diagramme de Séquence Système (DSS)

26
Figure 1.10  DSS : Gérer les gérants

27
Ajouter un responsable de club (Add Club leader)
Réalisé par : BOUMECHAL SALIHA
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Ajouter un responsable de club (Add Club leader)
Acteur Principal Gérant (Manager)
Objectif Permettre au gérant de créer et d'ajouter un nouveau prol de responsable
de club dans le système.
Préconditions
 Le gérant doit être connecté au système.
 Le nouveau responsable ne doit pas déjà posséder un compte existant.
Scénario Nominal
1. Le gérant sélectionne la section  Responsables de Club  depuis le
tableau de bord.
2. Le système ache les données du tableau de bord correspondantes.
3. Le gérant clique sur le bouton  Ajouter un nouveau responsable .
4. Le gérant saisit les informations personnelles du responsable et soumet
le formulaire.
5. Le système valide les données et crée les liens nécessaires.
6. Le système ache un message de succès.
Scénarios Alternatifs Compte en double : Le système ache un message d'erreur si l'adresse
e-mail ou l'identiant est déjà enregistré dans la base de données.
Postconditions
 Le prol du nouveau responsable est sauvegardé dans la base de don-
nées.
 Le nouveau responsable peut désormais se connecter au système.
 Le système enregistre l'historique de l'ajout eectué par le gérant.
Table 1.10  Description textuelle : Ajout d'un responsable de club

B. Diagramme de Séquence Système (DSS)

28
Figure 1.11  DSS : Ajouter un responsable de club

29
Supprimer un responsable de club (Remove Club Leader)
Réalisé par : FERROUH DARINE
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Supprimer un responsable de club (Remove Club Leader)
Acteur Principal Gérant (Manager)
Objectif Permettre au gérant de retirer un responsable de club du système.
Préconditions
 Le gérant est connecté au système.
 Le responsable de club à supprimer existe dans la base de données.
Scénario Nominal
1. Le gérant sélectionne le responsable de club dans la liste.
2. Le gérant choisit l'option de suppression (Remove).
3. Le système traite la demande et supprime le compte du responsable.
4. Le système ache un message de conrmation de la suppression.
Scénarios Alternatifs Données invalides : Si le système rencontre une erreur lors de l'identi-
cation du compte ou si les données sont corrompues, un message d'erreur
est aché.
Postconditions Le responsable est dénitivement retiré du club et ses accès au système
sont révoqués.
Table 1.11  Description textuelle : Suppression d'un responsable de club

B. Diagramme de Séquence Système (DSS)

30
Figure 1.12  DSS : Supprimer un responsable de club

31
Gérer les clubs (Manage Clubs)
Réalisé par : KHENIOU AMANI
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Gérer les clubs (Manage Clubs)
Acteur Principal Gérant (Manager)
Acteur Secondaire Système (Base de données)
Objectif Permettre au gérant de gérer intégralement les clubs (Ajout, Modication,
Suppression) dans le système.
Préconditions Le gérant est authentié sur le système.
Scénario Nominal
1. Le gérant accède à la page de gestion des clubs.
2. Le système récupère et ache la liste de tous les clubs existants.
3. Le gérant choisit une action : Ajouter, Modier ou Supprimer.
4. Le système traite la requête et met à jour la base de données.
5. Le système conrme l'opération par un message de succès.
Scénarios Alternatifs
 4.1. Nom déjà existant : Le système ache  Le club existe déjà
.
 4.2. Suppression d'un club avec groupes actifs : Le système
avertit le gérant de la suppression en cascade des groupes associés.
 4.3. Erreur de base de données : Le système ache un message
d'erreur et annule l'opération.
Postconditions
 Si Ajout : Un nouveau club est créé et sauvegardé.
 Si Modication : Les informations du club sont mises à jour.
 Si Suppression : Le club est retiré de la base (avec suppression en
cascade des groupes).
Table 1.12  Description textuelle : Gestion des clubs

B. Diagramme de Séquence Système (DSS)

32
Figure 1.13  DSS : Gérer les clubs

33
Ajouter un club (Add Club)
Réalisé par : SALHI ROUMEISSA
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Ajouter un club (Add Club)
Acteur Principal Gérant (Manager)
Objectif Permettre au gérant de créer un nouveau club de sport et d'y aecter un
responsable (Club Leader).
Préconditions
 Le gérant est authentié avec un jeton JWT valide.
 Le rôle de l'utilisateur est strictement  Manager .
 Au moins un utilisateur ayant le rôle  Leader  existe déjà dans le
système.
Scénario Nominal
1. Le gérant navigue vers la section  Club Management .
2. Le système envoie une requête GET /api/club pour récupérer les clubs
existants.
3. Le système ache la liste des clubs avec leurs détails.
4. Le gérant clique sur  Add Club  ; le système ache le formulaire de
création.
5. Le gérant saisit les informations (nom du club, type d'activité, lieu)
et sélectionne un responsable (Leader).
6. Le système envoie une requête POST /api/club avec les données du
formulaire.
7. Le middleware roleCheck vérie les privilèges du gérant.
8. Le système insère le nouveau club en base de données, lié au respon-
sable choisi.
9. Le système retourne un code 201 Created avec les détails du club
créé.
Scénarios Alternatifs Erreur d'authentication : Si le jeton JWT est expiré ou si le rôle
n'est pas  Manager , le système rejette la requête avec une erreur 401
ou 403.
Postconditions
 Le club est enregistré et lié au responsable de club (Leader).
 Le responsable de club peut désormais créer des groupes et gérer des
athlètes au sein de ce club.
Table 1.13  Description textuelle : Ajout d'un club

B. Diagramme de Séquence Système (DSS)

34
 Figure 1.14  DSS : Ajouter un club

Supprimer un gérant (Delete manager)

Réalisé par : SELLAHI BESSAM
A. Description textuelle du scénario
B. Diagramme de Séquence Système (DSS)

35
Figure 1.15  DSS : Supprimer un gérant

36
 Propriété Description
Cas d'utilisation Supprimer un gérant (Delete manager)
Acteur Principal Gérant responsable (Admin)
Acteur Secondaire Système (Base de données)
Objectif Supprimer dénitivement un compte de gérant du système.
Préconditions
 Le gérant eectuant l'action doit avoir les droits de suppression.
 Le compte gérant cible doit exister dans le système.
Scénario Nominal
1. Le gérant responsable ouvre l'application et accède à la liste des gé-
rants.
2. Le gérant parcourt la liste et choisit le prol à supprimer.
3. Le gérant clique sur le bouton  Supprimer gérant .
4. Le gérant conrme son choix (par saisie du nom ou sélection) et valide.
5. Le système traite la demande et supprime les données du gérant.
6. Le système ache un message de conrmation.
Scénarios Alternatifs Annulation : Le gérant peut annuler l'opération avant la validation
nale, le système revient alors à l'achage de la liste sans modication.
Postconditions Le compte du gérant n'existe plus dans la base de données.
Table 1.14  Description textuelle : Suppression d'un gérant

Supprimer une infrastructure (Delete facility)

Réalisé par : ZEDDAME IMANE
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Supprimer une infrastructure (Delete Facility)
Acteur Principal Gérant (Manager)
Objectif Retirer une infrastructure de la liste des ressources disponibles pour les
utilisateurs du système.
Préconditions L'infrastructure doit exister dans la base de données.
Scénario Nominal
1. Le système ache la liste des infrastructures disponibles.
2. Le gérant sélectionne l'infrastructure ciblée.
3. Le système ache l'interface des détails de l'infrastructure.
4. Le gérant clique sur le bouton de suppression (Delete).
5. Le système demande une conrmation de la suppression.
6. Le gérant conrme la suppression.
7. Le système ache la liste mise à jour sans l'infrastructure supprimée
(Message :  Deletion succeeded ).
Scénarios Alternatifs 7.2. Annulation : Si le gérant annule la conrmation, le système ache
à nouveau l'interface des détails (Message :  Deletion canceled ).
Postconditions L'infrastructure n'est plus disponible pour les utilisateurs du système.
Table 1.15  Description textuelle : Suppression d'une infrastructure

B. Diagramme de Séquence Système (DSS)

37
Figure 1.16  DSS : Supprimer une infrastructure

38
Aecter un responsable de club (Assign Club Leader)
Réalisé par : ZEKRI MOFIDA
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Aecter un responsable à un club/infrastructure (Assign Club Leader)
Acteur Principal Gérant du système (Manager)
Objectif Nommer ociellement un responsable de club pour une infrastructure ou
un club spécique dans le système.
Préconditions
 Le gérant doit être authentié avec des privilèges administratifs.
 Le futur responsable doit déjà être enregistré comme utilisateur dans
le système.
Scénario Nominal
1. Le gérant sélectionne l'infrastructure ou le club cible dans la liste.
2. Le gérant recherche et sélectionne l'utilisateur à nommer comme res-
ponsable.
3. Le système vérie l'éligibilité du rôle de l'utilisateur.
4. Le système met à jour la base de données pour associer l'identiant
de l'utilisateur (User_ID) à celui du club/infrastructure (Club_ID).
5. Le système conrme l'aectation et met à jour les permissions d'accès
de l'utilisateur vers le rôle  Club Leader .
6. Le système informe l'utilisateur nommé via une notication interne à
l'application.
Scénarios Alternatifs
 Utilisateur déjà aecté : Si l'utilisateur est déjà responsable d'une
autre entité, le système demande de réaecter ou de supprimer l'ancien
rôle d'abord.
 Sélection invalide : Si l'entité est inactive ou supprimée, le système
ache une erreur et annule l'opération.
 Échec d'autorisation : Si l'utilisateur n'est pas Admin, le système
refuse l'accès au panneau de gestion.
Postconditions Les données de l'entité sont mises à jour pour reéter la nouvelle direc-
tion, et l'utilisateur gagne l'accès au module de gestion des demandes
d'athlètes.
Table 1.16  Description textuelle : Aectation d'un responsable de club

B. Diagramme de Séquence Système (DSS)

39
 Figure 1.17  DSS : Aecter un responsable de club

Supprimer un responsable de club (Remove Club Leader)

Réalisé par : Asma Bouhechicha
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Supprimer un responsable de club (Remove Club Leader)
Acteur Principal Gérant (Manager)
Objectif Permettre au gérant de retirer un responsable de club de la liste du per-
sonnel de gestion.
Préconditions
 Le gérant est authentié (via le module de Login).
 Le responsable de club cible est présent dans la liste du personnel.
Scénario Nominal
1. Le gérant sélectionne un responsable et clique sur  Supprimer  (Re-
move).
2. Le système ache une boîte de dialogue de conrmation.
3. Le gérant conrme la suppression.
4. Le système traite la demande et ache un message de succès.
5. Le système redirige l'utilisateur vers la liste de gestion du personnel.
Scénarios Alternatifs Annulation de la suppression : Si le gérant choisit d'annuler l'opé-
ration dans la boîte de dialogue, le système interrompt la procédure et
retourne simplement à la liste de gestion sans eectuer de modication.
Postconditions Les droits du responsable de club sont révoqués et son nom est retiré de
la liste active du personnel.
Table 1.17  Description textuelle : Suppression d'un responsable de club (Asma)

B. Diagramme de Séquence Système (DSS)

40
Figure 1.18  DSS : Supprimer un responsable de club

41
1.3.2 Acteur : Responsable de Club (Club Leader)
Ajouter un groupe (Add Group)
Réalisé par : AYECHE MOHAMMED
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Ajouter un groupe (Add Group)
Acteur Principal Responsable de club (Club Leader)
Objectif Créer et ajouter un nouveau groupe au sein du système.
Préconditions Le responsable de club doit être connecté au système.
Scénario Nominal
1. Le responsable de club saisit les détails du groupe et clique sur le
bouton  Ajouter  (Add).
2. Le système vérie les données saisies.
3. Le système conrme que les données sont correctes.
4. Le système ache un message de succès ( Success ).
Scénarios Alternatifs Données incorrectes : Si les données saisies sont invalides (not OK),
le système ache un message d'erreur ( Error ) et l'enregistrement est
annulé.
Postconditions Un nouveau groupe est enregistré avec succès dans la base de données.
Table 1.18  Description textuelle : Ajout d'un nouveau groupe

B. Diagramme de Séquence Système (DSS)

Figure 1.19  DSS : Ajouter un groupe

42
Sélectionner une date (Select Date)
Réalisé par : BAOUTA ANIS
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Sélectionner une date (Select Date)
Acteur Principal Responsable de club (Club Leader)
Objectif Vérier la disponibilité d'une date spécique pour une réservation.
Description Ce cas d'utilisation permet au responsable de club de choisir une date sur
un calendrier an de voir si le créneau est libre.
Préconditions
 Le responsable de club est connecté au système.
 La page de réservation est ouverte.
Scénario Nominal
1. Le responsable de club accède à la page de réservation.
2. Le système ache le calendrier interactif.
3. Le responsable sélectionne une date précise.
4. Le système vérie la disponibilité de la date sélectionnée en base de
données.
5. Le système indique si la date est disponible pour une réservation.
Scénarios Alternatifs 4.1. Date indisponible : Si la date est déjà réservée ou bloquée, le
système ache un message indiquant que la réservation n'est pas possible
pour ce créneau.
Postconditions Le statut de disponibilité de la date sélectionnée est aché à l'écran.
Table 1.19  Description textuelle : Sélection et vérication d'une date

B. Diagramme de Séquence Système (DSS)

43
 Figure 1.20  DSS : Sélectionner une date

Vérier la disponibilité (Check Availability)

Réalisé par : Berghouth Amel
A. Description textuelle du scénario
B. Diagramme de Séquence Système (DSS)

44
Propriété Description
Cas d'utilisation Vérier la disponibilité (Check Availability)
Acteur Principal Responsable de club (Club Leader)
Objectif Permettre au responsable de consulter les créneaux libres pour une infra-
structure à une date donnée.
Préconditions
 Le responsable de club est authentié sur le système.
 L'infrastructure (facility) est répertoriée dans le système.
Scénario Nominal
1. Le responsable de club eectue son authentication (Login).
2. Le responsable sélectionne une date et une infrastructure spécique.
3. Le responsable demande la vérication des disponibilités
(CheckAvailability).
4. Le système interroge la base de données pour les paramètres fournis.
5. Le système ache la liste des créneaux horaires disponibles
(DisplayAvailableSlots).
Scénarios Alternatifs Aucun créneau libre : Si l'infrastructure est entièrement réservée pour
la date choisie, le système ache un message indiquant qu'aucun créneau
n'est disponible.
Postconditions Les créneaux disponibles sont présentés visuellement au responsable pour
une éventuelle réservation future.
Table 1.20  Description textuelle : Vérication des disponibilités

Figure 1.21  DSS : Vérier la disponibilité

45
Supprimer un groupe (Delete Group)
Réalisé par : BOUHACHICHA ASMA
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Supprimer un groupe (Delete Group)
Acteur Principal Responsable de club (Leader)
Objectif Permettre au responsable de supprimer dénitivement un groupe qu'il
gère.
Préconditions
 Le responsable est connecté au système.
 Le groupe ciblé appartient au club géré par le responsable.
Scénario Nominal
1. Le responsable sélectionne le groupe à supprimer dans sa liste de ges-
tion.
2. Le responsable clique sur l'option de suppression (Delete).
3. Le système ache une demande de conrmation.
4. Le système procède à la suppression du groupe de la base de données.
5. Le système conrme la réussite de l'opération par un message.
Scénarios Alternatifs Annulation : Le responsable choisit d'annuler l'opération lors de l'étape
de conrmation ; le système interrompt la procédure et le groupe n'est pas
supprimé.
Postconditions Le groupe est dénitivement retiré du système et de la base de données.
Table 1.21  Description textuelle : Suppression d'un groupe

B. Diagramme de Séquence Système (DSS)

46
 Figure 1.22  DSS : Supprimer un groupe

Modier la date de réservation (Change date)

Réalisé par : BOUKHETINI MOUSTAFA
A. Description textuelle du scénario
B. Diagramme de Séquence Système (DSS)

47
Propriété Description
Cas d'utilisation Modier la date (Change date)
Acteur Principal Responsable de club (Club leader)
Objectif Permettre au responsable de modier la date d'une réservation existante
après vérication de la disponibilité.
Préconditions
 Le responsable est connecté au système.
 Une réservation préalable existe déjà dans la base de données.
Scénario Nominal
1. Le responsable ouvre la page de réservation.
2. Le système ache le calendrier.
3. Le responsable sélectionne la réservation à modier et choisit une nou-
velle date.
4. Le système eectue une vérication interne de la disponibilité (Check
availability).
5. [Disponibilité = Vrai] : Le système met à jour la réservation et
ache un message de conrmation (Reservation update).
Scénarios Alternatifs 4.a. Disponibilité = Faux : Si la nouvelle date choisie est déjà occu-
pée, le système informe le responsable que la modication est impossible
(Reservation not possible).
Postconditions La date de la réservation est mise à jour dans la base de données ou
conservée en l'état en cas d'indisponibilité.
Table 1.22  Description textuelle : Modication d'une date de réservation

Figure 1.23  DSS : Modier la date de réservation

48
Demander une réservation (Request a reservation)
Réalisé par : BOULEMZAOUD IYAD
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Demander une réservation (Request a Reservation)
Acteur Principal Responsable de club (Club Leader)
Objectif Permettre à un responsable de club de réserver une infrastructure sportive
spécique pour l'un de ses groupes à une date et une heure précises.
Préconditions Le responsable doit avoir au moins un groupe enregistré sous sa gestion.
Scénario Nominal
1. Le responsable sélectionne l'option  Demander une réservation .
2. Le système ache la liste des groupes gérés par ce responsable.
3. Le responsable sélectionne un groupe spécique pour la session.
4. Le système ache les infrastructures disponibles ainsi que les créneaux
horaires.
5. Le responsable choisit une infrastructure, une date et une heure.
6. Le responsable conrme la demande de réservation.
7. Le système enregistre la demande et ache un message de conrma-
tion.
Scénarios Alternatifs Aucun groupe trouvé : Si le responsable n'a pas de groupe créé, le
système l'invite à créer un groupe avant de procéder à la réservation.
Postconditions Un nouvel enregistrement de réservation est créé dans la base de données
avec un statut  En attente  ou  Conrmé .
Table 1.23  Description textuelle : Demande de réservation

B. Diagramme de Séquence Système (DSS)

49
Figure 1.24  DSS : Demander une réservation

50
Modier l'infrastructure de réservation (Change facility)
Réalisé par : BOUMECHAL SALIHA
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Modier l'infrastructure (Change facility)
Acteur Principal Responsable de club (Club leader)
Objectif Permettre au responsable de soumettre une demande de modication
d'infrastructure pour une réservation existante.
Préconditions
 Le responsable de club est connecté au système.
 Une réservation active doit déjà exister.
Scénario Nominal
1. L'utilisateur clique sur la liste des réservations.
2. Le système ache la liste des réservations existantes.
3. L'utilisateur sélectionne une réservation et choisit de la modier.
4. L'utilisateur soumet la demande de changement d'infrastructure.
5. Le système conrme la réception de la demande et la met en attente
de validation.
Scénarios Alternatifs Infrastructure déjà réservée : Si le nouvel emplacement choisi est
déjà occupé pour ce créneau, le système ache une erreur et demande de
choisir une autre option.
Postconditions La réservation originale reste inchangée tant que le gérant (Manager) n'a
pas approuvé la demande de modication.
Table 1.24  Description textuelle : Demande de modication d'infrastructure

B. Diagramme de Séquence Système (DSS)

51
Figure 1.25  DSS : Modier l'infrastructure de réservation

52
Modier un groupe (Update Group)
Réalisé par : FERROUH DARINE
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Modier un groupe (Update Group)
Acteur Principal Responsable de club (Leader)
Objectif Permettre au responsable de mettre à jour les informations relatives à un
groupe spécique.
Préconditions
 Le responsable est connecté au système.
 Le groupe à modier existe déjà dans la base de données.
Scénario Nominal
1. Le responsable sélectionne le groupe qu'il souhaite modier.
2. Le responsable modie les informations nécessaires dans le formulaire.
3. Le responsable enregistre les modications.
4. Le système valide les données et met à jour les informations du groupe
dans la base de données.
5. Le système ache un message conrmant la mise à jour.
Scénarios Alternatifs Données invalides : Si les informations saisies ne respectent pas le
format requis (ex : nom vide, capacité incohérente), le système ache un
message d'erreur et conserve les anciennes données.
Postconditions Les informations du groupe sont mises à jour avec succès.
Table 1.25  Description textuelle : Mise à jour d'un groupe

B. Diagramme de Séquence Système (DSS)

Figure 1.26  DSS : Modier un groupe

Consulter les groupes (Get Groups)

Réalisé par : GHICHI IBRAHIM
A. Description textuelle du scénario
B. Diagramme de Séquence Système (DSS)

53
Propriété Description
Cas d'utilisation Consulter les groupes (Get Groups)
Acteur Principal Responsable de club (Club Leader)
Objectif Permettre au responsable de club de récupérer et de visualiser la liste
complète de tous les groupes (équipes) appartenant à son club spécique.
Préconditions
 Le responsable de club est authentié.
 Le responsable possède les permissions administratives pour son club.
 Le club existe dans la base de données du système.
Scénario Nominal
1. Le responsable sélectionne l'option  Consulter les groupes  ou 
Gérer les équipes  depuis le tableau de bord.
2. Le système vérie la session et l'identité du responsable.
3. Le système interroge la base de données pour tous les groupes liés à
l'identiant du club (Club_ID) du responsable.
4. Le système récupère les enregistrements (Nom, ID, Coach, Nombre de
membres).
5. Le système ache la liste sous forme de tableau organisé.
Scénarios Alternatifs Aucun groupe existant : Si aucun groupe n'est trouvé pour ce club,
le système ache le message  Aucun groupe disponible  et propose un
bouton pour  Créer un nouveau groupe .
Postconditions Le système ache avec succès la liste des groupes associée au club, in-
cluant les métadonnées de chaque groupe.
Table 1.26  Description textuelle : Consultation des groupes

Figure 1.27  DSS : Consulter les groupes

54
Examiner les demandes d'adhésion (Review Request)
Réalisé par : KHENIOU AMANI
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Examiner les demandes (Review Request)
Acteur Principal Responsable de club (Leader)
Acteurs Secondaires Système (Base de données), Athlète
Objectif Permettre au responsable d'examiner les demandes d'adhésion soumises
par les athlètes et de prendre une décision (Accepter ou Refuser).
Préconditions
 Le responsable est authentié dans le système.
 Au moins un athlète a soumis une demande pour rejoindre le groupe.
Scénario Nominal
1. Le responsable accède à la liste des demandes en attente.
2. Le système récupère toutes les demandes (statut = en attente) depuis
la base de données.
3. Le système ache la liste des demandes au responsable.
4. Le responsable sélectionne une demande et consulte les détails de l'ath-
lète.
5. Le responsable prend une décision : Accepter ou Refuser.
6. Le système met à jour le statut de la demande dans la base de données.
7. Le système envoie une notication à l'athlète concerné.
Scénarios Alternatifs
 2.1. Aucune demande : Le système ache  Aucune demande pour
le moment .
 2.2. Erreur BDD : Le système ache un message d'erreur et annule
l'opération.
Postconditions
 Si acceptée : L'athlète est ajouté au groupe et reçoit une notication
de succès.
 Si refusée : La demande est rejetée et l'athlète reçoit une notication
de refus.
Table 1.27  Description textuelle : Examen des demandes d'adhésion

B. Diagramme de Séquence Système (DSS)

55
 Figure 1.28  DSS : Examiner les demandes d'adhésion

Gérer les groupes (Manage Groups)

Réalisé par : SALHI ROUMEISSA
A. Description textuelle du scénario
B. Diagramme de Séquence Système (DSS)

56
Propriété Description
Cas d'utilisation Gérer les groupes (Manage Groups)
Acteur Principal Responsable de club (Club Leader)
Objectif Permettre au responsable de créer et d'organiser les groupes sportifs au
sein de son club.
Préconditions Le responsable de club doit être authentié dans le système.
Scénario Nominal
1. Le responsable de club demande la création d'un nouveau groupe.
2. Le système ache le formulaire de création à l'écran.
3. Le responsable remplit les informations du formulaire et valide la saisie.
4. Le système traite les données et enregistre le nouveau groupe.
5. Le système ache un message de succès conrmant la création.
Scénarios Alternatifs 4.1. Champs manquants : Si le formulaire est incomplet ou contient
des erreurs, le système ache un message d'erreur spécique et invite
l'utilisateur à corriger sa saisie.
Postconditions Le groupe est ajouté à la liste des groupes gérés par le responsable et est
prêt à accueillir des athlètes.
Table 1.28  Description textuelle : Gestion des groupes (Roumeissa)

Figure 1.29  DSS : Gérer les groupes

57
Demander la modication d'une réservation (Request a change)
Réalisé par : SELLAHI BESSAM
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Demander la modication d'une réservation (Request a change)
Acteur Principal Responsable de club (Club leader)
Acteur Secondaire Système (Base de données)
Objectif Modier les détails d'une réservation existante (infrastructure, horaire ou
groupe).
Préconditions
 Le responsable de club est authentié.
 La réservation cible existe déjà dans le système.
Scénario Nominal
1. Le responsable ouvre l'application et parcourt ses réservations.
2. Le responsable sélectionne la réservation à modier.
3. Le responsable clique sur le bouton  Modier  (Edit).
4. Le responsable change les paramètres nécessaires (infrastructure,
heure, groupe).
5. Le responsable valide les modications.
6. Le système enregistre les changements et conrme la mise à jour.
Scénarios Alternatifs Délai dépassé : Si la date de la réservation est déjà passée, le système
bloque toute tentative de modication et ache un message d'erreur.
Postconditions La réservation est mise à jour avec les nouvelles informations en base de
données.
Table 1.29  Description textuelle : Modication d'une réservation (Bessam)

B. Diagramme de Séquence Système (DSS)

58
Figure 1.30  DSS : Demander la modication d'une réservation

59
Gérer les demandes des athlètes (Manage Athlete Requests)
Réalisé par : ZEKRI MOFIDA
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Gérer les demandes des athlètes (Manage Athlete Requests)
Acteur Principal Responsable de club (Club Leader)
Objectif Examiner, traiter et décider du sort des demandes d'adhésion soumises
par les athlètes (Approuver ou Rejeter).
Préconditions
 Le responsable de club doit être authentié.
 Il doit y avoir au moins une demande en attente dans le système.
Scénario Nominal
1. Le responsable navigue vers le tableau de bord de gestion des de-
mandes.
2. Le système ache la liste des demandes en attente provenant des ath-
lètes.
3. Le responsable sélectionne une demande spécique pour en examiner
les détails.
4. Le responsable choisit d'Approuver ou de Rejeter la demande.
5. Le système met à jour le statut de la demande en base de données (via
l'inclusion  Update Status ).
6. Le système envoie une notication à l'athlète concernant la décision
prise.
Scénarios Alternatifs
 Informations insusantes : Si la demande est incomplète, le res-
ponsable peut la marquer comme  En attente de clarication .
 Erreur de base de données : Si la connexion échoue lors de la mise
à jour, le système alerte le responsable et l'invite à réessayer.
Postconditions Le statut de la demande est mis à jour de façon permanente et le compte
de l'athlète est modié en conséquence (accès au club accordé ou non).
Table 1.30  Description textuelle : Gestion des demandes des athlètes

B. Diagramme de Séquence Système (DSS)

60
 Figure 1.31  DSS : Gérer les demandes des athlètes

Prendre une décision (Make a decision)

Réalisé par : ZERIZER ISRA
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Prendre une décision (Make a decision)
Acteur Principal Responsable de club (Club leader)
Acteur Secondaire Athlète
Objectif Permettre au responsable de consulter les demandes d'adhésion en attente
et de statuer sur chacune d'elles (accepter ou refuser).
Préconditions
 Le responsable est authentié.
 Au moins une demande d'adhésion est en attente pour son groupe.
Scénario Nominal
1. Le responsable demande à acher la liste des demandes d'adhésion.
2. Le système ache la liste des postulants en attente.
3. Le responsable sélectionne une demande et clique sur  Accepter .
4. Le système enregistre l'adhésion et ache un message de conrmation.
Scénarios Alternatifs Refus de la demande : À l'étape 3, le responsable peut choisir de
cliquer sur  Refuser . Après conrmation, le système rejette la demande
et l'athlète n'est pas ajouté au groupe.
Postconditions La demande est traitée : soit le postulant devient membre du groupe, soit
la demande est dénitivement rejetée.
Table 1.31  Description textuelle : Prise de décision sur les adhésions

B. Diagramme de Séquence Système (DSS)

61
 Figure 1.32  DSS : Prendre une décision

1.3.3 Acteur : Athlète (Athlete)

Consulter les groupes (Check Groups)
Réalisé par : AYECHE MOHAMMED
A. Description textuelle du scénario
B. Diagramme de Séquence Système (DSS)

62
Propriété Description
Cas d'utilisation Consulter les groupes (Check Groups)
Acteur Principal Athlète
Objectif Permettre à un athlète de visualiser la liste des groupes disponibles au
sein d'un club spécique.
Préconditions L'athlète doit être connecté à l'application.
Scénario Nominal
1. L'athlète demande à voir les groupes d'un club spécique.
2. Le système récupère et traite la liste des groupes correspondants en
base de données.
3. Le système trouve les groupes associés au club.
4. Le système ache la liste des groupes à l'athlète.
Scénarios Alternatifs Aucun groupe trouvé : Si aucun groupe n'est enregistré pour le club
sélectionné, le système ache le message  Aucun groupe disponible 
(No groups available).
Postconditions L'athlète visualise les groupes disponibles ou reçoit une notication d'ab-
sence de résultats.
Table 1.32  Description textuelle : Consultation des groupes par l'athlète

Figure 1.33  DSS : Consulter les groupes

63
Se déconnecter (Logout)
Réalisé par : BAOUT REBIHA
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Se déconnecter (Logout)
Acteur Principal Athlète
Objectif Permettre à l'utilisateur de quitter son prol et de fermer sa session sé-
curisée.
Préconditions L'acteur doit posséder un compte et être actuellement authentié dans le
système.
Scénario Nominal
1. L'acteur clique sur l'icône de son prol.
2. Le système ache un menu déroulant.
3. L'acteur clique sur l'option  Déconnexion  (Logout).
4. Une boîte de conrmation apparaît à l'écran.
5. Le système redirige vers la page d'accueil et l'acteur retrouve un statut
de visiteur public.
Scénarios Alternatifs Annulation : L'acteur clique sur le bouton  Annuler  dans la boîte
de conrmation ; le système interrompt la procédure et l'acteur reste
connecté à son espace privé.
Postconditions La session est détruite, l'acteur quitte son espace privé et ne peut plus
accéder aux fonctionnalités restreintes sans se reconnecter.
Table 1.33  Description textuelle : Déconnexion de l'utilisateur

B. Diagramme de Séquence Système (DSS)

64
Figure 1.34  DSS : Se déconnecter

65
Demander à rejoindre un groupe (Request to join a group)
Réalisé par : BENCHEKHCHOUKH MOHYIDDINE
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Demander à rejoindre un groupe
Acteur Principal Athlète
Objectif Permettre à un athlète de soumettre une demande d'adhésion pour inté-
grer un groupe sportif spécique.
Préconditions L'athlète doit être connecté à son compte.
Scénario Nominal
1. L'athlète parcourt la liste des clubs et des groupes disponibles.
2. Le système ache la liste complète des groupes.
3. L'athlète sélectionne un groupe spécique via son identiant (grp_id ).
4. L'athlète clique sur le bouton  Rejoindre .
5. Le système vérie que l'athlète n'a pas déjà un abonnement actif ou
une demande en cours pour ce groupe.
6. Le système ache un formulaire d'adhésion.
7. L'athlète saisit les informations requises (date de début, date de n)
et valide.
8. Le système enregistre la demande avec le statut  En attente  et
ache une conrmation.
Scénarios Alternatifs 5-a. Abonnement déjà existant : Si le système détecte que l'utilisateur
est déjà membre, il ache le message  Déjà existant  et interrompt la
procédure.
Postconditions Une nouvelle demande d'adhésion (JoinRequest ) est créée dans la base
de données.

Table 1.34  Description textuelle : Demander à rejoindre un groupe

B. Diagramme de Séquence Système (DSS)

Consulter les groupes rejoints (View Joined Groups)
Réalisé par : BOUHACHICHA ASMA
A. Description textuelle du scénario
B. Diagramme de Séquence Système (DSS)

66
 Figure 1.35  DSS : Demander à rejoindre un groupe

Propriété Description
Cas d'utilisation Consulter les groupes rejoints (View Joined Groups)
Acteur Principal Athlète
Objectif Permettre à l'athlète de visualiser la liste de tous les groupes auxquels il
est ociellement inscrit.
Préconditions L'athlète doit être connecté au système.
Scénario Nominal
1. L'athlète sélectionne l'option  Mes Groupes  ou  Consulter les
groupes rejoints .
2. Le système interroge la base de données pour récupérer les groupes
liés à l'identiant de l'athlète.
3. Le système ache la liste détaillée des groupes à l'écran.
Scénarios Alternatifs Aucun groupe rejoint : Si l'athlète n'appartient à aucun groupe, le
système ache un message indiquant :  Vous n'avez rejoint aucun groupe
pour le moment .
Postconditions Le système ache avec succès la liste des adhésions de l'athlète.
Table 1.35  Description textuelle : Consultation des adhésions par l'athlète

67
 Figure 1.36  DSS : Consulter les groupes rejoints

Consulter les détails d'un groupe (View Group details)

Réalisé par : FERROUH DARINE
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Consulter les détails d'un groupe (View Group details)
Acteur Principal Athlète
Objectif Permettre à l'athlète d'accéder aux informations détaillées d'un groupe
spécique.
Préconditions L'athlète doit être connecté au système.
Scénario Nominal
1. L'athlète sélectionne un groupe spécique dans la liste des groupes
disponibles.
2. Le système interroge la base de données pour récupérer l'intégralité
des informations du groupe.
3. Le système ache les détails (ex : description, coach assigné, eectif
actuel, planning).
Scénarios Alternatifs Groupe introuvable : Si les données du groupe ne peuvent pas être
chargées ou si le groupe a été supprimé entre-temps, le système ache
un message d'erreur.
Postconditions Les détails complets du groupe sont achés à l'écran pour l'athlète.
Table 1.36  Description textuelle : Consultation des détails d'un groupe

B. Diagramme de Séquence Système (DSS)

68
 Figure 1.37  DSS : Consulter les détails d'un groupe

Consulter les notications de groupe (View Group Notication)

Réalisé par : GHICHI IBRAHIM
A. Description textuelle du scénario
B. Diagramme de Séquence Système (DSS)

Figure 1.38  DSS : Consulter les notications de groupe

69
Propriété Description
Cas d'utilisation Consulter les notications (View Group Notication)
Acteur Principal Athlète
Description Permet à l'utilisateur d'accéder à une liste centralisée de notications
générées par les activités du groupe (messages du coach, changements de
planning, etc.).
Préconditions
 L'athlète est connecté à l'application.
 L'athlète est membre d'au moins un groupe.
 Une notication a été déclenchée par un coach ou par le système.
Scénario Nominal
1. L'athlète clique sur l'icône de notications (cloche) sur la barre de
navigation.
2. L'athlète ltre les notications par l'onglet  Groupes .
3. Le système récupère et ache les notications par ordre antéchrono-
logique.
4. L'athlète clique sur une notication spécique.
5. Le système marque la notication comme  Lue  et redirige l'utilisa-
teur vers le contenu concerné.
Scénarios Alternatifs
 Liste vide : Si aucune activité n'est enregistrée, le système ache :
 Aucune activité de groupe pour le moment .
 Contenu supprimé : Si le contenu lié à la notication a été sup-
primé, le système ache un message d'erreur.
Postconditions Le statut de la notication passe de  Non lue  à  Lue  dans la base
de données.
Table 1.37  Description textuelle : Consultation des notications

70
Valider les identiants (Validate Credentials)
Réalisé par : KHENIOU AMANI
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Valider les identiants (Validate Credentials)
Acteur Principal Athlète / Responsable / Manager
Acteur Secondaire Système (Base de données)
Objectif Vérier les informations de connexion (email et mot de passe) pour ac-
corder l'accès selon le rôle de l'utilisateur.
Préconditions L'utilisateur possède déjà un compte enregistré dans le système.
Scénario Nominal
1. L'utilisateur saisit son adresse email et son mot de passe.
2. Le système vérie l'existence de l'email dans la base de données.
3. Le système compare le mot de passe saisi avec le mot de passe haché
stocké.
4. Le système génère un jeton JWT contenant l'ID et le rôle de l'utili-
sateur.
5. Le système renvoie le jeton et redirige l'utilisateur vers son espace
dédié.
Scénarios Alternatifs
 Email inexistant : Le système ache  Utilisateur non trouvé .
 Mot de passe incorrect : Le système ache  Identiants invalides
.
 Retour à l'étape 1 du scénario principal dans les deux cas.
Postconditions L'utilisateur est authentié et redirigé vers son interface spécique (Ma-
nager, Leader ou Athlète).
Table 1.38  Description textuelle : Validation des identiants

B. Diagramme de Séquence Système (DSS)

71
Figure 1.39  DSS : Valider les identiants

72
Parcourir les groupes (Browse Groups)
Réalisé par : SALHI ROUMEISSA
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Parcourir les groupes (Browse Groups)
Acteur Principal Athlète
Objectif Permettre à un athlète de consulter la liste des groupes disponibles et
d'accéder aux détails de chacun.
Préconditions L'athlète doit être authentié dans le système.
Scénario Nominal
1. L'athlète demande la liste des groupes au système.
2. Le système récupère les données et ache la liste des groupes.
3. L'athlète sélectionne un groupe spécique dans la liste.
4. Le système ache les détails complets du groupe sélectionné.
Scénarios Alternatifs Aucun groupe : Si aucun groupe n'est disponible, le système ache
une liste vide ou un message d'information.
Postconditions L'athlète a pris connaissance des détails du groupe pour une éventuelle
adhésion.
Table 1.39  Description textuelle : Parcourir les groupes (Roumeissa)

B. Diagramme de Séquence Système (DSS)

Figure 1.40  DSS : Parcourir les groupes (Athlète)

Notier le responsable (Notify Club Leader)

Réalisé par : SELLAHI BESSAM
A. Description textuelle du scénario
B. Diagramme de Séquence Système (DSS)

73
Propriété Description
Cas d'utilisation Notier le responsable (Notify Club Leader)
Acteur Principal Système
Acteur Secondaire Responsable de Club (Club Leader)
Objectif Alerter automatiquement le responsable de club lorsqu'une nouvelle ac-
tion (demande d'adhésion, message, etc.) nécessite son attention.
Préconditions Un événement déclencheur (ex : un athlète postule à un groupe) a eu lieu
dans le système.
Scénario Nominal
1. Le système détecte un changement d'état ou une nouvelle requête.
2. Le système génère un message de notication.
3. Le système identie le responsable de club concerné.
4. Le système envoie la notication (via le tableau de bord ou email).
5. Le responsable reçoit et peut consulter l'alerte.
Scénarios Alternatifs Erreur d'envoi : Si le destinataire n'est pas trouvé ou si le service de
notication échoue, le système enregistre l'erreur dans les logs pour une
tentative ultérieure.
Postconditions La notication est marquée comme  non lue  dans l'espace du respon-
sable de club.
Table 1.40  Description textuelle : Notication automatique du responsable

Figure 1.41  DSS : Notication du responsable de club

74
S'authentier (Login)
Réalisé par : ZERIZER ISRA
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation S'authentier (Login)
Acteur Principal Athlète (ou tout utilisateur enregistré)
Objectif Permettre à l'utilisateur de s'authentier pour accéder à son espace de
travail personnel.
Préconditions L'acteur doit posséder un compte déjà créé dans le système.
Scénario Nominal
1. L'utilisateur demande l'accès à son espace de travail (clic sur
"Connexion").
2. Le système ache l'interface d'authentication (formulaire).
3. L'utilisateur remplit le formulaire avec ses identiants et valide.
4. Le système vérie la validité des informations saisies en base de don-
nées.
5. Le système redirige l'utilisateur et ache son espace de travail person-
nalisé.
Scénarios Alternatifs Échec d'authentication : Si les informations sont incorrectes, le sys-
tème ache le message d'erreur :  Les informations saisies sont invalides
 et redirige l'utilisateur vers l'étape 2.
Postconditions L'utilisateur a accès à ses fonctionnalités privées et son jeton de session
est actif.
Table 1.41  Description textuelle : Authentication de l'utilisateur

B. Diagramme de Séquence Système (DSS)

75
 Figure 1.42  DSS : S'authentier

1.3.4 Acteur : Utilisateur Public (Public User)

Naviguer sur le site (Browse Website)
Réalisé par : BOUKHETINI MOUSTAFA
A. Description textuelle du scénario
B. Diagramme de Séquence Système (DSS)

76
Propriété Description
Cas d'utilisation Naviguer sur le site (Browse Website)
Acteur Principal Utilisateur Public (Public User)
Objectif Permettre à un visiteur non authentié d'accéder aux informations pu-
bliques et de naviguer entre les diérentes pages du site.
Préconditions L'utilisateur dispose d'une connexion internet et accède à l'URL de l'ap-
plication.
Scénario Nominal
1. L'utilisateur ouvre le site web.
2. Le système ache la page d'accueil (Homepage).
3. L'utilisateur sélectionne une page spécique (ex : À propos, Clubs,
Contact).
4. Le système charge les données de la page demandée.
5. Le système ache la page correspondante à l'utilisateur.
Scénarios Alternatifs Page introuvable (Erreur 404) : Si l'utilisateur tente d'accéder à une
page inexistante ou si les données ne peuvent être chargées, le système
ache un message d'erreur approprié.
Postconditions L'utilisateur a consulté les informations souhaitées sans nécessité de
compte utilisateur.
Table 1.42  Description textuelle : Navigation publique

Figure 1.43  DSS : Naviguer sur le site (Public User)

77
Consulter les ores (Check Oers)
Réalisé par : BOUMECHAL SALIHA
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Consulter les ores (Check Oers)
Acteur Principal Utilisateur Public (Public User)
Objectif Permettre aux visiteurs de visualiser les ores disponibles an de les at-
tirer et de les aider à trouver les meilleures infrastructures sportives.
Préconditions L'utilisateur se trouve sur la page principale de l'application.
Scénario Nominal
1. L'utilisateur navigue vers la section  Ores .
2. Le système récupère les ores actives depuis la base de données.
3. Le système ache les détails des ores (prix, durée, description, infra-
structures liées).
Scénarios Alternatifs Absence d'ores : Dans le cas exceptionnel où aucune ore n'est active
en base de données, le système ache le message :  Aucune ore dispo-
nible pour le moment .
Postconditions L'utilisateur reste sur la page des ores ou se dirige vers la section d'ins-
cription (Sign-up) pour proter d'une ore.
Table 1.43  Description textuelle : Consultation des ores par le public

B. Diagramme de Séquence Système (DSS)

78
Figure 1.44  DSS : Consulter les ores

79
Laisser un avis (Leave Feedback)
Réalisé par : SELLAHI BESSAM
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Laisser un avis (Leave Feedback)
Acteur Principal Utilisateur Public (Public User)
Acteur Secondaire Système
Objectif Permettre aux utilisateurs (même non connectés) de donner leur avis ou
de laisser des commentaires sur l'application ou les services proposés.
Préconditions L'utilisateur doit avoir accès à l'application. Aucune authentication n'est
requise.
Scénario Nominal
1. L'utilisateur public ouvre l'application.
2. L'utilisateur parcourt les diérentes sections du site.
3. L'utilisateur clique sur le bouton ou le lien  Laisser un avis  (Leave
a feedback).
4. L'utilisateur rédige son commentaire dans le champ prévu à cet eet.
5. L'utilisateur soumet son avis.
6. Le système enregistre le feedback et ache un message de remercie-
ment.
Scénarios Alternatifs Champ vide : Si l'utilisateur tente de soumettre un avis sans texte, le
système ache un message d'erreur et bloque l'envoi.
Postconditions Le feedback est stocké dans la base de données et peut être consulté
ultérieurement par l'administrateur.
Table 1.44  Description textuelle : Envoi d'un feedback

B. Diagramme de Séquence Système (DSS)

80
Figure 1.45  DSS : Laisser un avis

81
Consulter les infrastructures (Check Facilities)
Réalisé par : ZEKRI MOUFIDA
A. Description textuelle du scénario
Propriété Description
Cas d'utilisation Consulter les infrastructures
Acteur Principal Utilisateur Public (Public User)
Objectif Permettre à un visiteur de visualiser la liste des installations sportives et
d'obtenir des détails sur leurs disponibilités sans être connecté.
Préconditions L'utilisateur accède à la page d'accueil (Landing Page ).
Scénario Nominal
1. L'utilisateur demande à visualiser les infrastructures.
2. Le système ache la liste des installations (Football, Tennis, etc.).
3. [Optionnel] L'utilisateur clique sur une infrastructure spécique pour
voir les détails.
4. Le système ache la description complète et les créneaux horaires dispo-
nibles.
Contraintes Aucune réservation n'est autorisée à ce stade. L'utilisateur doit s'authentier
pour eectuer une réservation.
Postconditions L'utilisateur a pris connaissance des ores et des disponibilités du complexe.

Table 1.45  Description textuelle : Consulter les infrastructures

B. Diagramme de Séquence Système (DSS)

82
 Figure 1.46  DSS : Consulter les infrastructures

1.4 Conception des Interfaces Homme-Machine (IHM)

La conception des Interfaces Homme-Machine (IHM) est une étape essentielle qui fait le pont entre
la modélisation conceptuelle et le développement technique. Avant d'entamer la phase de codage, nous
avons réalisé des maquettes (wireframes) pour nos principaux cas d'utilisation.
Ces interfaces initiales nous ont permis de dénir l'ergonomie, la disposition des éléments (formu-
laires, tableaux de bord, boutons d'action) et le parcours utilisateur, an de garantir une navigation
intuitive pour chaque type d'acteur.
Voici les maquettes correspondantes à nos scénarios principaux :

1.4.1 Interface d'Authentication

Cette maquette illustre l'écran de connexion et d'inscription, permettant aux diérents acteurs
d'accéder à leurs espaces respectifs.

1.4.2 Interface de Réservation d'Infrastructure

Formulaire permettant au responsable de club de sélectionner une date, une heure et un terrain
pour planier une session d'entraînement.

1.4.3 Interface de Gestion des Groupes

Tableau de bord dédié au responsable de club pour visualiser, ajouter ou modier les groupes
(équipes) rattachés à son club.

1.4.4 Interface de Décision sur les Réservations

Espace administrateur (Manager) listant les demandes de réservation en attente, avec les options
pour les approuver ou les rejeter.

83
 Figure 1.47  Maquette de l'interface : Authentication

Figure 1.48  Maquette de l'interface : Eectuer une réservation

84
 Figure 1.49  Maquette de l'interface : Gérer les groupes

Figure 1.50  Maquette de l'interface : Décision sur une réservation

85
1.4.5 Interface de Demande d'Adhésion
Vue côté Athlète présentant les détails d'un groupe et le bouton permettant d'envoyer une demande
pour le rejoindre.

Figure 1.51  Maquette de l'interface : Demander à rejoindre un groupe

1.4.6 Interface de Gestion des Infrastructures

Vue permettant au Manager de congurer le complexe sportif, d'ajouter de nouvelles salles ou de
modier la capacité des terrains existants.

1.4.7 Interface de Gestion des Demandes d'Athlètes

Tableau récapitulatif pour le responsable de club, achant les candidatures des athlètes souhaitant
intégrer ses groupes.

86
 Figure 1.52  Maquette de l'interface : Gérer les infrastructures

Figure 1.53  Maquette de l'interface : Gérer les demandes des athlètes

1.4.8 Interface de Gestion des Responsables de Clubs

Tableau d'administration du gérant (Manager) pour superviser la création et les accès des leaders
de clubs.

Figure 1.54  Maquette de l'interface : Gérer les responsables de clubs

1.5 Conclusion
Ce premier chapitre nous a permis de poser les bases fondamentales de notre projet en réalisant
une analyse approfondie des besoins. À travers l'étude de l'existant et le recensement des attentes des
futurs utilisateurs, nous avons pu dénir avec précision le périmètre fonctionnel de notre plateforme
de gestion de complexe sportif.
La modélisation par les diagrammes de cas d'utilisation a mis en lumière les responsabilités de

87
chaque acteur (Athlètes, Responsables de clubs et Gérant), garantissant ainsi une couverture com-
plète des processus métiers. De plus, l'élaboration des Diagrammes de Séquence Système (DSS) a
permis de valider la logique des interactions et les ux d'informations circulant entre les utilisateurs et
l'application.
En somme, ce travail d'analyse nous a permis de comprendre ce que le système doit faire. Cette
compréhension est indispensable pour aborder sereinement la phase suivante. Ainsi, le chapitre suivant
sera consacré à la conception technique, où nous traduirons ces exigences en une architecture logicielle
et une structure de données prêtes pour l'implémentation.

88
Chapitre 2

Conception (Phase d'Élaboration)

2.1 Introduction
Après avoir identié les besoins fonctionnels et modélisé les interactions globales entre les acteurs
et le système lors de la phase d'analyse (Chapitre 1), ce deuxième chapitre est consacré à la phase
de conception. Si l'analyse visait à dénir ce que le système doit faire, la conception a pour but de
déterminer comment il va le faire.
L'objectif de ce chapitre est de fournir une architecture détaillée et exhaustive de notre plateforme
de gestion sportive. Nous commencerons par modéliser la dynamique interne du système à l'aide des
diagrammes de classes participantes (selon le patron Boundary-Control-Entity). Ensuite, nous déni-
rons la structure statique des données à travers le diagramme de classes global, que nous traduirons en
Modèle Logique de Données (MLD) et en dictionnaire de données pour notre base PostgreSQL. Enn,
nous détaillerons la logique des opérations via les diagrammes de séquence détaillés et nous présenterons
la conception ergonomique de notre application grâce aux maquettes des interfaces (IHM).

2.2 Analyse (Modèle MVC / BCE)

2.2.1 Diagrammes de Classes Participantes
Dans cette phase de conception, nous utilisons les diagrammes de classes participantes pour illustrer
la réalisation dynamique de nos cas d'utilisation. Ces diagrammes reposent sur le patron d'architecture
MVC / BCE (Boundary-Control-Entity), qui s'aligne parfaitement avec notre architecture 3-
Tiers :
 Boundary (Frontière / Vue) : Représente l'interface avec laquelle l'utilisateur interagit. Dans
notre projet, il s'agit des composants ReactJS (pages, formulaires, boutons).
 Control (Contrôle / Logique) : Représente le traitement des requêtes, la validation et la
logique métier. Cela correspond à nos contrôleurs et routes développés avec [Link] et Ex-
pressJS.
 Entity (Entité / Modèle) : Représente les données persistantes du système. Ces classes cor-
respondent à nos tables dans la base de données PostgreSQL.
Nous présentons ci-dessous l'interaction entre ces trois types de classes pour les scénarios les plus
critiques de notre plateforme.

Authentication (Authenticate)
Réalisé par : BAOUT
Ce diagramme illustre le processus de connexion. La classe frontière (LoginPage ) capture les identiants
et les transmet au contrôleur (AuthController ). Ce dernier vérie les informations auprès de l'entité
(User ) dans PostgreSQL et génère un jeton JWT en cas de succès.

89
 Figure 2.1  Diagramme des classes participantes : Authentication

Eectuer une réservation (Make a reservation)

Réalisé par : AMMORA BARAA
Lorsqu'un responsable souhaite réserver une infrastructure, il utilise la vue ReservationForm. Le contrô-
leur ReservationController vérie la disponibilité de l'entité Facility avant de créer et d'enregistrer une
nouvelle entité Reservation.

Gérer les groupes (Manage groups)

Réalisé par : IMANE ZEDDAM
Le responsable de club interagit avec la page GroupDashboard pour ajouter, modier ou supprimer des
groupes d'entraînement. Le GroupController traite ces actions et met à jour les entités Group et Club
dans la base de données.

Décision sur une demande de réservation (Decision on a reservation request)

Réalisé par : AYACHE MOHAMMED
Le gérant (Manager) utilise l'interface ManagerDashboard pour visualiser les demandes en attente.
Lorsqu'il approuve ou refuse, le DecisionController modie l'état (statut) de l'entité Reservation et
notie l'utilisateur concerné.

Demander à rejoindre un groupe (Request to join a group)

Réalisé par : TEAM 2
Un athlète utilise la vue GroupDetailsView pour soumettre sa demande. Le JoinRequestController
crée alors une entité de liaison JoinRequest qui relie l'entité Athlete à l'entité Group, avec le statut "en
attente".

Gérer les infrastructures (Manage facility)

Réalisé par : TEAM 3
À travers la vue FacilityManagementPage, le gérant peut ajouter ou retirer des terrains et des salles. Le

90
Figure 2.2  Diagramme des classes participantes : Eectuer une réservation

91
Figure 2.3  Diagramme des classes participantes : Gérer les groupes

92
Figure 2.4  Diagramme des classes participantes : Décision sur une réservation

Figure 2.5  Diagramme des classes participantes : Rejoindre un groupe

93
FacilityController se charge de répercuter ces changements directement sur les entités Facility stockées
dans PostgreSQL.

Figure 2.6  Diagramme des classes participantes : Gérer les infrastructures

Gérer les demandes des athlètes (Manage requests from athlete)

Réalisé par : TEAM 4
Le responsable de club gère les candidatures depuis l'interface AthleteRequestsView. Le RequestMa-
nagementController récupère toutes les entités JoinRequest ciblées, permet de modier leur statut
(Accepté/Refusé), et met à jour les entités correspondantes.

94
Figure 2.7  Diagramme des classes participantes : Gérer les demandes d'athlètes

95
2.3 Conception Détaillée
2.3.1 Diagrammes de Séquence Détaillés
Alors que les diagrammes de séquence système (DSS) présentés précédemment se concentraient sur
l'interaction entre l'acteur et le système global, les diagrammes de séquence détaillés exposent ici la
logique interne de l'application.
Ils illustrent les échanges précis entre les diérentes couches de notre architecture :
 L'Acteur : Déclencheur de l'action.
 L'Interface (React) : Capture les entrées et ache les résultats.
 Le Contrôleur (Express/[Link]) : Traite la logique métier et les requêtes API.
 La Base de données (PostgreSQL) : Assure la persistance des informations.
Nous présentons ci-après l'ensemble des scénarios détaillés respectant l'ordre logique des fonction-
nalités du système.

DS : Mettre à jour une infrastructure

Figure 2.8  Diagramme de Séquence Détaillé : Mettre à jour une infrastructure

DS : Modier un groupe

96
 Figure 2.9  Diagramme de Séquence Détaillé : Modier un groupe

DS : Eectuer une réservation (Gérant)

Figure 2.10  Diagramme de Séquence Détaillé : Eectuer une réservation (Gérant)

DS : Créer un gérant

97
 Figure 2.11  Diagramme de Séquence Détaillé : Créer un gérant

DS : Gérer les infrastructures

Figure 2.12  Diagramme de Séquence Détaillé : Gérer les infrastructures

DS : Gérer les responsables de clubs

98
 Figure 2.13  Diagramme de Séquence Détaillé : Gérer les responsables de clubs

DS : Gérer les gérants

99
Figure 2.14  Diagramme de Séquence Détaillé : Gérer les gérants

100
DS : Ajouter un responsable de club

Figure 2.15  Diagramme de Séquence Détaillé : Ajouter un responsable de club

DS : Supprimer un responsable de club

Figure 2.16  Diagramme de Séquence Détaillé : Supprimer un responsable de club

DS : Gérer les clubs

101
 Figure 2.17  Diagramme de Séquence Détaillé : Gérer les clubs

DS : Ajouter un club

102
 Figure 2.18  Diagramme de Séquence Détaillé : Ajouter un club

DS : Supprimer un gérant

103
 Figure 2.19  Diagramme de Séquence Détaillé : Supprimer un gérant

DS : Supprimer une infrastructure

104
 Figure 2.20  Diagramme de Séquence Détaillé : Supprimer une infrastructure

DS : Aecter un responsable de club

Figure 2.21  Diagramme de Séquence Détaillé : Aecter un responsable de club

DS : Ajouter un groupe

105
 Figure 2.22  Diagramme de Séquence Détaillé : Ajouter un groupe

DS : Sélectionner une date

Figure 2.23  Diagramme de Séquence Détaillé : Sélectionner une date

DS : Vérier la disponibilité

106
 Figure 2.24  Diagramme de Séquence Détaillé : Vérier la disponibilité

DS : Supprimer un groupe

Figure 2.25  Diagramme de Séquence Détaillé : Supprimer un groupe

DS : Modier la date de réservation

107
 Figure 2.26  Diagramme de Séquence Détaillé : Modier la date de réservation

DS : Demander une réservation

Figure 2.27  Diagramme de Séquence Détaillé : Demander une réservation

DS : Consulter les groupes

108
 Figure 2.28  Diagramme de Séquence Détaillé : Consulter les groupes

DS : Examiner les demandes d'adhésion

Figure 2.29  Diagramme de Séquence Détaillé : Examiner les demandes d'adhésion

DS : Gérer les clubs (Leader)

109
 Figure 2.30  Diagramme de Séquence Détaillé : Gérer les clubs

DS : Demander la modication d'une réservation

110
 Figure 2.31  Diagramme de Séquence Détaillé : Demander la modication d'une réservation

DS : Gérer les demandes des athlètes

Figure 2.32  Diagramme de Séquence Détaillé : Gérer les demandes des athlètes

DS : Prendre une décision

111
 Figure 2.33  Diagramme de Séquence Détaillé : Prendre une décision

DS : Se déconnecter

Figure 2.34  Diagramme de Séquence Détaillé : Se déconnecter

DS : Consulter les groupes rejoints

112
 Figure 2.35  Diagramme de Séquence Détaillé : Consulter les groupes rejoints

DS : Consulter les détails d'un groupe

Figure 2.36  Diagramme de Séquence Détaillé : Consulter les détails d'un groupe

DS : Consulter les notications de groupe

113
 Figure 2.37  Diagramme de Séquence Détaillé : Consulter les notications de groupe

DS : Valider les identiants

Figure 2.38  Diagramme de Séquence Détaillé : Valider les identiants

DS : Parcourir les groupes (Athlète)

114
 Figure 2.39  Diagramme de Séquence Détaillé : Parcourir les groupes (Athlète)

DS : Notication du responsable de club

Figure 2.40  Diagramme de Séquence Détaillé : Notication du responsable de club

DS : S'authentier

115
 Figure 2.41  Diagramme de Séquence Détaillé : S'authentier

DS : Naviguer sur le site (Public User)

Figure 2.42  Diagramme de Séquence Détaillé : Naviguer sur le site (Public User)

DS : Consulter les ores

116
 Figure 2.43  Diagramme de Séquence Détaillé : Consulter les ores

DS : Laisser un avis

Figure 2.44  Diagramme de Séquence Détaillé : Laisser un avis

2.3.2 Diagramme de Classes Global (Conception)

Le diagramme de classes global constitue l'épine dorsale de la conception de notre système. Il
modélise la structure statique de l'application en détaillant les diérentes entités, leurs attributs, leurs
méthodes, ainsi que les relations (associations, multiplicités, compositions et héritages) qui les unissent.
Comme illustré dans la gure ci-dessous, notre modèle repose sur une architecture orientée objet
claire. On y retrouve notamment une classe généralisée User de laquelle héritent les diérents prols
d'acteurs (Athlete, ClubLeader, Manager ). Le diagramme met également en évidence la logique métier
centrale de la plateforme : la gestion des Clubs et de leurs Groups, la planication des TrainingSessions,
ainsi que le processus de Reservation lié aux infrastructures (Facility ).

117
Figure 2.45  Diagramme de classes global du système

118
2.4 Modèle Relationnel (Base de données)
2.4.1 Règles de passage du modèle objet au modèle relationnel
Pour transformer notre diagramme de classes (conceptuel) en un Modèle Logique de Données
(MLD) implémentable sous PostgreSQL, nous avons appliqué les règles standard de passage de l'orienté
objet vers le relationnel. Voici les règles spéciques qui ont guidé notre conception :
 Règle 1 : Transformation des classes en tables
Chaque classe d'entité principale (Facility, Club, Reservation, Notication ) a été transformée en
une table relationnelle. Les attributs simples de ces classes sont devenus les colonnes (champs)
des tables correspondantes. Pour chaque table, nous avons ajouté un identiant unique technique
(id) de type SERIAL qui agit comme Clé Primaire (PK).
 Règle 2 : Gestion de l'héritage (Généralisation / Spécialisation)
Dans notre diagramme de classes, les acteurs Manager, ClubLeader et Athlete héritent de la classe
mère User. Pour le modèle relationnel, nous avons opté pour la stratégie de la Table Unique
(Single Table). Au lieu de créer trois tables séparées, nous avons fusionné ces entités en une
seule table User et ajouté un attribut discriminant type (de type ENUM) pour diérencier le rôle
de chaque utilisateur. Cela simplie grandement l'authentication.
 Règle 3 : Traduction des associations de type (1..* ou 0..*)
Une association de type "Un-à-Plusieurs" se traduit par l'ajout d'une Clé Étrangère (FK)
dans la table située du côté "Plusieurs (*)". Cette clé pointe vers la clé primaire de la table
située du côté "Un (1)".
 Exemple 1 : Un club possède plusieurs groupes (1..*). Nous avons donc ajouté la clé étrangère
#club_id dans la table Club_Group.
 Exemple 2 : Une réservation est liée à un groupe, à une infrastructure et est traitée par un
manager. Nous avons inséré les clés étrangères #group_id, #facility_id et #manager_id
dans la table Reservation.
 Règle 4 : Gestion des identiants et de l'intégrité référentielle
Toutes les relations entre nos entités sont sécurisées au niveau de la base de données PostgreSQL
par des contraintes d'intégrité (Foreign Key Constraints). Cela garantit, par exemple, qu'on ne
peut pas supprimer un club si des groupes y sont encore rattachés, assurant ainsi la cohérence
globale de notre système d'information.

2.4.2 Le Modèle Logique de Données (MLD / ERD)

Le Modèle Logique de Données (MLD) permet de traduire le diagramme de classes en un schéma
relationnel adapté à notre Système de Gestion de Base de Données (PostgreSQL). Les règles de passage
du modèle objet au modèle relationnel nous donnent les relations suivantes (les clés primaires sont
soulignées et les clés étrangères sont précédées d'un #) :
 User (id, name, password, type)
 Facility (id, name, category, number_of_seats)
 Club (id, club_name, type_of_activity, place)
 Club_Group (id, group_name, #club_id)
 Reservation (id, state, time, duration, #manager_id, #group_id, #facility_id)
 Notication (id, description, time, is_feedback, #target_id)

119
2.4.3 Dictionnaire des données
Le dictionnaire des données détaille la structure interne de chaque table de la base de données
PostgreSQL, en précisant les types de données, les contraintes et la description de chaque champ.

Champ Type PostgreSQL Clé Description

id SERIAL PK Identiant unique de l'utilisateur (auto-incrémenté)
name VARCHAR(100) - Nom complet de l'utilisateur
password VARCHAR(255) - Mot de passe haché (sécurisé via Bcrypt)
type ENUM - Rôle de l'utilisateur ('Manager', 'Leader', 'Athlete')

Table 2.1  Dictionnaire des données : Table User

Champ Type PostgreSQL Clé Description

id SERIAL PK Identiant unique de l'infrastructure
name VARCHAR(150) - Nom de l'infrastructure (ex : Terrain de foot A)
category VARCHAR(100) - Type d'infrastructure (ex : Salle, Piscine, Stade)
number_of_seats INT - Capacité d'accueil ou nombre de places

Table 2.2  Dictionnaire des données : Table Facility

Champ Type PostgreSQL Clé Description

id SERIAL PK Identiant unique du club
club_name VARCHAR(150) - Nom ociel du club sportif
type_of_activity VARCHAR(100) - Discipline pratiquée (ex : Football, Natation)
place VARCHAR(255) - Emplacement, ville ou quartier du club

Table 2.3  Dictionnaire des données : Table Club

120
Champ Type PostgreSQL Clé Description
id SERIAL PK Identiant unique du groupe
group_name VARCHAR(100) - Nom du groupe (ex : U19, Seniors)
club_id INT FK Référence au club auquel appartient ce groupe

Table 2.4  Dictionnaire des données : Table Club_Group

Champ Type PostgreSQL Clé Description

id SERIAL PK Identiant unique de la réservation
state VARCHAR(50) - État de la réservation ('pending', 'approved', 'rejected')
time TIMESTAMP - Date et heure exactes du début de la réservation
duration INT - Durée de la réservation (exprimée en minutes)
manager_id INT FK Référence au gérant ayant traité/supervisé la demande
group_id INT FK Référence au groupe concerné par la réservation
facility_id INT FK Référence à l'infrastructure réservée

Table 2.5  Dictionnaire des données : Table Reservation

Champ Type PostgreSQL Clé Description

id SERIAL PK Identiant unique de la notication
description TEXT - Contenu textuel du message ou de l'avis
time TIMESTAMP - Date et heure de l'envoi de la notication
is_feedback BOOLEAN - Vrai (true) s'il s'agit d'un feedback public, Faux (false)
sinon
target_id INT FK Référence au destinataire (Utilisateur ou Groupe cible)

Table 2.6  Dictionnaire des données : Table Notication

121
2.5 Conclusion
Ce chapitre de conception nous a permis d'établir les fondations techniques et structurelles de
notre application. En passant d'une vision externe (cas d'utilisation) à une vision interne hautement
détaillée, nous avons pu cartographier l'ensemble de la logique métier. Le diagramme de classes et
le modèle relationnel garantissent désormais une base de données robuste et cohérente. De leur côté,
les diagrammes de séquence détaillés ont tracé le cheminement exact des données entre les interfaces,
les contrôleurs et la base de données. Enn, la conception des maquettes (IHM) nous a oert une
vision claire de l'expérience utilisateur nale. Toutes les spécications techniques et ergonomiques
étant désormais clairement dénies et documentées, nous disposons d'un plan solide pour entamer la
dernière étape de notre projet : le développement et l'implémentation de la solution, qui feront l'objet
du chapitre suivant.

122
Chapitre 3

Réalisation / Implémentation (Phase de

Construction)

3.1 Introduction
Après avoir recensé les besoins fonctionnels, modélisé les processus métiers et déni la structure
des données dans les chapitres précédents, nous entamons à présent la phase de réalisation. Cette
étape cruciale marque la transition dénitive entre la conception théorique (UML) et le développement
concret de notre plateforme web de gestion de complexe sportif.
L'objectif de ce troisième et dernier chapitre est de présenter de manière transparente et détaillée
le processus d'implémentation de l'application. Nous y exposerons dans un premier temps l'architec-
ture logicielle adoptée pour garantir la robustesse du système. Ensuite, nous décrirons l'environnement
matériel et logiciel, en justiant le choix de notre  stack  technique (langages, frameworks et outils
d'aide au développement). Enn, nous mettrons en évidence l'aboutissement de ce travail de dévelop-
pement à travers la présentation des interfaces graphiques (IHM) nales, illustrant l'ergonomie et les
fonctionnalités oertes à chaque prol d'utilisateur.

3.2 Architecture du Système

Le succès d'une plateforme de gestion complexe repose sur une structure capable de gérer des
ux de données hétérogènes (réservations, adhésions, notications). Pour ce projet, nous avons adopté
une architecture **3-Tiers (ou architecture à trois niveaux)**, qui est le standard industriel pour les
applications web modernes.
Cette séparation en trois couches indépendantes permet une grande exibilité : on peut modier
l'interface (Front-end) sans impacter la logique métier (Back-end) ou la structure des données.
3.1

3.2.1 Description des trois couches

1. La Couche Présentation (Front-end) : Développée avec ReactJS, cette couche est la seule
interface avec laquelle les utilisateurs (Manager, Leader, Athlète) interagissent. Elle est respon-
sable de la récupération des entrées utilisateur et de l'achage des données de manière dyna-
mique. Elle communique avec le serveur via des requêtes asynchrones (API REST) utilisant la
bibliothèque Axios.
2. La Couche Traitement ou Logique Métier (Back-end) : Propulsée par [Link] et le
framework Express, cette couche constitue le  cerveau  du système. Elle reçoit les requêtes du
Front-end, vérie l'identité de l'utilisateur via des Tokens JWT, exécute les règles métiers (ex :
vérier si une infrastructure est libre avant de conrmer une réservation) et prépare les réponses
au format JSON.
3. La Couche d'Accès aux Données (Database) : Le système de gestion de base de données
relationnelle PostgreSQL assure le stockage permanent. Toutes les relations complexes (un club

123
 possède plusieurs groupes, un athlète appartient à plusieurs clubs) sont gérées ici grâce à des
contraintes d'intégrité référentielle strictes.

3.2.2 Flux de travail et Communication (Workow)

Le fonctionnement global suit un cycle de communication sécurisé :
 Requête : L'utilisateur eectue une action (ex : l'Athlète clique sur  Rejoindre un groupe ).
Le Front-end envoie une requête HTTP (POST) au serveur Express avec l'identiant du groupe
et le Token de l'utilisateur.
 Authentication & Validation : Le serveur intercepte la requête, valide le Token JWT. S'il
est valide, le contrôleur métier vérie en base de données si l'athlète n'est pas déjà inscrit.
 Traitement des données : Le serveur communique avec PostgreSQL via des requêtes SQL
pour enregistrer la nouvelle demande d'adhésion.
 Réponse : Une fois l'opération réussie, le serveur renvoie un code de succès (200 OK). Le Front-
end met alors à jour l'interface en temps réel pour conrmer l'action à l'athlète (ex : achage
d'une notication ou changement de statut du bouton).

Figure 3.1  Schéma détaillé de l'architecture 3-Tiers et du ux de données

3.3 Environnement Matériel et Logiciel

Cette section détaille les ressources physiques et logicielles mobilisées pour assurer le développement,
les tests et le déploiement de la plateforme. Un environnement bien conguré est le garant de la
productivité de l'équipe et de la robustesse de l'application.

3.3.1 Environnement Matériel (Hardware)

Le développement a été réalisé sur des stations de travail dotées des congurations minimales
suivantes, nécessaires pour faire tourner simultanément les serveurs de développement (Front-end et
Back-end) ainsi que le système de gestion de base de données :

124
  Processeur : Intel Core i5 / i7 (ou équivalent) pour assurer une compilation rapide du code.
 Mémoire vive (RAM) : 8 Go minimum (16 Go recommandés) pour supporter l'exécution de
Docker (si utilisé), de VS Code et des navigateurs.
 Stockage : SSD de 256 Go pour des temps de lecture/écriture optimisés lors de l'installation
des dépendances (node_modules ).
 Système d'exploitation : Windows 10/11 ou macOS, utilisant souvent WSL2 (Windows Sub-
system for Linux) pour un environnement de développement proche du déploiement réel.

3.3.2 Environnement Logiciel et Système

 Navigateurs Web : Google Chrome et Mozilla Firefox, utilisés pour les tests de compatibilité
et l'inspection du DOM via les DevTools.
 Serveur de base de données : PostgreSQL installé localement pour la phase de développement.
 Environnement d'exécution : [Link] (Version LTS) agissant comme moteur d'exécution
JavaScript côté serveur.

3.3.3 Stack Technique (Technologies de développement)

Nous avons opté pour une stack moderne et performante, favorisant la rapidité de développement
et la scalabilité.

Front-end : L'expérience utilisateur

 ReactJS (v18+) : Choisi pour sa gestion du DOM virtuel qui optimise les mises à jour de
l'interface. Sa structure basée sur les composants permet une réutilisation du code, essentielle
pour les tableaux de bord (Dashboards).
 [Link] : Utilisé comme outil de build à la place de Webpack. Il ore un rechargement à chaud
(Hot Module Replacement) quasi instantané, améliorant considérablement l'expérience de déve-
loppement.
 Tailwind CSS : Un framework CSS utilitaire qui permet de construire des interfaces personna-
lisées sans quitter le chier HTML/JSX. Il garantit un design responsive avec très peu de code
CSS personnalisé.
 Axios : Pour la gestion des requêtes asynchrones vers l'API. Nous l'avons préféré à l'API Fetch
native pour sa gestion simpliée des intercepteurs (utile pour injecter les tokens JWT).

Back-end : Logique métier et Sécurité

 ExpressJS : Framework minimaliste pour [Link]. Il nous permet de dénir les routes de l'API
(REST) et de gérer les middlewares de sécurité et de journalisation.
 JSON Web Token (JWT) : Standard utilisé pour l'authentication sécurisée. Une fois connecté,
l'utilisateur reçoit un token crypté lui permettant d'accéder aux routes protégées selon son rôle
(Manager, Leader ou Athlète).
 Bcrypt : Bibliothèque de hachage de fonctions pour sécuriser les mots de passe. Aucun mot de
passe n'est stocké en clair dans la base de données.
 PostgreSQL : SGBD relationnel choisi pour sa gestion rigoureuse des clés étrangères et des
contraintes d'intégrité, indispensables pour lier les athlètes, les clubs et les réservations.

3.3.4 Outils d'aide au développement

 Visual Studio Code (VS Code) : L'IDE principal, conguré avec des extensions telles que
ESLint et Prettier pour garantir la qualité et l'uniformité du code source.
 Postman : Utilisé pour simuler les requêtes HTTP (GET, POST, PUT, DELETE). Il a permis
de tester l'API de manière isolée avant même que l'interface front-end ne soit développée.

125
  Git & GitHub : Pour la gestion de versions (Version Control System). GitHub a servi de
plateforme collaborative permettant de fusionner les travaux des diérents membres de l'équipe
via des Pull Requests.
 StarUML / [Link] : Pour la documentation technique et la mise à jour des diagrammes
UML au fur et à mesure de l'évolution du projet.

3.4 Réalisation des Interfaces (Résultat Final)

Cette section présente les interfaces graphiques développées pour notre application. An d'orir la
meilleure expérience utilisateur possible, nous avons conçu des tableaux de bord spéciques et adaptés
aux besoins de chaque type d'acteur.

3.4.1 Interfaces de l'Utilisateur Public (Visiteur)

L'interface publique permet aux visiteurs non connectés de découvrir le complexe sportif, de consul-
ter les infrastructures disponibles et de laisser des avis.

Figure 3.2  Page d'accueil principale (User Dashboard)

Figure 3.3  Aperçu secondaire de la page d'accueil

126
Figure 3.4  Consultation des infrastructures disponibles

Figure 3.5  Formulaire pour laisser un avis (Feedback)

127
3.4.2 Interfaces de l'Athlète
L'espace Athlète permet aux sportifs de s'inscrire, de gérer leur prol, d'explorer les groupes des
clubs et d'envoyer des demandes d'adhésion.

Figure 3.6  Page d'inscription (Sign-in / Register) pour les athlètes

Figure 3.7  Page de connexion (Login)

128
 Figure 3.8  Tableau de bord de l'athlète

Figure 3.9  Consultation de la liste des groupes (Check Groups)

Figure 3.10  Détails d'un groupe avant d'envoyer une demande

129
Figure 3.11  Conrmation de l'envoi de la demande d'adhésion

Figure 3.12  Consultation des notications de groupe

130
3.4.3 Interfaces du Responsable de Club (Club Leader)
Cet espace est dédié à la gestion quotidienne des activités du club : validation des inscriptions,
création des groupes et demandes de réservation d'infrastructures.

Figure 3.13  Tableau de bord du Leader de Club (Vue principale)

Figure 3.14  Tableau de bord du Leader de Club (Vue détaillée)

131
 Figure 3.15  Gestion des groupes existants

Figure 3.16  Formulaire de création d'un nouveau groupe

132
Figure 3.17  Gestion des demandes d'adhésion des athlètes

133
Figure 3.18  Notications de nouvelles demandes d'athlètes

134
 Figure 3.19  Sélection d'une date et d'une infrastructure

Figure 3.20  Formulaire de demande de réservation d'infrastructure

135
3.4.4 Interfaces du Gérant (Manager)
Le manager détient les droits d'administration de la plateforme. Il gère les infrastructures, les clubs,
ainsi que les autres gérants et responsables.

Figure 3.21  Interface de gestion des infrastructures sportives

136
Figure 3.22  Ajout d'une nouvelle infrastructure au complexe

Figure 3.23  Liste et gestion des clubs inscrits

137
Figure 3.24  Création d'un nouveau prol de club

138
Figure 3.25  Gestion des comptes des responsables de clubs

Figure 3.26  Ajout d'un nouveau responsable de club

139
Figure 3.27  Gestion des administrateurs (Managers) du système

Figure 3.28  Création d'un nouveau compte Manager

140
 Figure 3.29  Prise de décision (Validation/Refus) sur les requêtes système

3.5 Conclusion
Ce chapitre a été entièrement consacré à la concrétisation de notre projet. En nous appuyant sur
l'architecture 3-Tiers et une stack technique robuste, nous avons pu traduire les modèles conceptuels
et les cas d'utilisation dénis précédemment en une application web fonctionnelle.
La présentation des diérentes interfaces graphiques conrme que les besoins de chaque acteur
(Athlète, Responsable de club, Gérant et Visiteur public) ont été pris en compte, orant à chacun un
espace de travail ergonomique, intuitif et adapté à ses missions.
En dénitive, la combinaison de technologies modernes telles que ReactJS, Express et PostgreSQL a
permis de construire une plateforme performante et hautement évolutive. L'utilisation continue d'outils
de versionnage (Git) et de test (Postman) tout au long du cycle de vie du projet a sécurisé le processus
de développement, menant à une implémentation dèle et rigoureuse aux spécications établies lors de
la phase d'analyse.

141
Conclusion Générale
Arrivés au terme de ce projet de n d'études, qui a consisté en la conception et la réalisation d'une
plateforme intégrée de gestion pour un complexe sportif, nous pouvons armer que les objectifs xés
initialement ont été atteints. Ce travail nous a permis de traverser toutes les étapes du cycle de vie
d'un projet logiciel, de l'analyse des besoins à l'implémentation technique.
Bilan du projet Tout au long de ce parcours, nous avons veillé à respecter une méthodologie
rigoureuse : * L'analyse fonctionnelle nous a permis de comprendre les enjeux métier et d'identier les
besoins spéciques des athlètes, des responsables de clubs et des gérants. * La phase de conception a
été le pilier central de notre travail, où nous avons traduit des exigences abstraites en une architecture
solide (modèle relationnel PostgreSQL, diagrammes de classes et de séquence détaillés). * La réalisation
technique, s'appuyant sur des technologies modernes ([Link] pour le front-end, [Link]/Express pour
le back-end), a donné naissance à une application fonctionnelle, ergonomique et sécurisée.
Enseignements tirés Sur le plan personnel et professionnel, ce projet a été un dé enrichissant.
Il nous a permis d'approfondir nos compétences en développement **Full-Stack** et en modélisation
**UML**. Nous avons également appris l'importance de la rigueur dans la conception des bases de
données et la nécessité de placer l'expérience utilisateur (UX) au c÷ur du développement. Les obstacles
rencontrés lors de l'implémentation des logiques de réservation complexes ont renforcé notre capacité
de résolution de problèmes et notre autonomie.
Perspectives d'avenir Bien que la solution actuelle soit pleinement opérationnelle, elle constitue
une base évolutive qui pourrait être enrichie par plusieurs fonctionnalités futures : 1. Intégration d'un
module de paiement : Pour permettre aux clubs de régler leurs réservations en ligne de manière sécuri-
sée. 2. Application Mobile : Développer une version mobile native (React Native) pour faciliter l'accès
aux athlètes en déplacement. 3. Algorithmes d'optimisation : Implémenter une gestion intelligente des
plannings pour maximiser l'occupation des terrains durant les heures creuses.
En conclusion, cette expérience restera une étape déterminante de notre formation. Elle nous a
non seulement permis de consolider nos acquis académiques, mais aussi de nous préparer concrètement
aux réalités du métier d'ingénieur logiciel. Nous clôturons ce chapitre académique avec la satisfaction
d'avoir livré un produit ni, prêt à répondre aux besoins concrets du monde sportif.

142