Rapport du pfe (application Web de gestion des annonces scolaires)

Ce projet de fin d’études présente le développement d’une application Web de gestion des annonces au sein d’un établissement scolaire.

L’application permet aux professeurs de publier des annonces (emplois du temps, notes, événements), aux administrateurs de les valider et de gérer les départements, et aux étudiants/visiteurs de consulter en temps réel les informations pertinentes.

Technologies utilisées : Laravel (PHP), Blade, Bootstrap, MySQL, phpMyAdmin.

Objectifs principaux : améliorer la communication interne, garantir la fiabilité des informations, offrir une interface claire et assurer la traçabilité des annonces.

Réalisé par : Amine Oubouisk & Abderahman Ouazzani Chahidi.

Année académique : 2024-2025.

1. Projet de fin d’études
Filière :
Développement Web et Multimédia
Développement d’une application
Web
Application Web de gestion des annonces
Réalisé par :
Amine Oubouisk
Abderhaman Ouazzanie Chahidie
Encadré par :
Idriss Chana
Jury :
M. Idriss Chana
M. Morad Hajjii
Année académique : 2024-2025

2. Remerciements
Nous tenons à exprimer notre profonde gratitude à toutes les personnes qui ont contribué,
de près ou de loin, à la réalisation de ce projet de fin d’études intituléDéveloppement d’une
application Web de gestion des annonces.
Nos remerciements les plus sincères vont à notre encadrant,M. Driss Chana, pour sa
disponibilité, son accompagnement, ses conseils avisés et son soutien tout au long de ce
projet. Sa rigueur scientifique et ses qualités pédagogiques ont été déterminantes dans
notre avancement.
Nous remercions également l’ensemble des enseignants du programmeDéveloppement
Web et Multimédiapour la qualité de la formation dispensée, ainsi que l’administration
de l’établissement pour les conditions optimales mises à notre disposition durant notre
stage.
Ce projet a été un véritable travail d’équipe réalisé par nous,Amine Oubouisket
Abderhaman Ouazzanie Chahdiei, basé sur la collaboration, l’entraide et la complé-
mentarité de nos compétences. Cette expérience a été riche tant sur le plan technique que
personnel.
Remerciements d’Amine Oubouisk
Je tiens à remercier chaleureusement mon père et ma mère pour leur soutien indéfectible,
leur amour et leurs encouragements constants. Leur présence et leurs conseils ont été une
source de motivation inestimable tout au long de ce parcours.
Remerciements d’Abderhaman Ouazzanie Chahdie
Je souhaite exprimer toute ma reconnaissance à mon père et à ma mère pour leur com-
préhension, leur patience et leurs mots réconfortants. Grâce à eux, j’ai puisé la confiance
nécessaire pour mener à bien ce projet.
1

3. Résumé
Cette application Web a été développée pour améliorer la gestion des annonces au sein
d’un établissement scolaire, notamment pour les emplois du temps, les notes des étudiants
et les événements. Elle permet aux enseignants de publier rapidement des informations
importantes telles que les horaires de cours, les résultats d’examen et les activités à venir.
Chaque département peut gérer ses propres annonces de manière autonome, garantissant
une organisation claire et adaptée. Les annonces publiées sont validées par un adminis-
trateur avant d’être affichées sur un écran central accessible à tous les utilisateurs. Ce
processus de gestion des annonces assure une diffusion rapide, précise et sécurisée de
l’information à l’ensemble de la communauté scolaire.
L’objectif principal de cette application est de faciliter la communication et la gestion
efficace de l’information, permettant aux utilisateurs d’accéder en temps réel aux annonces
pertinentes.
Mots-clés :gestion des annonces, gestion des emplois du temps, application Web scolaire,
plateforme éducative, gestion des événements scolaires, système d’information scolaire,
accès en temps réel
2

4. Table des matières
Remerciements
Résumé 2
Liste des figures
Liste des abréviations
1 Introduction
1.1 Contexte général
1.2 Processus de développement
1.3 Objectifs du projet
1.4 Choix techniques
1.4.1 Backend
1.4.2 Frontend
1.4.3 Base de données
1.5 Organisation du rapport
2 Conception et architecture fonctionnelle
2.1 Analyse des besoins et spécifications
2.1.1 Objectifs de l’analyse
2.1.2 Acteurs et rôles
2.1.3 Cas d’usage principaux
2.1.4 Processus détaillés
2.1.5 Exigences fonctionnelles
3

