Table des matières

Chapitre I : Contexte et objectifs du projet………………………………………………… ………………………………8

Introduction : ....................................................................................................................................... 8
1 Contexte général du projet ..................................................................................................... 8
1.1 Cadre du projet........................................................................................................................ 8
1.2 Objectifs du projet ................................................................................................................... 8
2 Etude de l’existant ................................................................................................................... 8
2.1 Solutions existantes................................................................................................................. 8
2.1.1 La nouvelle version de site Web d’isimm ............................................................................... 8
2.1.2 L’ancienne version de site web d’isimm.................................................................................. 9
2.1.3 les interactions face à face et main à main ........................................................................... 11
2.1.4 Tableau comparatif ............................................................................................................... 11
2.2 Critique de l’existant ............................................................................................................. 12
2.3 Travail à réaliser .................................................................................................................... 12
3 Méthodologie de travail ........................................................................................................ 13
3.1 Méthode 2TUP ...................................................................................................................... 13
3.2 Méthode agile Scrum ............................................................................................................ 14
3.3 Méthodologie adoptée.......................................................................................................... 15
4 Diagramme de Gantt ............................................................................................................. 15
5 Conclusion ............................................................................................................................. 16
Chapitre II : Specification des besoins et analyse………………………………………………………………………….17

1 Introduction ........................................................................................................................... 17
2 Identification des acteurs ...................................................................................................... 17
3 Modèle de contexte du système informatisé ....................................................................... 17
3.1 Diagramme de contexte ........................................................................................................ 18
4 Capture des besoins .............................................................................................................. 18
4.1 Capture des besoins fonctionnels ......................................................................................... 18
4.2 Capture des besoins non fonctionnels .................................................................................. 20
5 Spécification des besoins fonctionnels.................................................................................. 20
5.1 Diagramme de cas d’utilisation général ................................................................................ 20

1
 6 Diagrammes de cas d’utilisation détaillés ............................................................................. 22
6.1 Diagramme de cas d’utilisation détaillé de l’acteur « Représentant du club » .................... 22
6.2 Diagramme de cas d’utilisation détaillé de l’acteur « Responsable des clubs » ................... 22
6.3 Diagramme de cas d’utilisation détaillé de l’acteur « Etudiant » ......................................... 23
7 Diagrammes de séquence acteur-système ........................................................................... 24
7.1 Diagramme de séquence « gestion d’une demande » .......................................................... 24
7.2 Diagramme de séquence « consulter feedbacks »................................................................ 26
7.3 Diagramme de séquence « donner le droit d'accès à un club » ........................................... 28
7.4 Diagramme de séquence « rechercher des évènements par catégorie » ............................ 29
8 Choix technique ..................................................................................................................... 31
8.1 Framework Bootstrap............................................................................................................ 31
8.2 Framework Laravel ................................................................................................................ 32
9 Conclusion ............................................................................................................................. 32
Chapitre III : Conception……………………………………………………………………………………………………………….33

1 Introduction : ......................................................................................................................... 33
2 Modèle architectural ............................................................................................................. 33
2.1 L’architecture 3-tiers ............................................................................................................. 33
2.2 Modèle MVC .......................................................................................................................... 34
2.2.1 Diagramme de séquence MVC : ............................................................................................ 35
2.3 Architecture adoptée ............................................................................................................ 35
3 Conception de la base de données ....................................................................................... 36
3.1 Modèle conceptuel de données (MCD) ................................................................................ 36
3.2 Modèle Logique de données (MLD) ...................................................................................... 38
4 Conception logicielle détaillée .............................................................................................. 39
4.1 Conception des interfaces graphiques .................................................................................. 39
4.1.1 Maquettage : ......................................................................................................................... 39
5 Conclusion : ........................................................................................................................... 46

2
 Table des Figures
Figure 1: Page de connexion du site «Isimm » ........................................................................... 9
Figure 2: L'ancien site web d'isimm ......................................................................................... 10
Figure 3 : les interactions entre les différents acteurs ............................................................ 11
Figure 4: Représentation de la méthodologie 2TUP ................................................................ 14
Figure 5:Représentation de la méthodologie SCRUM ............................................................. 15
Figure 6: Diagramme de Gantt ................................................................................................. 16
Figure 7: Diagramme de contexte ............................................................................................ 18
Figure 8:Diagramme de cas d'utilisation général ..................................................................... 21
Figure 9: Diagramme de cas d'utilisation de l'acteur « Représentant du club » ..................... 22
Figure 10: Diagramme de cas d'utilisation de l'acteur « Responsable des clubs ».................. 23
Figure 11: Diagramme de cas d'utilisation de l’acteur « Etudiant » ........................................ 24
Figure 12: diagramme de séquence « gestion d’une demande » ............................................ 26
Figure 13: diagramme de séquence « consulter les feedbacks » ............................................ 28
Figure 14: diagramme de séquence « donner le droit d’accès à un club » ............................. 29
Figure 15: diagramme de séquence « Rechercher des évènements par catégorie » .............. 31
Figure 16: L’architecture 3-tiers .............................................................................................. 34
Figure 17: L'architecture du modèle MVC .............................................................................. 34
Figure 18: Diagramme de séquence MVC de représentant de club ........................................ 35
Figure 19: L'architecture de notre site Web ............................................................................ 35
Figure 20: Modèle Conceptuel de données (MCD) .................................................................. 36
Figure 21: Le Modèle Logique de Données .............................................................................. 39

3
 Résumé

Ce travail s’inscrit dans le cadre de l’accomplissement de notre Projet fédéré (méthode

Agile) à l’Institut Supérieur d'Informatique et de Mathématiques de Monastir pour l’année
universitaire 2022- 2023 demandé par notre professeur Mme. Aljia Bouzidi en vue de
l’obtention de notre note de Travaux Pratique . Ce projet a été effectué au sein de notre
établissement ayant comme objectif la conception et le développement d’un site Web de
gestion des Clubs . Pour réaliser ce projet, nous avons utilisé les frameworks Laravel et Mysql
pour gérer la base de données. Nous avons suivi la méthodologie 2TUP pour gérer notre
projet. En se basant sur ce document, nous décrivons en détail les différentes étapes de
réalisation de ce projet

Abstract

