Développement d’une application web de gestion d’événements internes pour une petite entreprise.

L’application devra intégrer les fonctionnalités suivantes :

- Création d’un événement (titre, date, lieu, description)
- Inscription des participants
- Affichage de la liste des événements à venir
- Envoi automatique de rappels par email
- Modification ou annulation d’un événement
- Export de la liste des participants en PDF

PREMIÈRE PARTIE : APPROCHE

TRADITIONNELLE — 01H30
Citer les méthodes pour recueillir les besoins client.
1. Entretiens Individuels
Cette méthode consiste à rencontrer les utilisateurs clés (ceux qui utiliseront l'application :
organisateurs d'événements, participants potentiels, et la direction) individuellement pour discuter
de leurs besoins, de leurs attentes et de leurs processus actuels. C'est une excellente façon d'obtenir
des informations détaillées et de comprendre les nuances de chaque rôle.

2. Ateliers et Brainstorming
Organiser des sessions de groupe avec les parties prenantes permet de générer des idées, de discuter
des fonctionnalités souhaitées et de résoudre collectivement les problèmes potentiels. Ces ateliers
favorisent la collaboration et aident à obtenir un consensus sur les priorités.

3. Questionnaires et Sondages
Pour recueillir des informations auprès d'un plus grand nombre de personnes, les questionnaires et
sondages peuvent être très utiles. Ils permettent de quantifier les besoins et de cibler des
fonctionnalités spécifiques. Cependant, ils peuvent manquer de la profondeur des entretiens
individuels.

4. Analyse Documentaire
Il s'agit d'examiner les documents existants liés à la gestion actuelle des événements (par exemple,
des feuilles de calcul, des emails échangés, des comptes-rendus de réunions). Cette analyse peut
révéler des processus implicites et des lacunes que l'application pourrait combler.
5. Observation des Processus Existant
Observer comment les événements sont gérés actuellement, même si c'est de manière informelle,
peut fournir des insights précieux sur les flux de travail, les points douloureux et les opportunités
d'amélioration que l'application pourrait apporter.

6. Prototypage Rapide (Maquettes/Wireframes)

Bien que ce ne soit pas une méthode de recueil de besoins à proprement parler, la création rapide de
maquettes ou de wireframes (esquisses de l'interface utilisateur) peut aider à valider les besoins et à
susciter des retours concrets de la part des utilisateurs, affinant ainsi les exigences.

Citez les besoins fonctionnels et besoins non fonctionnels

Besoins Fonctionnels (Ce que l'application DOIT faire)
Les besoins fonctionnels décrivent les fonctionnalités spécifiques que l'application doit offrir pour
répondre aux exigences des utilisateurs.
• Gestion des événements :
• Création d'un événement : Permettre aux utilisateurs autorisés de créer un nouvel
événement en spécifiant un titre, une date (début et fin), un lieu, une description
détaillée, et éventuellement une image ou un programme.
• Modification d'un événement : Offrir la possibilité de modifier toutes les
informations d'un événement existant.
• Annulation d'un événement : Permettre l'annulation d'un événement, avec
notification automatique aux participants inscrits.
• Affichage des événements : Présenter une liste claire et navigable des événements à
venir, avec des options de filtrage (par date, par lieu, etc.).
• Historique des événements : Afficher une liste des événements passés.
• Gestion des participants :
• Inscription des participants : Permettre aux utilisateurs de s'inscrire à un
événement.
• Désinscription des participants : Offrir la possibilité de se désinscrire d'un
événement.
• Gestion des inscriptions : Pour les organisateurs, visualiser la liste des participants
inscrits à chaque événement.
• Export de la liste des participants : Générer et exporter la liste des participants d'un
événement spécifique au format PDF.
• Communication :
• Envoi automatique de rappels par email : Envoyer des rappels aux participants
inscrits avant la date de l'événement (par exemple, 24 heures et 1 heure avant).
• Notifications en cas de modification/annulation : Informer automatiquement les
participants par email en cas de modification majeure ou d'annulation d'un
événement.
• Gestion des utilisateurs (si applicable) :
 • Authentification : Permettre aux utilisateurs de se connecter de manière sécurisée
(par exemple, avec email/mot de passe ou via un système d'authentification unique
de l'entreprise).
• Gestion des rôles : Distinguer différents niveaux d'accès (par exemple,
administrateur, organisateur d'événements, participant standard).

Besoins Non Fonctionnels (Comment l'application DOIT fonctionner)

Les besoins non fonctionnels décrivent les qualités de l'application, plutôt que ses fonctionnalités.
Ils définissent comment le système doit se comporter.
• Performance :
• Temps de réponse : L'application doit répondre aux requêtes des utilisateurs en
moins de 2 secondes pour les opérations courantes (affichage d'une liste
d'événements, inscription).
• Scalabilité : L'application doit pouvoir gérer une augmentation du nombre
d'événements et de participants sans dégradation significative des performances.
• Sécurité :
• Authentification et autorisation : Seuls les utilisateurs autorisés doivent pouvoir
accéder aux fonctionnalités spécifiques (création/modification d'événements).
• Protection des données : Les données des utilisateurs et des événements doivent
être protégées contre les accès non autorisés et les pertes.
• Vulnérabilités : L'application doit être conçue pour résister aux attaques courantes
(injections SQL, XSS, etc.).
• Utilisabilité (Ergonomie) :
• Interface intuitive : L'interface utilisateur doit être simple, claire et facile à
comprendre, même pour les utilisateurs novices.
• Expérience utilisateur (UX) : Le parcours utilisateur doit être fluide et logique pour
toutes les fonctionnalités.
• Accessibilité : L'application devrait idéalement être accessible aux personnes ayant
des besoins spécifiques (par exemple, support pour lecteurs d'écran).
• Fiabilité :
• Disponibilité : L'application doit être disponible 99,5 % du temps (hors périodes de
maintenance planifiée).
• Gestion des erreurs : Le système doit afficher des messages d'erreur clairs et
informatifs en cas de problème.
• Sauvegarde et restauration : Les données doivent être régulièrement sauvegardées
et un plan de restauration doit être en place.
• Maintenabilité :
• Code propre : Le code doit être bien structuré, commenté et facile à comprendre
pour faciliter les futures évolutions et corrections.
• Documentation : Une documentation technique doit être disponible pour les
développeurs.
• Compatibilité :
• Navigateurs : L'application doit être compatible avec les navigateurs web modernes
(Chrome, Firefox, Edge, Safari) sur différentes versions.
 • Appareils : L'interface doit être responsive et s'adapter aux différents types
d'appareils (ordinateurs de bureau, tablettes, smartphones).
Dessiner un MCD simplifié des entités principales.
Proposer une architecture applicative en trois couches avec un schéma. Architecture Applicative
en Trois Couches
Cette architecture divise l'application en trois couches logiques distinctes, chacune ayant une
responsabilité spécifique :
1. Couche Présentation (ou Client) : C'est ce que l'utilisateur voit et avec quoi il interagit.
Elle gère l'interface utilisateur et la logique de présentation.
2. Couche Métier (ou Application/Logique de Traitement) : C'est le cerveau de l'application.
Elle contient toute la logique métier, les règles de validation, et orchestre les interactions
entre la couche présentation et la couche données.
3. Couche Données (ou Accès aux Données) : Elle est responsable de la persistance des
données. Elle interagit directement avec la base de données pour stocker, récupérer, mettre à
jour et supprimer les informations.

Schéma de l'Architecture en Trois Couches

Voici un schéma simplifié illustrant cette architecture pour votre application :
+------------------------------------+
| Couche Présentation |
| (Frontend - Navigateur Web / UI) |
| |
| - Pages HTML/CSS/JavaScript |
| - Framework Frontend (React, Vue, |
| Angular) |
| - Interactions utilisateur |
| - Affichage des données |
+------------------------------------+
|
| Requêtes HTTP (API REST/GraphQL)
V
+------------------------------------+
| Couche Métier |
| (Backend - Serveur Applicatif) |
| |
| - Logique métier (création/gestion |
| d'événements, inscription, etc.) |
| - Validation des données |
| - Services (envoi d'e-mails) |
| - API REST (Endpoints) |
| - Langages: Python (Django/Flask), |
| [Link] (Express), PHP (Laravel) |
+------------------------------------+
|
| Requêtes SQL (JDBC/ORM)
V
+------------------------------------+
| Couche Données |
| (Base de Données) |
| |
| - Stockage des événements, |
| utilisateurs, participants |
| - Persistance des données |
| - Types: PostgreSQL, MySQL, SQLite |
+------------------------------------+

Description Détaillée des Couches :

1. Couche Présentation (Frontend)
• Responsabilité : Gérer l'interface utilisateur, afficher les informations, collecter les entrées
de l'utilisateur et envoyer les requêtes à la couche métier.
• Technologies possibles :
• HTML, CSS, JavaScript : Les bases de toute interface web.
• Frameworks JavaScript (SPA - Single Page Application) : React, [Link], Angular
pour une expérience utilisateur dynamique et réactive.
• Librairies UI : Material-UI, Bootstrap, Ant Design pour accélérer le développement
de l'interface.
• Exemples d'interactions : Un utilisateur clique sur "Créer un événement", remplit un
formulaire, puis clique sur "Soumettre". La couche présentation envoie ces données à la
couche métier via une requête HTTP.

2. Couche Métier (Backend / Serveur Applicatif)

• Responsabilité : Contenir la logique métier de l'application. Elle reçoit les requêtes de la
couche présentation, les traite, applique les règles métier, interagit avec la couche données si
nécessaire, puis renvoie une réponse. Elle gère également des services comme l'envoi d'e-
mails.
• Technologies possibles :
• Langages de programmation : Python (avec des frameworks comme Django ou
Flask), [Link] (avec Express), PHP (avec Laravel), Ruby (avec Rails), Java (avec
Spring Boot).
• API REST : Définition des points d'accès (endpoints) pour la communication avec le
frontend (ex: /api/events, /api/users/register).
• Services : Module d'envoi d'e-mails (pour les rappels), gestion des validations
d'entrées.
• Exemples de traitements : Lorsqu'une requête de création d'événement arrive, la couche
métier valide les données (date valide, titre non vide), puis demande à la couche données de
sauvegarder le nouvel événement. Elle peut aussi déclencher l'envoi d'un email de
confirmation.

3. Couche Données (Base de Données)

• Responsabilité : Stocker, gérer et fournir un accès persistant aux données de l'application.
Elle est la source de vérité pour toutes les informations.
• Technologies possibles :
• Bases de données relationnelles : PostgreSQL (robuste et open-source), MySQL
(populaire et fiable), SQLite (pour des projets plus petits ou de développement
local).
• Systèmes de gestion de base de données (SGBD) : Le moteur de base de données
lui-même.
 • ORM (Object-Relational Mapper) : Des outils comme SQLAlchemy (Python),
Sequelize ([Link]) ou Eloquent (PHP Laravel) sont souvent utilisés dans la couche
métier pour faciliter l'interaction avec la base de données sans écrire directement du
SQL brut.
• Exemples d'opérations : Sauvegarder un nouvel événement, récupérer la liste de tous les
événements, mettre à jour les informations d'un participant.
Donner un exemple de diagramme de cas d’utilisation UML (3 cas, 1 acteur).