5. TABLE DES MATIÈRES
2.1.6 Exigences non-fonctionnelles
2.1.7 Personas et scénarios d’usage Exemple
2.2 Conception et architecture fonctionnelle
2.2.1 Architecture générale
2.2.2 Modélisation des Données : MCD et MLD
2.2.3 Architecture de l’application
2.2.4 Vue visiteur publique
2.3 Outils de Modélisation Utilisés
Résumé du chapitre
3 Processus fonctionnel de l’application
3.1 Interfaces communes aux administrateurs et professeurs
3.1.1 Page d’accueil (Landing Page)
3.1.2 Page d’inscription (Register)
3.1.3 Page de connexion (Login)
3.2 Parcours de l’administrateur
3.2.1 Tableau de bord administrateur
3.2.2 Gestion des administrateurs
3.2.3 Gestion des professeurs
3.2.4 Ajout d’un professeur
3.2.5 Gestion des départements
3.2.6 Création d’un département
3.2.7 Gestion des plannings
3.2.8 Création d’un planning
3.2.9 Paramètres du profil administrateur
3.2.10 Gestion des annonces (vue administrateur)
3.3 Parcours du professeur
3.3.1 Tableau de bord du professeur
3.3.2 Création d’une annonce
3.3.3 Paramètres du profil
4

6. TABLE DES MATIÈRES
3.3.4 Gestion des annonces publiées
3.4 Parcours du visiteur
3.4.1 Consultation des annonces publiques par département
3.4.2 Consultation du planning public des événements
Résumé du chapitre
4 Conclusion Générale et Perspectives
4.1 Bilan des réalisations
4.1.1 Fonctions principales
4.2 Compétences et apprentissages
4.3 Perspectives d’évolution
4.3.1 Axes techniques
4.3.2 Axes fonctionnels
Mot de la fin
Webographie
5

7. Table des figures
1.1 Logo Laravel
1.2 composant Blade
1.3 Logo MySQL
2.1 Diagramme de cas d’usage
2.2 Diagramme de séquence global
2.3 Schéma d’architecture MVC (modèle conceptuel)
2.4 Modèle Conceptuel de Données (MCD) : entités, attributs et associations
2.5 Modèle Logique de Données (MLD) : tables relationnelles dérivées du MCD
2.6 d’architecture détaillée
2.7 Interface publique de consultation des annonces
2.8 Interface de PowerAMC
2.9 Interface de Enterprise Architect
3.1 Page d’accueil (Landing Page) de l’application
3.2 Page d’inscription pour les administrateurs et professeurs
3.3 Page de connexion à la plateforme (administrateur/professeur)
3.4 Tableau de bord administrateur
3.5 Gestion des comptes administrateurs
3.6 Gestion des comptes professeurs
3.7 Formulaire d’ajout d’un professeur
3.8 Gestion des départements
3.9 Formulaire de création d’un département
3.10 Gestion des plannings
6

8. TABLE DES FIGURES
3.11 Formulaire de création d’un planning
3.12 Page des paramètres du profil administrateur
3.13 Interface de gestion des annonces par l’administrateur
3.14 Tableau de bord personnalisé du professeur
3.15 Formulaire de création d’annonce
3.16 Page de gestion du profil professeur
3.17 Liste des annonces créées par le professeur
3.18 Interface de consultation des annonces publiques
3.19 Page du planning public des événements
7

9. Liste des abréviations
PHP Preprocesseur hypertexte
MVC Modèle-Vue-Contrôleur
CRUD Créer, Lire, Mettre à jour, Supprimer
ORM Mapping objet-relationnel
SQL Langage de requête structuré
MySQL Système de gestion de base de données relationnelle
Laravel Framework PHP basé sur MVC
npm Gestionnaire de paquets Node
—–
8

10. Chapitre 1
Introduction
9