This work is part of the completion of our Federated Project (Agile Method) at the Higher
Institute of Computer Science and Mathematics of Monastir for the academic year 2022-
2023, requested by our professor Ms. Aljia Bouzidi in order to obtain our Practical Work
grade. This project was carried out within our institution with the objective of designing and
developing a Club Management Web site. To carry out this project, we used the Laravel and
Mysql frameworks to manage the database. We followed the 2TUP methodology to manage
our project. Based on this document, we describe in detail the different stages of this
project's implementation..

4
 Remercîment

Je tiens à exprimer nos sincère gratitude envers Madame Aljia Bouzidi, notre professeure et
mentore, pour son soutien et sa guidance durant tout le processus de notre projet fédéré. Sa
passion pour le domaine et son expertise ont été inestimables pour la réussite de notre
travail. Grâce à ses précieux conseils et son encouragement constant, nous avons pu
développer nos compétences et acquérir de nouvelles connaissances. Son engagement
envers notre réussite a été remarquable et mérite une mention spéciale dans ce rapport de
projet fédéré. Nous sommes extrêmement reconnaissants envers Madame Bouzidi pour son
dévouement et son soutien tout au long de ce projet.

y compris tous qui a contribué à la réussite de ce projet , votre soutien, votre expertise et
votre engagement ont été essentiels pour la réussite de ce projet.

Nous sommes reconnaissants pour toutes les heures de travail acharné, les réunions, les
discussions et les commentaires qui ont conduit à la réussite de notre travail . Votre
contribution a été inestimable et nous vous remercions sincèrement, vous méritez le
meilleur .

5
 INTRODUCTION GÉNÉRALE

De nos jours, la gestion de projet est un aspect crucial pour toute entreprise ou organisation
qui cherche à atteindre ses objectifs de manière efficace et efficiente. Cela est
particulièrement vrai dans le domaine de la gestion de club, où les responsables doivent
gérer les activités et les membres de manière organisée et cohérente pour assurer la
satisfaction des membres et la croissance de l'organisation.

Cependant, la gestion des clubs peut être un processus complexe et fastidieux, surtout si elle
est effectuée manuellement ou avec des outils obsolètes. la gestion des clubs est un défi
majeur pour de nombreux responsables. En effet, la coordination et l'organisation des
différentes activités, événements et membres peuvent s'avérer compliquées et
chronophages. De plus, les tâches administratives telles que la gestion des inscriptions et des
adhésions peuvent être fastidieuses et source d'erreurs humaines.

C'est pourquoi nous avons décidé de développer un site web de gestion des clubs pour aider
les responsables de club à gérer leurs activités et membres de manière plus efficace et
cohérente. Notre site Web sera conçue pour faciliter la souscription, l'organisation des
activités et des événements et la synchronisation du travail des responsables.

Notre projet de gestion des clubs s'étend sur trois chapitres, qui présentent les différentes
étapes de notre processus de développement.

Dans le premier chapitre, intitulé « Contexte et objectifs », nous présenterons le cadre

général de notre projet, ainsi que les solutions existantes et la méthodologie de travail que
nous avons adoptée. Nous examinerons également les principaux défis auxquels sont
confrontés les responsables de club et les avantages que notre application apportera.

Dans le deuxième chapitre, « Analyse et spécification des besoins », nous mettrons l'accent
sur les spécifications des besoins fonctionnels, non fonctionnels et techniques de notre
application. Nous identifierons les principales fonctionnalités de notre application, telles que
la gestion des événements et des activités, la gestion des paiements et des adhésions, et la
gestion des rapports.

Dans le troisième chapitre, « Conception », nous détaillerons la conception de la base de

données, des couches logicielles et des interfaces utilisateur de notre application. Nous
expliquerons comment notre application sera structurée et comment elle fonctionnera, en
fournissant des diagrammes et des illustrations pour clarifier nos concepts

6
Enfin, nous conclurons notre rapport par une synthèse générale de notre projet de gestion
de club et de ses avantages potentiels pour les responsables de club, les représentants et les
etudiants. Nous évaluerons également les perspectives d'avenir de notre projet et les
améliorations que nous pourrions apporter à notre application à l'avenir pour répondre aux
besoins changeants de nos utilisateurs.

En somme, notre projet de gestion des clubs vise à aider les responsables de club à gérer
leurs activités et membres de manière plus efficace et cohérente. Nous avons adopté une

7
CHAPITRE 1

Contexte et objectifs du projet

Introduction :
Au cours de ce chapitre, nous allons introduire notre projet en étudiant son cadre général et
la problématique qui a mené l'organisme d'accueil à réaliser cette application. Ensuite nous
allons procéder à l’étude de l’existant avec leurs critiques et nous introduirons les solutions
proposées. Par la suite, nous allons aborder une étude sur les différentes méthodologies de
travail existantes afin de dégager celle la plus adéquate à notre projet.

1 Contexte général du projet

Dans cette partie, nous allons présenter le cadre général du projet et ses objectifs

1.1 Cadre du projet

Le présent travail s'inscrit dans le cadre de l’accomplissement de notre Projet fédéré
(méthode Agile) à l’Institut Supérieur d'Informatique et de Mathématiques de Monastir pour
l’année universitaire 2022- 2023 demandé par notre professeur Mme. Aljia Bouzidi en vue
de l’obtention de notre note de Travaux Pratique .

1.2 Objectifs du projet

Le projet visait à concevoir et à développer un système de gestion des clubs au sein d'une
faculté universitaire. L'objectif de ce projet était de développer un site Web pouvant être
utilisé pour gérer différents clubs au sein de la faculté, y compris les clubs sportifs, culturels
et académiques qui améliore l'efficacité de la gestion des membres et des activités du club
en ligne. Le site web permettra d'automatiser les processus de gestion, de faciliter la
communication entre les membres du club, de gérer les inscriptions, de planifier les
événements et les activités du club, et de suivre les performances des membres du club.
L'objectif ultime est de créer une plateforme en ligne facile à utiliser qui améliore
l'expérience des membres du club universitaire et optimise la gestion du club.

2 Etude de l’existant
L'étude de l'existant consiste à auditer les solutions existantes pour s’inspirer et pour raffiner
de plus l’idée immergeant.

2.1 Solutions existantes

2.1.1 La nouvelle version de site Web d’isimm

8
 Figure 1: Page de connexion du site «Isimm »