11. CHAPITRE 1. INTRODUCTION
1.1
Aujourd’hui, la circulation de l’information au sein des établissements d’enseignement
peut être lente, fragmentée et peu lisible. Les enseignants, l’administration et les étudiants
ont besoin d’un canal unique et intuitif pour partager et consulter toutes les annonces
— qu’il s’agisse des horaires de cours, des résultats d’examen, ou des événements organi-
sés par l’école. Dans ce contexte, notre projet vise à créer une plateforme centralisée et
conviviale, adaptée aux besoins des établissements d’enseignement supérieur.
1.2
Le développement de cette application s’est articulé autour de trois grandes étapes :
1.Analyse des besoinsRencontre avec les enseignants, le service administratif et des
représentants d’étudiants pour recenser les attentes : rapidité de publication, clarté de
présentation, traçabilité des annonces.
2.Conception fonctionnelleÉlaboration des maquettes de l’interface et définition des
parcours utilisateurs :
—Parcours enseignantpour créer, modifier ou supprimer une annonce
—Parcours administrateurpour valider, archiver et organiser les départements
—Parcours visiteurpour consulter les annonces filtrées par filière ou par date
3.Déploiement et testsMise en ligne d’une version bêta auprès d’un groupe pilote,
suivi de retours d’usage, ajustements graphiques et validation finale avant lancement
officiel.
1.3
Le projet poursuit quatre objectifs principaux :
—Fluidifier la communicationRéduire le temps d’attente entre la saisie d’une an-
nonce et sa diffusion effective.
—Garantir la fiabilitéAssurer que chaque information soit validée par le service com-
pétent avant publication.
—Accroître la lisibilitéOffrir un affichage clair, avec des catégories et des filtres (par
département, par date) pour retrouver facilement l’annonce recherchée.
—Assurer la traçabilitéConserver un historique des annonces supprimées ou modi-
fiées, afin de pouvoir consulter l’historique complet des publications.
10

12. CHAPITRE 1. INTRODUCTION
1.4
Pour répondre aux besoins métier et non-fonctionnels de notre projet, nous avons choisi
une stack moderne et éprouvée.
1.4.1
—Framework :Laravel 9 (PHP 8.0+)
—Sécurité :protections CSRF, XSS et validation de toutes les entrées
—ORM :Eloquent avec migrations pour versionner la base de données
—Authentification :Laravel UI avec scaffold prêt à l’emploi
1.4.2
—Templating :Blade avec composants réutilisables
—Interactivité :JavaScript natif, Alpine.js pour le DOM, axios pour les appels AJAX
—Styles :Bootstrap CSS pour un design utilitaire et responsive
—Bundling :Laravel Mix (Webpack) ou Vite pour compiler et minifier les assets
1.4.3
—Système :MySQL avec phpMyAdmin pour la gestion de la base de données
Figure 1.1– Logo Laravel
11

13. CHAPITRE 1. INTRODUCTION
Figure 1.2– composant BladeFigure 1.3– Logo MySQL
1.5
Après cette introduction, le rapport se compose de cinq chapitres :
—Chapitre 2 :Conception : Analyse, besoins et architecture fonctionnelle
—Chapitre 3 :Processus fonctionnel de l’application
—Chapitre 4 :Conclusion et perspectives
Ainsi, ce premier chapitre pose le cadre de notre démarche et présente les grandes lignes
de l’application de gestion des annonces que nous proposons pour les établissements d’en-
seignement.
Résumé du chapitre
Ce premier chapitre introduit le contexte général du projet, qui vise à améliorer la com-
munication interne dans les établissements d’enseignement supérieur à travers une plate-
forme centralisée de gestion des annonces. Il décrit les étapes clés du développement —
de l’analyse des besoins à la mise en ligne — ainsi que les objectifs poursuivis : fluidité
de la communication, fiabilité, lisibilité et traçabilité. Les choix techniques sont détaillés,
incluant l’utilisation de Laravel pour le backend, Blade et Bootstrap pour le frontend,
ainsi que MySQL pour la base de données. Enfin, l’organisation du rapport est présentée,
annonçant les chapitres suivants sur la conception, le fonctionnement de l’application, et
les perspectives futures.
12

14. Chapitre 2
Conception et architecture
fonctionnelle
13

15. CHAPITRE 2. CONCEPTION ET ARCHITECTURE FONCTIONNELLE
2.1
2.1.1
Ce chapitre précise les besoins fonctionnels et non-fonctionnels de l’application, définit les
acteurs, décrit les cas d’usage clés et formalise les exigences détaillées avant la phase de
conception et de développement.
2.1.2
—Professeur
—
—
—Administrateur
—
—
—
—Visiteur / Étudiant
—
—
14

16. CHAPITRE 2. CONCEPTION ET ARCHITECTURE FONCTIONNELLE
2.1.3
Figure 2.1– Diagramme de cas d’usage
Inscription / ConnexionL’utilisateur s’enregistre (ou se connecte) via le formulaire
Laravel UI. Le rôle (prof/admin) est vérifié et oriente la redirection.
CU1 – Créer une annonceLe professeur saisit titre, contenu, département, dates, pièce
jointe et valide.
CU2 – Valider/Activer une annonceL’admin consulte les annonces en attente, clique
sur « Activer » ou « Désactiver » et confirme.
CU3 – Gérer les départementsL’admin ajoute, modifie ou supprime un département
via la page dédiée.
CU4 – Gérer les comptes professeursL’admin crée, édite ou supprime un compte
professeur.
CU5 – Consulter les annonces activesLe visiteur/étudiant affiche la liste des an-
nonces validées avec possibilité de filtrer.
15

17. CHAPITRE 2. CONCEPTION ET ARCHITECTURE FONCTIONNELLE
2.1.4
Figure 2.2– Diagramme de séquence global
16

18. CHAPITRE 2. CONCEPTION ET ARCHITECTURE FONCTIONNELLE
2.1.5
—Annonce
—
—
— active,désactivée.
—
—Département
—
—
—Utilisateur
—
— role:adminmiddleware).
2.1.6
—Performance
—
—
—
—Sécurité
—
—
—
—
—
—Accessibilité
—
—
—
—Maintenabilité
—
—
—
17

19. CHAPITRE 2. CONCEPTION ET ARCHITECTURE FONCTIONNELLE
2.1.7
Pour mieux comprendre les besoins des utilisateurs, nous avons établi trois personas prin-
cipaux :
—Mohammed, Professeur de mathématiques
—Besoin :Publier rapidement des changements d’horaires et des résultats d’exa-
mens.
—Contraintes :Peu de temps disponible, confort modéré avec le numérique.
—Scénario :Se connecte depuis son bureau, crée une annonce de report de cours
en 2 minutes, joint le nouveau planning PDF, voit immédiatement que le statut
est "en attente de validation".
—Fatima, Administratrice
—Besoin :Garantir la qualité et la pertinence des annonces publiées.
—Contraintes :Forte charge de travail, doit valider rapidement.
—Scénario :Reçoit une notification d’annonce en attente, consulte le contenu,
vérifie sa conformité, l’active ou demande des modifications à l’auteur via le
système de commentaires.
—Youssef,Étudiant
—Besoin :Consulter les annonces relatives à sa filière.
—Contraintes :Utilise principalement son smartphone, connexion parfois instable.
—Scénario :Consulte l’application mobile, filtre par département "Informatique",
trouve l’annonce sur l’examen final, télécharge le document préparatoire.
2.2
2.2.1
L’application est organisée selon le pattern MVC (Model–View–Controller) de Laravel 9,
complété par quelques services et middlewares pour la sécurité et la journalisation :
18

20. CHAPITRE 2. CONCEPTION ET ARCHITECTURE FONCTIONNELLE
Figure 2.3– Schéma d’architecture MVC (modèle conceptuel)
Les requêtes HTTP sont routées parroutes/web.phpvers lesControllers; ceux-ci or-
chestrent la logique métier, interagissent avec lesModelset renvoient uneViewBlade
ou une réponse JSON.
2.2.2
La modélisation des données repose sur deux niveaux complémentaires : le modèle concep-
tuel (MCD) et le modèle logique (MLD). Le MCD permet de représenter les entités métier,
leurs attributs et leurs relations sans se soucier des contraintes techniques. Il sert de base
à la création du MLD, qui précise la structure relationnelle de la base de données, les clés
primaires, étrangères, et les types de données.
Le tableau suivant présente un aperçu des principales entités identifiées dans notre base
de données, accompagnées de leurs attributs clés et des relations qu’elles entretiennent :
Représentations graphiques
Les figures ci-dessous illustrent les deux niveaux de modélisation de notre base de données :
19