Le nouveau Site Web d’isimm est un site officiel amélioré sur le coté design des
interfaces de l’institut d’informatique et de mathématiques de Monastir et une
plateforme en ligne complète pour les étudiants, les enseignants et le personnel
administratif de la faculté. Les utilisateurs peuvent facilement naviguer sur le site pour
trouver les informations dont ils ont besoin, y compris les programmes de cours, les
horaires, les événements de la faculté, les nouvelles et les mises à jour importantes , il
offre à ces utilisateurs la possibilité de :

 Gérer leur profils personnels

 Voir leurs informations de contact
 consulter les programmes de cours et les horaires
 demander des renseignements sur les programmes de cours et les activités de la
faculté
 les étudiants peuvent voir leur notes

2.1.2 L’ancienne version de site web d’isimm

9
 Figure 2: L'ancien site web d'isimm

L’ancien site web d’isimm est un site officiel non amelioré sur le coté design des
interfaces de l’institut d’informatique et de mathématiques de Monastir et une
plateforme en ligne complète pour les étudiants, les enseignants et le personnel
administratif de la faculté. Les utilisateurs peuvent facilement naviguer sur le site pour
trouver les informations dont ils ont besoin, y compris les programmes de cours, les
horaires, les événements de la faculté, les nouvelles et les mises à jour importantes , il
offre à ces utilisateurs la possibilité de :

 Gérer leur profils personnels

 Voir leurs informations de contact
 consulter les programmes de cours et les horaires
 demander des renseignements sur les programmes de cours et les activités de la
faculté
 les étudiants peuvent voir leur notes

10
2.1.3 les interactions face à face et main à main

Figure 3 : les interactions entre les différents acteurs

Les interactions en face à face et les interactions directes entre les représentants des clubs,
les responsables de clubs et les membres de clubs sont essentielles pour une gestion efficace
des clubs au sein de la faculté. Les représentants des clubs et les responsables de clubs
peuvent facilement collaborer et travailler ensemble pour planifier des événements,
organiser des activités et coordonner les différentes initiatives du club. Ces interactions en
face à face peuvent aider à renforcer la cohésion et la collaboration entre les membres du
club et les responsables de clubs.

2.1.4 Tableau comparatif

Nous pouvons classer les résultats de l'analyse des solutions existantes mentionnées
précédemment, comme l’illustre le tableau 1.1, selon sept critères (Cx) pris en
considération dans le processus d'évaluation de ses solutions :
 C1 : La qualité du contenu: Le contenu doit être informatif, utile, facile à lire et à
comprendre, et régulièrement mis à jour. Il doit également être pertinent par rapport
aux objectifs du site.
 C2 : La convivialité: Le site doit être facile à utiliser et à naviguer, avec une structure
logique et intuitive. Les liens doivent fonctionner correctement et le temps de
chargement doit être rapide.
 C3 : La conception visuelle: Le site doit avoir un design attractif, professionnel et
cohérent avec l'image de marque de l'entreprise. Il doit également être adapté aux
différents types d'appareils et de navigateurs.

11
  C4 : La sécurité: Le site doit être protégé contre les attaques malveillantes et les
menaces potentielles. Les données des utilisateurs doivent être stockées de manière
sécurisée.
 C5 : La performance: Le site doit être rapide, fiable et résistant aux pannes. Il doit
également être optimisé pour les moteurs de recherche (SEO).
 C6 : L'accessibilité: Le site doit être accessible à tous les utilisateurs, y compris ceux
qui ont des handicaps ou des besoins spécifiques. Il doit également respecter les
normes d'accessibilité du Web.
 C7 : Les fonctionnalités: Le site doit offrir des fonctionnalités et des outils utiles pour
les utilisateurs, tels que des formulaires de contact, des boutons de partage social,
etc.

Critéres Le nouveau site web L’ancien site web d’isimm

d’isimm
La qualité du contenu Oui oui
La convivialité Oui non
La conception visuelle Oui non
La sécurité Non non
La performance Non non
L'accessibilité Non non
Les fonctionnalités Oui oui
Table 1.1 : Tableau comparatif entre les solutions existantes

2.2 Critique de l’existant

Chaque solution existante mentionnée précédemment ne donne pas l'opportunité aux
acteurs l’opportunité de consulter et gérer toutes les activités des clubs au seins de l’institut,
hors les sites web qui déjà existes ne comportent pas un espace concerné pour les clubs ,
d’où la gestion de club devient plus et plus complexé et difficiles.

2.3 Travail à réaliser

Il est crucial de fournir une plateforme en ligne qui facilite la gestion des clubs pour les
étudiants, les responsables de club et les représentants de club. Notre solution innovante
permettra d'optimiser la gestion de projet en automatisant les tâches administratives
fastidieuses. Voici les principales fonctionnalités que notre plateforme doit offrir :

Pour les étudiants :

 La création de leur profil et la mise à jour de leurs informations personnelles.

 Une inscription facile pour les clubs disponibles. Il suffit de suivre les instructions et
de remplir soigneusement les formulaires et les demandes.
 La possibilité de s'inscrire à des événements organisés par les clubs, de gérer leur
calendrier personnel et de recevoir des notifications pour ne rien manquer.
 La communication instantanée avec les responsables de club et les autres membres.

12
Pour les responsables de club :

 Faciliter le contact entre l’établissement, les clubs et les étudiants

 La possibilité de gérer plusieurs clubs en même temps.
 La création et la gestion de calendriers pour chaque club et chaque événement.
 La gestion de l'adhésion et la communication avec les membres.
 La gestion financière, y compris la collecte des cotisations, la création de rapports
financiers et la gestion des dépenses.
 La communication en temps réel avec les responsables de club et les membres.

Pour les représentants de club :

 La gestion des membres et leur adhésion.

 La création et la planification d'événements, la gestion des présences et des absences
et la communication en temps réel avec les membres.
 La gestion financière du club, y compris la collecte de cotisations, le suivi des
dépenses et la création de rapports financiers.
 La possibilité de personnaliser le site web du club avec des informations et des
photos.

3 Méthodologie de travail
Avant de réaliser chaque projet, il est nécessaire de choisir une méthodologie de travail afin
d’aboutir à un logiciel fiable, adaptable et efficace. Et pour pouvoir choisir la méthodologie la
plus adéquate nous avons procédé à une comparaison entre la méthode 2Tup et la méthode
agile Scrum

3.1 Méthode 2TUP

Two Tracks Unified La méthode 2 Tracks Unifed est un processus de développement logiciel
qui met en œuvre la méthode du processus unifié (c'est-à-dire construit sur UML, itératif,
centré sur l'architecture et conduit par les cas d'utilisation). Le 2TUP propose un cycle de
développement en Y, qui dissocie les aspects techniques des aspects fonctionnels. Il
commence par une étude préliminaire qui consiste essentiellement à identifier les acteurs
qui vont interagir avec le système à construire, les messages qu'échangent les acteurs et le
système, à produire le cahier de charges et à modéliser le contexte. Le processus s'articule
ensuite autour de trois phases essentielles comme indique la figure 3 :

 Une branche fonctionnelle : elle capitalise la connaissance du métier de l’entreprise.

Cette branche capture des besoins fonctionnels, ce qui produit un modèle focalisé
sur le métier des utilisateurs finaux.
 Une branche technique : capitalise un savoir-faire technique et/ou des contraintes
techniques. Les techniques développées pour le système sont indépendamment des
fonctions à réaliser.

13
  Une phase de réalisation : elle consiste à réunir les deux branches, permettant de
mener une conception applicative et enfin la livraison d'une solution adaptée aux
besoins

Figure 4: Représentation de la méthodologie 2TUP

3.2 Méthode agile Scrum

La méthode agile Scrum, illustrée par la figure 5, se base sur le découpage du projet en itérations
nommées sprints qui se succèdent et durent de 2 à 4 semaines. Chaque itération commence par une
réunion de planification appelée « Sprint planning » pour définir son objectif et décomposer chaque
besoin en plusieurs tâches. Le sprint se termine par une démonstration de ce qui a été réalisé, pour
l’évaluer et le valider. Le but de cette méthode est de produire la plus grande valeur métier dans la
durée la plus courte. Lorsque nous disons Scrum, il faut comprendre les mots concepts suivants :

 Responsable Produit (Product Owner) : Il représente les clients et les utilisateurs et

détermine ce qui doit être réalisé.
 Scrum Master : Le responsable du déroulement du processus. Il gére efficacement le
carnet du produit et il garantit la motivation de l'équipe et l'efficacité de la
collaboration entre les membres.
 Équipe projet : L'équipe de développement s'organise elle-même pour déterminer la
meilleure façon de produire les exigences les plus prioritaires, son rôle principal est
de livrer un incrément, une version du logiciel, à la fin de chaque Sprint.
 User story : C’est l’histoire utilisateur décrivant un besoin fonctionnel désiré par le
client.
14
  Backlog du produit : Besoins priorisés par le product owner et estimés par l’équipe,
qui évoluent et sont affinés.
 Sprint : Un Sprint est une itération. Il s'agit d'une période de 2 à 4 semaines
maximum pendant laquelle une version terminée et utilisable du produit est réalisée.
Chaque sprint a un objectif et une liste de fonctionnalités à réaliser.
 Backlog du sprint : Une sélection de tâches retenues du « Backlog du produit » pour
construire l'objectif du sprint.
 Daily Meeting : C'est une réunion quotidienne qui permet de mettre le point sur ce
qui a été réalisé, les problèmes rencontrés et les objectifs de la journée
 Démonstration du sprint : Nommé aussi « Sprint Review ». C'est une réunion programmée
à la fin de chaque sprint durant laquelle l'équipe de projet présente le travail réalisé pour
l’évaluer et le valider

Figure 5:Représentation de la méthodologie SCRUM

3.3 Méthodologie adoptée

Nous avons décidé d’adopter le processus 2TUP pour la suite de notre travail car il respecte le cadre
de notre projet qui est basé sur un processus de développement bien défini qui commence par la
détermination des besoins fonctionnels du système jusqu'à la conception et l’implémentation ainsi
qu’il correspond à l’envergure et la durée de notre projet.

4 Diagramme de Gantt

Le diagramme de Gantt est un outil utilisé en ordonnancement et en gestion de projet qui

permet de visualiser dans le temps les diverses tâches qui composent un projet. La figure 6

15
 Figure 6: Diagramme de Gantt

5 Conclusion
En guise de conclusion, dans ce chapitre nous avons mis notre projet dans son cadre général.
Ensuite, nous avons étudié les solutions existantes et proposé notre propre solution. Enfin,
nous avons clôturé par la méthodologie de développement que nous avons adoptée. Dans le
chapitre suivant nous allons spécifier les différents besoins auxquels doit répondre notre
application.

16
CHAPITRE II

SPÉCIFICATION DES BESOINS

1 Introduction
L’étape d’analyse et spécification des besoins est une étape indispensable pour comprendre
les fonctionnalités essentielles que le système doit fournir. Dans ce chapitre nous
présenterons les exigences fonctionnelles et non fonctionnelles associées à ces
fonctionnalités ainsi que les acteurs concernés par ce système. Le diagramme de contexte,
les diagrammes de cas d'utilisation et les diagrammes de séquence sont des outils précieux
pour aider à identifier ces besoins et à les exprimer clairement et efficacement.

2 Identification des acteurs

Un acteur est une entité externe qui définit le rôle joué par un utilisateur, humain ou non
humain, qui interagit avec un système interactif, et il est essentiel de les identifier avec
précision afin de comprendre les interactions et les exigences de chacun.

Notre système comporte les acteurs suivants :

 Les représentants des clubs : Ce sont les secrétaires générales des clubs, ils
représentent leurs clubs dans le système de gestion des clubs. Ils auront accès au
système pour créer et gérer les événements et les activités de leur club, ainsi que
pour communiquer avec le responsable de clubs.

 Le responsable de clubs : C'est la personne chargée de superviser et de gérer les

différents clubs de l'établissement. Il aura accès au système pour valider et
approuver les événements et les activités proposées par les représentants des clubs,
ainsi que pour fournir un soutien et des conseils aux clubs.

 Les étudiants : Ce sont les membres qui auront accès au système pour consulter et
participer aux événements et activités proposés par les clubs, ainsi que pour écrire
leurs feedbacks concernant ces événements.

3 Modèle de contexte du système informatisé

Dans cette partie, nous allons présenter le modèle de contexte du système informatisé, qui
permettra de visualiser l'environnement dans lequel le système va interagir.