21. CHAPITRE 2. CONCEPTION ET ARCHITECTURE FONCTIONNELLE
Figure 2.4– Modèle Conceptuel de Données (MCD) : entités, attributs et associationsFigure 2.5– Modèle Logique de Données (MLD) : tables relationnelles dérivées du MCD
20

22. CHAPITRE 2. CONCEPTION ET ARCHITECTURE FONCTIONNELLE
2.2.3
Figure 2.6– d’architecture détaillée
L’application est structurée en plusieurs composants qui interagissent ensemble :
—Module d’authentification
—
—
—
—Module de gestion des annonces
—
—Module d’administration
—
—
—
—Module de présentation publique
—
—
—
2.2.4
Pour illustrer l’expérience utilisateur, voici l’écran que voit un visiteur lorsqu’il consulte
les annonces selon son département :
21

23. CHAPITRE 2. CONCEPTION ET ARCHITECTURE FONCTIONNELLE
Figure 2.7– Interface publique de consultation des annonces
2.3
—PowerAMC : utilisé pour la modélisation des données (MCD, MLD, MPD).
—Enterprise Architect: utilisé pour la modélisation fonctionnelle (diagrammes de
cas d’utilisation, diagrammes de séquence).
Figure 2.8– Interface de PowerAMCFigure 2.9– Interface de Enterprise
Architect
22

24. CHAPITRE 2. CONCEPTION ET ARCHITECTURE FONCTIONNELLE
Résumé du chapitre
Ce chapitre détaille la phase de conception de l’application de gestion des annonces. Il
commence par l’analyse des besoins, identifiant les utilisateurs principaux (professeurs,
administrateurs, étudiants) et les cas d’usage essentiels. Les exigences fonctionnelles et
non-fonctionnelles sont ensuite formalisées, couvrant la performance, la sécurité, l’acces-
sibilité et la maintenabilité.
La modélisation s’appuie sur les diagrammes de cas d’usage, de séquence, ainsi que sur le
modèle conceptuel (MCD) et logique (MLD) de données. L’architecture logicielle repose
sur le modèle MVC de Laravel, avec des modules dédiés à l’authentification, la gestion
des annonces, l’administration et la présentation publique. Enfin, les outils utilisés pour
la modélisation (PowerAMC et Enterprise Architect) sont présentés pour illustrer les
schémas produits.
23

25. Chapitre 3
Processus fonctionnel de
l’application
24

26. CHAPITRE 3. PROCESSUS FONCTIONNEL DE L’APPLICATION
3.1
fesseurs
3.1.1
Figure 3.1– Page d’accueil (Landing Page) de l’application
La page d’accueil constitue le point d’entrée de la plateforme. Elle présente brièvement la
solution et permet à tous les utilisateurs d’accéder aux annonces publiques et au planning
sans authentification. Les administrateurs et professeurs peuvent également y accéder aux
boutons de connexion ou d’inscription selon leur profil.
3.1.2
Figure 3.2– Page d’inscription pour les administrateurs et professeurs
Cette interface est réservée aux professeurs et administrateurs. Elle leur permet de créer
un compte sur la plateforme en renseignant le nom, l’adresse e-mail, l’identifiant Prof
(pour les professeurs), le mot de passe et sa confirmation.
25

27. CHAPITRE 3. PROCESSUS FONCTIONNEL DE L’APPLICATION
3.1.3
Figure 3.3– Page de connexion à la plateforme (administrateur/professeur)
La page de connexion est destinée uniquement aux administrateurs et professeurs déjà
inscrits. Elle leur permet d’accéder à leur espace personnel sécurisé via leur adresse e-mail
et mot de passe.
3.2
3.2.1
Figure 3.4– Tableau de bord administrateur
Cette interface est le centre de contrôle principal pour l’administrateur. Elle offre une vue
d’ensemble des statistiques clés de l’application et fournit des accès rapides aux modules
de gestion. L’administrateur peut ainsi superviser et gérer efficacement les utilisateurs,
les départements, les plannings et les annonces.
26