17
3.1 Diagramme de contexte
La Figure 7 montre le diagramme de contexte du système informatisé et identifie les
différentes interactions entre le système et son environnement.

Figure 7: Diagramme de contexte

4 Capture des besoins

4.1 Capture des besoins fonctionnels

Les besoins fonctionnels décrivent les fonctionnalités et les services que le système doit
fournir pour répondre aux besoins des utilisateurs.

L’application doit permettre au représentant du club de :

 S’authentifier : Après avoir l’accès, le représentant du club saisit son login et son mot
de passe pour accéder à la plateforme.

 Gérer les activités du club : Le représentant du club doit pouvoir créer, modifier et
supprimer des activités pour le club, ainsi que les planifier, les organiser et les
promouvoir.

18
  Consulter les annonces : Le représentant du club doit pouvoir consulter les annonces
et les diffuser auprès des membres du club.

 Gérer une demande d'événement : Le représentant du club doit pouvoir créer et

déposer les demandes d’événements ainsi que les supprimer.

 Ajouter une réclamation : Le représentant du club doit pouvoir créer une

réclamation pour signaler un problème concernant le club, les événements, les
ressources, etc.

 Consulter feedbacks : Le représentant du club doit pouvoir consulter les feedbacks

laissés par les étudiants sur les activités et événements organisés par le club.

L’application doit permettre au responsable des clubs de :

 Gérer l’accès : Le responsable des clubs doit pouvoir gérer les autorisations d'accès
des différents acteurs du système, en créant et en supprimant des comptes, en
assignant des rôles et en définissant les niveaux d'accès.

 Gérer les finances : Le responsable des clubs doit pouvoir suivre les finances, en
générant des rapports financiers sur les clubs, les événements et les activités en
cours.

 Contrôler les activités des clubs : Le responsable des clubs doit pouvoir contrôler les
activités des clubs, en s'assurant qu'ils respectent les règles et les normes de
l'établissement, et en prenant des mesures si nécessaire.

 Poster des événements sur la plateforme : Le responsable des clubs doit pouvoir
publier des événements sur la plateforme pour que les étudiants puissent les
consulter et s'y inscrire.

 Gérer les demandes d'événements : Le responsable des clubs doit pouvoir gérer les
demandes d'événements des différents clubs, en les validant ou en les rejetant, et en
les planifiant sur le calendrier de l'établissement si nécessaire.
L’application doit permettre à l’étudiant de :

 Consulter les événements des clubs : Les étudiants doivent pouvoir consulter les
événements proposés par les clubs, en filtrant par catégorie, date, club, etc.

 Participer à un événement : Les étudiants doivent pouvoir s'inscrire et participer aux

événements proposés par les clubs.

19
  Ajouter un feedback : Les étudiants doivent pouvoir ajouter un feedback sur les
événements auxquels ils ont participé, en évaluant leur expérience, en laissant des
commentaires, etc.

4.2 Capture des besoins non fonctionnels

Les besoins non-fonctionnels ont comme but de décrire les conditions requises qui
permettent d’assurer le bon fonctionnement du système et optimiser les services qu’il
fournit vis-à-vis l’utilisateur. Notre application doit répondre aux critères suivants :

 La fiabilité : la capacité du système à fonctionner de manière fiable sans erreurs

ni pannes.
 Performance : le système doit être performant et répondre rapidement aux
requêtes des utilisateurs, même en cas de charges élevées.
 La sécurité : la capacité du système à protéger les données sensibles des
membres et les informations financières du club.
 La facilité d'utilisation : la capacité du système à être facile à comprendre et à
utiliser pour les membres et les responsables des clubs.
 La flexibilité : la capacité du système à être modifié et adapté aux besoins
changeants du club.
 La qualité de l'interface utilisateur : l'expérience de navigation et de
manipulation du système doit être optimale pour l’utilisateur.

5 Spécification des besoins fonctionnels

Cette partie consiste à comprendre le contexte du système. Il s'agit de déterminer les
fonctionnalités et les acteurs les plus pertinents ainsi qu’'identifier les cas d’utilisation.

5.1 Diagramme de cas d’utilisation général

La figure 8 illustre le diagramme de cas d'utilisation général de notre système.

20
Figure 8:Diagramme de cas d'utilisation général

21
6 Diagrammes de cas d’utilisation détaillés

6.1 Diagramme de cas d’utilisation détaillé de l’acteur « Représentant du club »

La figure 9 illustre les fonctionnalités à fournir à l’acteur « Représentant du club » après
l’authentification. Un Représentant du club peut gérer les activités du club et les demandes,
il peut consulter les annonces et les feedbacks et peut déposer les actualités de son club. Il a
aussi la possibilité d'ajouter des réclamations.

Figure 9: Diagramme de cas d'utilisation de l'acteur « Représentant du club »

6.2 Diagramme de cas d’utilisation détaillé de l’acteur « Responsable des clubs »

La figure 10 illustre les fonctionnalités à fournir à l’acteur « Responsable des clubs » après
l’authentification. Il peut gérer les autorisations d’accès, les finances, contrôler les activités
des clubs, poster des événements sur la plateforme et gérer les demandes d'événements
des différents clubs en les validant ou en les rejetant.

22
 Figure 10: Diagramme de cas d'utilisation de l'acteur « Responsable des clubs »

6.3 Diagramme de cas d’utilisation détaillé de l’acteur « Etudiant »

La figure 11 illustre les fonctionnalités à fournir à l’acteur « Etudiant » après
l’authentification. Un Etudiant peut consulter les événements proposés par les clubs,
s’inscrire et participer à ces événements. Il a aussi la possibilité de donner un feedback pour
aider à améliorer les futurs événements.

23
 Figure 11: Diagramme de cas d'utilisation de l’acteur « Etudiant »

7 Diagrammes de séquence acteur-système

Les diagrammes de séquences permettent de modéliser les interactions entre les différents
éléments du système et les acteurs, en montrant l'ordre chronologique des messages
échangés entre eux. Cela permet de comprendre comment le système fonctionne et
comment les différentes parties interagissent entre elles.

7.1 Diagramme de séquence « gestion d’une demande »

Le tableau 2.1 et la figure 12 décrivent le diagramme de séquence « gestion d’une demande
».

Table 2.1 : Description du C.U « gestion d’une demande »

Cas d’utilisation Gestion d’une demande

Acteur Représentant du club

But Permettre au représentant du club de soumettre une demande

d'événement pour son club, en fournissant les informations
nécessaires sur l'événement.
Précondition Le représentant du club doit être authentifié dans le système et
avoir les autorisations nécessaires pour soumettre une demande

24
 d'événement.

Scénario nominal Soumettre une demande :

-Le représentant du club accède à la fonctionnalité de soumission
de demande d'événement dans le système.
-Le système affiche le formulaire de demande d'événement, qui
contient les champs suivants : nom de l'événement, date et heure
de l'événement, etc.
-Le représentant du club remplit les champs du formulaire avec les
informations sur l'événement.
-Le représentant du club soumet la demande d'événement.
-Le système enregistre la demande d'événement dans la base de
données et notifie le représentant du club de la réception de la
demande.
-Le responsable des clubs peut accéder à la demande d'événement
et l'approuver, la rejeter ou la reporter.
Annuler la demande :
- Le représentant ouvre la page de demandes dans le système.
- Le système affiche la liste de toutes les demandes soumises.
- Le représentant choisit la demande et l’annule.

Post condition La demande d'événement est enregistrée et peut être consultée

par le responsable des clubs pour validation.

Exception -Le système détecte des informations manquantes ou incorrectes

dans la demande et affiche un message d'erreur indiquant les
champs à corriger.
-Le représentant du club corrige les champs en question et soumet
à nouveau la demande.
-Le système vérifie que la demande ne contient plus d'informations
manquantes ou incorrectes, puis l'enregistre.

25
 Figure 12: diagramme de séquence « gestion d’une demande »

7.2 Diagramme de séquence « consulter feedbacks »

Le tableau 2.2 et la figure 13 décrivent le diagramme de séquence « consulter feedbacks ».

Table 2.2 : Description du C.U « consulter feedbacks »

Cas d’utilisation Consulter feedbacks

Acteur Représentant du club

But Permettre au représentant du club de consulter les

feedbacks laissés par les étudiants sur les événements
auxquels ils ont participé, afin d'améliorer les événements
futurs et de mieux comprendre les besoins des étudiants.

Précondition Le représentant du club doit être authentifié dans le

système

26
Scénario nominal -Le représentant du club accède à la fonctionnalité de
consultation des feedbacks dans le système.
-Le système affiche la liste des événements organisés par le
club.
-Le représentant du club sélectionne un événement pour
consulter ses feedbacks.
-Le système affiche la liste des feedbacks laissés par les
étudiants pour l'événement sélectionné.
-Le représentant du club peut lire les feedbacks pour
évaluer l'expérience des étudiants lors de l'événement.

Postcondition Le représentant du club a consulté les feedbacks des

événements organisés par le club.

Exception Si le représentant du club n'est pas authentifié dans le

système, il ne peut pas accéder à la fonctionnalité de
consultation des feedbacks. Le système affiche un message
d'erreur et redirige le représentant du club vers la page
d'authentification.

27
 Figure 13: diagramme de séquence « consulter les feedbacks »

7.3 Diagramme de séquence « donner le droit d'accès à un club »

Le tableau 2.4 et la figure 14 décrivent le diagramme de séquence « donner le droit d’accès à
un club ».

Table 2.4 : Description du C.U « donner le droit d’accès à un club »

Cas d’utilisation Donner le droit d’accès à un club

Acteur Responsable de clubs

But Permettre au responsable de club d'accorder une

autorisation d'accès à un club
Précondition -Le responsable des clubs doit être authentifié dans le
système.
-Le club pour lequel le droit d'accès est accordé doit être
enregistré dans le système.
Scénario nominal -Le responsable des clubs accède à la fonctionnalité de
gestion des droits d'accès dans le système.
-Le système affiche la liste des clubs disponibles.
28
 -Le responsable des clubs sélectionne le club pour lequel il
souhaite donner le droit d'accès.
-Le système affiche la liste des rôles disponibles pour le club.
-Le responsable des clubs sélectionne le rôle approprié pour
le club.
-Le système enregistre les modifications et notifie le
représentant du club de l'attribution du droit d'accès.
Postcondition -Le représentant du club dispose du droit d'accès
sélectionné avec le rôle approprié.
Exception -Si le club n'existe pas dans la base de données, le système
affiche un message d'erreur indiquant que le club est
introuvable.

Figure 14: diagramme de séquence « donner le droit d’accès à un club »

7.4 Diagramme de séquence « rechercher des évènements par catégorie »

Le tableau 2.5 et la figure 15 décrivent le diagramme de séquence « Rechercher des
évènements par catégorie ».

Table 2.5 : Description du C.U « Rechercher des évènements par catégorie »

29
Cas d’utilisation Rechercher des évènements par catégorie

Acteur Étudiant

But Permettre à l'étudiant de rechercher des

événements en fonction de leur catégorie
d'intérêt

Précondition L'étudiant doit être authentifié à la

plateforme
Scénario nominal
-L'étudiant accède à la page de recherche
d'événements.
-Le système affiche les catégories
d’évènements.
-L'étudiant sélectionne la catégorie
d'événements qui l'intéresse.
-La plateforme affiche les événements
correspondants à la catégorie sélectionnée.

Post condition L'étudiant a la possibilité de s'inscrire à un

événement qui l'intéresse en fonction de la
catégorie d'événements sélectionnée.

Exception Si aucun événement ne correspond à la

catégorie sélectionnée, le système peut
afficher un message indiquant qu'il n'y a pas
d'événement correspondant.

30
 Figure 15: diagramme de séquence « Rechercher des évènements par catégorie »

8 Choix technique
Pour le coté front-end nous allons utiliser le framework Bootstrap et le framework Laravel
pour le coté back-end.

8.1 Framework Bootstrap

Bootstrap est un framework open-source élaboré par Mark Otto et Jacob Thorton depuis
2010, qui fournit des composants HTML, CSS et JavaScript préconçus pour faciliter la
conception de pages web réactives et mobiles.

Nous avons opté pour la framework Bootstrap pour les raisons suivantes :

 Flexibilité : Bootstrap propose une grande variété de composants, tels que des