28. CHAPITRE 3. PROCESSUS FONCTIONNEL DE L’APPLICATION
3.2.2
Figure 3.5– Gestion des comptes administrateurs
Cette interface permet à un super-administrateur de contrôler les comptes des autres ad-
ministrateurs de la plateforme. Il peut visualiser leurs profils, ajouter de nouveaux admi-
nistrateurs, modifier leurs informations ou privilèges, et supprimer des comptes existants,
assurant ainsi un contrôle granulaire de l’accès administratif.
3.2.3
Figure 3.6– Gestion des comptes professeurs
L’administrateur utilise cette interface pour gérer l’ensemble des comptes professeurs. Elle
présente une liste complète de tous les professeurs enregistrés, avec des options pour ajou-
ter de nouveaux profils, modifier les informations existantes (y compris le rattachement
de département) et supprimer les comptes qui ne sont plus nécessaires.
27

29. CHAPITRE 3. PROCESSUS FONCTIONNEL DE L’APPLICATION
3.2.4
Figure 3.7– Formulaire d’ajout d’un professeur
Ce formulaire est utilisé par l’administrateur pour créer de nouveaux comptes professeurs.
L’administrateur doit y renseigner des informations essentielles comme le nom du profes-
seur, son adresse e-mail, un identifiant unique (Identifiant Prof) et un mot de passe initial.
Cet identifiant est particulièrement important car il sera utilisé par le professeur lors de
sa propre inscription sur la plateforme.
3.2.5
Figure 3.8– Gestion des départements
Cette section permet à l’administrateur de structurer l’organisation interne de l’établis-
sement au sein de l’application. Il peut consulter la liste des départements déjà créés et
effectuer des opérations d’ajout de nouveaux départements, de modification des détails
des départements existants, ou de suppression si nécessaire.
28

30. CHAPITRE 3. PROCESSUS FONCTIONNEL DE L’APPLICATION
3.2.6
Figure 3.9– Formulaire de création d’un département
Ce formulaire simple est utilisé par l’administrateur pour ajouter un nouveau département
à la plateforme. Il suffit de saisir le nom du département. Les départements sont cruciaux
pour l’organisation et la classification des annonces et des plannings par entité spécifique.
29

31. CHAPITRE 3. PROCESSUS FONCTIONNEL DE L’APPLICATION
3.2.7
Figure 3.10– Gestion des plannings
Cette interface offre à l’administrateur une vue d’ensemble et des outils de gestion pour
tous les plannings créés sur la plateforme. Elle affiche les informations principales de
chaque planning, telles que le titre et la date, et permet à l’administrateur de modifier ou
de supprimer des plannings existants.
3.2.8
Figure 3.11– Formulaire de création d’un planning
L’administrateur utilise ce formulaire pour ajouter de nouveaux événements au calendrier
public de l’établissement. Il peut y renseigner des détails importants comme le titre de
30

32. CHAPITRE 3. PROCESSUS FONCTIONNEL DE L’APPLICATION
l’événement, les dates et heures précises, le lieu, et une description détaillée pour organiser
efficacement des cours, des conférences, des réunions ou tout autre événement pertinent.
3.2.9
Figure 3.12– Page des paramètres du profil administrateur
Cette page est dédiée à la gestion des informations personnelles du profil administrateur.
L’administrateur peut y mettre à jour son nom, son adresse e-mail, modifier son mot de
passe ou ajuster d’autres préférences liées à son compte pour maintenir ses informations
à jour et sécurisées.
3.2.10
Figure 3.13– Interface de gestion des annonces par l’administrateur
31

33. CHAPITRE 3. PROCESSUS FONCTIONNEL DE L’APPLICATION
Cette interface offre à l’administrateur une vue centralisée et complète de toutes les an-
nonces soumises par les professeurs. Il dispose de contrôles essentiels pour valider les
annonces afin de les rendre publiques, les désactiver temporairement si nécessaire, ou
les supprimer définitivement. Ce module est crucial pour la modération et la gestion du
contenu diffusé sur la plateforme.
3.3
3.3.1
Figure 3.14– Tableau de bord personnalisé du professeur
Après s’être connecté, le professeur accède à son tableau de bord personnel. Cette interface
affiche des statistiques pertinentes concernant ses propres annonces, comme le nombre
d’annonces publiées ou celles en attente de validation. Elle offre également des raccourcis
pratiques pour créer de nouvelles annonces ou pour gérer celles qui ont déjà été soumises.
32

34. CHAPITRE 3. PROCESSUS FONCTIONNEL DE L’APPLICATION
3.3.2
Figure 3.15– Formulaire de création d’annonce
Cette interface est spécifiquement dédiée aux professeurs pour la rédaction de leurs an-
nonces. Le professeur doit y renseigner tous les champs obligatoires, y compris le titre de
l’annonce, son contenu détaillé, ainsi que les dates de début et de fin de publication. Il
a également la possibilité d’ajouter une pièce jointe, comme un document ou une image,
pour enrichir le contenu de son annonce.
3.3.3
Figure 3.16– Page de gestion du profil professeur
Le professeur peut accéder à cette page pour gérer et modifier ses informations person-
nelles. Il peut y mettre à jour son nom, son adresse e-mail, changer son mot de passe,
33

35. CHAPITRE 3. PROCESSUS FONCTIONNEL DE L’APPLICATION
ou télécharger une photo de profil. Cette page lui permet de maintenir ses informations à
jour et personnalisées.
3.3.4
Figure 3.17– Liste des annonces créées par le professeur
Cette page affiche un récapitulatif de toutes les annonces que le professeur a soumises.
Pour chaque annonce listée, le professeur dispose d’options pour en visualiser les détails
complets, la modifier pour apporter des corrections ou des mises à jour, ou la supprimer
si elle n’est plus pertinente.
3.4
L’application permet aux visiteurs (utilisateurs non connectés) de consulter certaines
informations publiques essentielles, offrant une transparence sur les activités de l’établis-
sement.
34

36. CHAPITRE 3. PROCESSUS FONCTIONNEL DE L’APPLICATION
3.4.1
Figure 3.18– Interface de consultation des annonces publiques
Accessible directement depuis la page d’accueil, cette interface permet aux visiteurs de
naviguer et de consulter toutes les annonces qui ont été validées par l’administrateur.
Les annonces sont organisées et affichées par département. Les visiteurs ont également
la possibilité de les filtrer selon des critères spécifiques tels que le département ou les
catégories d’intérêt, ce qui permet une consultation ciblée sans nécessiter de connexion.
Sur cette page, les visiteurs ont accès à toutes les annonces validées, classées par dé-
partement. Cela permet une diffusion transparente de l’information à l’ensemble de la
communauté.
35

37. CHAPITRE 3. PROCESSUS FONCTIONNEL DE L’APPLICATION
3.4.2
Figure 3.19– Page du planning public des événements
Directement accessible depuis la page d’accueil de l’application, cette page offre aux vi-
siteurs une vue complète de tous les événements à venir. Les événements sont triés par
date et accompagnés de détails essentiels tels que la date précise, le lieu et une description
succincte. Ce planning permet aux visiteurs de rester informés des activités importantes
de l’établissement (conférences, soutenances, réunions, etc.) sans avoir à se connecter.
Le planning des événements est accessible à tous, permettant aux visiteurs de rester
informés des activités importantes de l’établissement (conférences, soutenances, réunions,
etc.).
Résumé du chapitre
Ce chapitre décrit de manière détaillée le fonctionnement de l’application du point de
vue de ses différents utilisateurs : administrateurs, professeurs et visiteurs. Il présente
les interfaces communes telles que la page d’accueil, d’inscription et de connexion, avant
d’illustrer les parcours spécifiques à chaque rôle.
L’administrateur dispose d’un tableau de bord avancé lui permettant de gérer les utili-
sateurs, les départements, les annonces et les plannings. Le professeur, quant à lui, peut
créer, modifier et suivre ses annonces via une interface dédiée. Enfin, les visiteurs peuvent
consulter les annonces validées et le planning public sans avoir besoin de se connecter. Ce
chapitre met également en valeur la simplicité d’utilisation et la logique ergonomique de
la plateforme.
36

38. Chapitre 4
Conclusion Générale et Perspectives
37