boutons, des formulaires, des modales, etc., qui peuvent être facilement
personnalisés pour répondre aux besoins du projet.

 Performance : Bootstrap est léger et rapide, avec une taille de fichier minifiée et
compressée qui permet de réduire le temps de chargement des pages web.

31
  Documentation : Bootstrap est largement documenté et dispose d'une grande
communauté de développeurs qui contribuent régulièrement à son amélioration et à
son support.

8.2 Framework Laravel

Laravel est un framework web open-source basé sur PHP, créé par Taylor Otwell depuis
2011, qui permet de développer des applications web de manière rapide, efficace et
sécurisée. Il est conçu pour faciliter les tâches telles que l'authentification, la gestion des
sessions, la validation des données et la création de migrations de base de données, entre
autres.

Nous avons opté pour la framework Laravel pour les raisons suivantes :

 Documentation complète : Laravel dispose d'une documentation complète et d'une

communauté active, ce qui facilite l'apprentissage et la résolution des problèmes.

 Sécurité : Laravel est l’un des frameworks les plus robustes et sécurisés.

 Nombreuses fonctionnalités : Laravel offre de nombreuses fonctionnalités, telles que

l'authentification, la gestion des sessions, la validation des données, les migrations de
base de données, etc., ce qui facilite le développement d'applications web robustes
et évolutives

 Intégration avec d'autres technologies : Laravel peut être facilement intégré avec
d'autres technologies, telles que JavaScript, Vue.js, React, etc., ce qui permet de
créer des applications web modernes et interactives.

9 Conclusion
Dans ce chapitre, nous avons identifié les acteurs et les besoins fonctionnels et non
fonctionnels pour notre système. Puis, nous avons présenté et détaillé les différents cas
d’utilisation. Et enfin nous avons présenté quelques diagrammes de séquences acteur-
système. Le troisième chapitre sera consacré à la conception de notre application.

32
CHAPITRE III

ANALYSE ET CONCEPTION

1 Introduction :

Ce chapitre marque une étape cruciale dans le développement de notre application ou

nous établirons un lien entre la phase de spécification et la phase de réalisation .Nous
débuterons en présentant l’architecture globale de l’application ,puis aborderons en
présentant l’architecture globale de l’application ,puis aborderons la conception générale et
détaillée en utilisant des diagrammes de classes pour représenter les vues statiques. Enfin,
nous conclurons ce chapitre en présentant quelques fonctionnalités de l’application a l’aide
de maquettes.

2 Modèle architectural

Après avoir fait le choix de la méthodologie 2TUP, la démarche de conception sera en

adéquation avec l'architecture de site web .

Avant de développer notre site web , il est indispensable de choisir un modèle de conception
(pattern design). Parmi les patrons les plus connues, nous mentionnons l’architecture 3-tiers
et le patron Modèle-Vue-Contrôleur (MVC).

2.1 L’architecture 3-tiers

Ce modèle d’architecture, décrit par la figure se décompose en trois niveaux logiques bien
distincts qui ont chacune un rôle bien défini :

 La couche de présentation correspond à l’interface utilisateur. Son rôle est d’afficher

les données et de permettre à l’utilisateur final d’interagir avec ces dernières.
 La couche métier est en charge d’appliquer et de respecter les règles métiers (ou
actes de gestion). Avec ce modèle d’architecture, la logique applicative et la sécurité
sont implémentées dans cette couche.
 La couche d’accès aux données, quant à elle, assure la persistance des données qui
doivent être conservées.

33
 Figure 16: L’architecture 3-tiers

2.2 Modèle MVC

L’architecture MVC organise l’interface graphique d’un programme en trois entités

distinctes : le modèle, la vue et le contrôleur, chacun entités distinctes : le modèle ,la vue et
le contrôleur ,chacun ayant un rôle précis. La figure 18 illustre cette architecture .

Dans l'architecture MVC, les rôles des trois entités sont les suivants :

 Le modèle : il gère les données de site, son rôle est de récupérer les informations
dans la base de données, de les organiser et de les assembler pour qu'elles puissent
ensuite être traitées par le contrôleur
 La vue : elle représente l’interface utilisateur, sa première tâche est d'afficher les
données qu'elle a récupérées auprès du modèle. Sa seconde tâche est de recevoir
toutes les actions de l'utilisateur. Ses différents événements sont envoyés au
contrôleur.
 Le contrôleur : cette partie est chargée de la synchronisation du modèle et de la vue.
C'est en quelque sorte l'intermédiaire entre le modèle et la vue : le contrôleur
demande au modèle les données, les analyser, prendre des décisions et finalement
les déléguer à la vue.

Figure 17: L'architecture du modèle MVC

34
2.2.1 Diagramme de séquence MVC :

Figure 18: Diagramme de séquence MVC de représentant de club

2.3 Architecture adoptée

L'architecture générale de notre application s'inspire de l'architecture 3-tier. Elle est illustrée
par la figure 19

Figure 19: L'architecture de notre site Web

Le front-end représenté la partie visuelle de l’architecture en 3-tiers. Cette partie est

composée de deux couches distinctes : la couche « vue » qui représente les interfaces
graphiques utilisées par l’utilisateur pour interagir avec le système ,et la couche « Service »
qui organise les traitements et assure l’interaction avec le serveur.

Le back-end correspond à la partie métier et accès aux données de l’architecture en 3- tiers.

La première partie est constituée de deux couches : la couche « Routing » qui redirige les

35
demandes vers les contrôleurs appropriés et la couche « Controller » qui reçoit tous les
événements de l'utilisateur et declenche les actions à effectuer. Quant à la deuxième partie
elle se compose d’une seule couche :la couche « model » qui représente les entités métiers
gérés par notre application.

3 Conception de la base de données

La création d’une base de donnés implique de structurer les données en fonction d’un
modèle ,permettant ainsi de définir la manière sont elles seront stockées et reliées entre
elles . Ainsi, il est courant de commencer par élaborer un modèle conceptuel de données
(MCD),suivi d’un modèle logique de données (MLD).

3.1 Modèle conceptuel de données (MCD)

Un MCD décrit les différentes entités ainsi que les relations qui existent entre elles. La figure
20 illustre le modèle conceptuel de notre base de données. Le tableau 3.1 donne les détails
de description de chaque entité.

Figure 20: Modèle Conceptuel de données (MCD)

Entités Description Attributs et type