39. CHAPITRE 4. CONCLUSION GÉNÉRALE ET PERSPECTIVES
4.1
4.1.1
Dès le début, nous avions défini des objectifs prioritaires pour l’application. Voici ce qui
a été accompli :
•Plateforme centralisée et intuitive: une interface conviviale pour les adminis-
trateurs, les enseignants et les visiteurs.
•Module de gestion des annonces: création, modification, suppression et vali-
dation(Crud) des annonces avec des statuts clairs et des filtres avancés.
•Gestion des utilisateurs et des départements: interface complète pour l’ad-
ministration, incluant la création et la modification des comptes.
•Historique et traçabilité: suivi des actions réalisées pour une meilleure transpa-
rence et sécurité.
•Sécurité et performance:Validation des données, protection contre les attaques
CSRF et XSS dans toute la partie authentification, requêtes optimisées et tests de
charge.
•Accessibilité: interface responsive, compatible avec les principaux navigateurs,
pensée pour un usage simple et efficace.
4.2
Au-delà de l’aspect purement technique, ce projet a été une véritable opportunité pour
développer un large éventail de compétences :
•Maîtriser Laravel et ses concepts avancés (MVC, Eloquent, migrations, Blade, etc.).
•Concevoir une architecture fonctionnelle robuste et évolutive.
•Appliquer les bonnes pratiques de développement (sécurité, lisibilité, modularité).
•Renforcer notre esprit d’équipe, l’écoute et l’adaptabilité face aux retours des utili-
sateurs.
•Découvrir l’importance de l’UX/UI et de l’ergonomie dans la conception d’une ap-
plication Web.
38

40. CHAPITRE 4. CONCLUSION GÉNÉRALE ET PERSPECTIVES
4.3
4.3.1
•Développement d’une version mobile (Android/iOS) pour un accès encore plus facile
aux annonces.
•Ajout de notifications en temps réel (via WebSockets ou Pusher) pour alerter ins-
tantanément les utilisateurs.
•Intégration d’un module de statistiques pour visualiser les tendances et l’activité
des annonces.
•Extension de l’interface multilingue pour une utilisation plus inclusive et adaptée à
un public international.
4.3.2
•Mise en place d’un système de commentaires ou de feedback sur les annonces.
•Ajout d’un module de planification d’événements synchronisé avec les annonces
publiées.
•Amélioration continue de l’interface grâce aux retours des utilisateurs et aux tests
ergonomiques.
•Éventuelle intégration à un système d’information global de l’établissement pour
une gestion unifiée.
39

41. Mot de la fin
Au terme de ce projet de fin d’études, nous tenons à exprimer notre grande satisfaction
d’avoir mené à bien le développement d’une application Web de gestion des annonces,
répondant aux besoins concrets d’un établissement éducatif.
Cette aventure a représenté bien plus qu’un simple travail technique : elle nous a permis de
progresser dans notre maîtrise des technologies web, de structurer notre approche projet
et surtout de grandir sur le plan humain, grâce à une collaboration constructive et à la
diversité des défis relevés. Nous avons appris à écouter, à partager, à nous adapter aux
contraintes, et à chercher l’excellence dans chaque étape du développement.
Nous adressons nos remerciements les plus sincères àM. Driss Chanapour la qualité
de son encadrement, sa disponibilité et ses conseils toujours pertinents. Son suivi attentif
et professionnel a largement contribué à la réussite de ce projet.
Nous remercions également tous les enseignants, membres de l’établissement, collègues et
proches qui nous ont accompagnés de près ou de loin, et dont le soutien et les remarques
ont enrichi notre réflexion et notre démarche.
Ce projet marque la fin d’un parcours académique et le début de nouvelles ambitions pro-
fessionnelles, armés de compétences solides, d’esprit d’équipe, et de la confiance nécessaire
pour aborder nos futurs défis.
40

42. Webographie
— https://laravel.com/docs
— https://youtu.be/CmZkMH8uzGo?si=
53k0dLlMcmKDgyzd
— https://getbootstrap.com/docs
— https://www.php.net/docs.php
— https://stackoverflow.com/
— https://dev.mysql.com/doc/
— https://www.w3schools.com/
— https://mailtrap.io/docs/
—
Internet.https://ngrok.com
—L
ATEX— Utilisé pour rédiger et mettre en forme ce rapport de stage.
https://latex-project.org/help/documentation/
41