utilisateur Tout utilisateur de la plateforme Id_U :int

36
 Email :string

MDP :string

membre Les membre atteindre des Id_M : Int

évènements
Nom Membre :string

Prenom_Membre :string

Email Membre :string

Représentant Il hérite de la classe (utilisateur) Id_R : int

du clubs et contient les attributs
Nom : string
supplémentaires relatives au
utilisateur Prénom : string

Tel :Int

club Les évènements appartient a un Id :Int

club
Nom club :string

Date -affiche :Date

Évènement Il sont Gérés par le représentant Id :Int

du club
Titre :string
Chaque évènements appartient a
Localisation :string
un club
Img :string

Prix :float

Nb_place :Int

demande Les demandes sont gérer par le Id_d :Int

représentant du club
Nom :string

Prénom :string

Date :date

Feed-back Le membre peut également Nom :string

fournir des commentaires
Prénom :string

37
 Contenu :string

Date :date

profil Consiste a associer les données Id PR :Int

d’un représentant de club a celles
d’un profil

Table 3.1 : Les entités du modèle conceptuel de données

3.2 Modèle Logique de données (MLD)

Un modèle MCD peut être organisé selon différents modèles logiques de données. Dans
notre projet, nous avons opté pour le modèle relationnel qui répond bien à nos besoins non
fonctionnels.

En appliquant les règles de transformations du modèle E/A vers un modèle relationnel, nous
obtenons le schéma relationnel suivant, illustré dans la figure 21 Nous distinguons 9
relations du modèle conceptuel :

Representant de club (id_R ,nom_R , prenom_R, tel_R, Email_R, mdp_R, id_E#)

Utilisateur (id_U, Email_U,mdp_U)

Evenement (id_E, titre, localisation,img, prix, nb_place,#id-C)

Feedback ( nom, prenom, contenu, date,id_M#)

Club (id_C, nom_club,date_affiche)

Membre (id_M,nom_M,prenom_M,email_M,id_E#)

Demande (id_D, nom, prenom, Date)

Profil (id_P)

Attendre (#id_M, #id_E)

38
 Figure 21: Le Modèle Logique de Données

4 Conception logicielle détaillée

Dans la conception logicielle détaillée ,nous présenterons deux types de visualisation pour
mieux comprendre le fonctionnement du logiciel : une vue statique avec le diagramme de
classes , montrant les différentes classes et leurs relations ,et une vue dynamique avec le
diagramme de séquence , mettant en évidence les interactions et les flux entre les éléments
du logiciel .

4.1 Conception des interfaces graphiques

4.1.1 Maquettage :

Le maquettage est une étape indispensable, il permet de donne une idée sur le site et sur les
différentes interfaces sous forme de schéma. Dans ce qui suit, nous allons illustrer quelques
maquettes de notre application :

 Interface du cas d’utilisation « gestion des activités de club et « déposer les

actualités« de l’acteur représentant de club :

Cette interface du cas d’utilisation doit permettre a l’acteur de créer et publier des
actualités sur le site web .

39
 Interface du cas d’utilisation « gestion d’une demande pour l’acteur représentant
de club doit permettre a cet acteur de créer ,visualiser ,modifier et supprimer des
demandes pour son club.

40
41
Interface de cas d’utilisation « consulter feed-back pour l’acteur représentant de club doit
permettre a ce dernier de visualiser les retours de commentaires des membres du club sur
les activités et événements organisés.

42
43
 Interface de cas d’utilisation «Consulter les annoncements de l’établissement »de
l’acteur représentant de club doit permettre a ce dernier de visualiser les annonces
officielles et les informations importantes provenant de l’établissement auquel le
club est affilé .

 Interface de cas d’utilisation « ajouter une réclamation de l’acteur représentant de

club

 Interface de cas d’utilisation « ajouter un feed-back » de l’acteur étudient doit

permettre a ce dernier de soumettre un commentaire concernant les activités du
club .

44
Le feedback peut aider le club a s’améliorer et a mieux répondre aux besoins de la
communauté étudiante .

 Interface de cas d’utilisation « participer a un évènement» de l’acteur étudiant

Interface de cas d’utilisation « consulter les évènement »de club de l’acteur étudiant doit
permettre a ce dernier de visualiser les évènements organisés par le club . l’étudiant peut
ainsi s’informer sur les activités proposées et y participer

45
5 Conclusion :

Le chapitre présenté a couvert en détail les étapes clés de la conception de notre projet,
notamment l’architecture générale de l’application , la conception de la base de données via
le modèle conceptuel et relationnel , ainsi que la conception logicielle via des diagrammes
de classe et de séquence . Enfin, nous avons également discuté de la conception graphique
des interfaces utilisateur.

46
 CONCLUSION GÉNÉRALE
Notre projet de gestion des clubs universitaires sous forme d'un site web intitulé "Gestion
des clubs universitaires en ligne" a été mené avec succès en quatre mois. L'objectif de notre
projet était d'améliorer la gestion quotidienne des clubs universitaires et d'automatiser les
tâches du personnel.

Notre rapport comprend trois chapitres. Le premier chapitre présente le contexte général du
projet, où nous avons évalué les processus et les solutions informatiques existantes pour
identifier les points à améliorer. Nous avons également comparé différentes méthodologies
de gestion de projet et choisi la méthode agile pour mener à bien notre projet.

Le deuxième chapitre est consacré à l'analyse et la spécification des besoins fonctionnels et

non fonctionnels en utilisant des diagrammes de cas d'utilisation et des diagrammes de
séquence. Nous avons également justifié nos choix techniques pour l'implémentation de
notre application.

Le troisième chapitre détaille la conception de l'architecture du système, la conception de la

base de données, la conception logicielle détaillée, et les maquettes des interfaces de notre
application.

Ce projet nous a permis d'appliquer nos connaissances théoriques acquises tout au long de
notre parcours universitaire et de renforcer notre expérience pratique en matière de gestion
de projet et de développement web. Nous avons également développé nos compétences en
programmation et en utilisation d'outils informatiques.

Pour l'avenir, nous envisageons d'ajouter de nouvelles fonctionnalités pour compléter le site
web et de développer une version mobile pour une meilleure accessibilité. Nous espérons
que notre application permettra de simplifier la gestion des clubs universitaires et facilitera
la communication entre les membres des clubs.

47