Chapitre III : "Hairbnb" Analyse système

1. Introduction

Après avoir défini les grands axes du besoin métier et les cas d’usage attendus par les utilisateurs, cette section se concentre sur la modélisation technique et fonctionnelle du système cible.

L’objectif de cette analyse est de traduire les intentions métier exprimées précédemment en éléments concrets du système d’information, en s’appuyant sur des outils tels que les diagrammes UML (cas d’utilisation, séquence, activités, etc.), les modèles de données ou encore les scénarios d’interaction.

Cette étape constitue un pont essentiel entre le besoin exprimé et la phase de développement, car elle permet de clarifier la structure de l’application, d’anticiper les comportements attendus, et d’identifier les contraintes techniques majeures.

Je reconnais que le périmètre (scope) fixé initialement a été modifié à plusieurs reprises au cours de la phase de développement.

Cela a parfois été démoralisant, et j’ai eu l’impression d’évoluer dans un cercle vicieux entre ajustements fonctionnels, contraintes techniques, et le retour constant vers l’adaptation de l’analyse en fonction des fonctionnalités que j’avais ajoutées.

Mais avec du recul, je pense que cette expérience est assez représentative de la réalité d’un projet de développement, surtout lorsqu’il est mené seul.

Normalement, ce type de projet mobilise plusieurs profils complémentaires (analyste, développeur, designer, etc.), chacun concentré sur un domaine bien défini.

De mon côté, je n’ai pas encore les compétences d’un analyste professionnel : mes bases proviennent essentiellement de la formation suivie et de mes efforts d’autoformation.

C’est pourquoi les allers-retours entre l’analyse et le développement étaient non seulement inévitables, mais aussi formatrices dans mon cas.

2. L’analyse système

2.1. Qu’est-ce que l’analyse système ?

De mon point de vue, une fois l’analyse métier achevée, l’analyse système prend le relais.

Elle consiste à traduire ces besoins métier en spécifications fonctionnelles et techniques.

On modélise des cas d’utilisation, on détaille les interactions entre les composants, les flux de données, les interfaces, etc.

L’enjeu est simple : comment le système va-t-il répondre aux exigences identifiées lors de l’analyse métier ?

— Soulaiman

L’analyse système est une approche qui permet d’examiner un système informatique dans son ensemble, en tenant compte de ses interactions internes et externes.

Elle est utilisée pour comprendre comment les différentes parties d’un système s’influencent mutuellement et pour prendre des décisions éclairées en conséquence.

L’analyse système s’intéresse au "comment" : comment le système actuel fonctionne-t-il ? Quelles sont ses données, ses traitements, ses flux, ses composants ?

Source : Office québécois de la langue française https://vitrinelinguistique.oqlf.gouv.qc.ca/fiche-gdt/fiche/8460144/analyse-de-systeme

2.2. Comparaison entre analyse métier et analyse système

Critère	Analyse métier	Analyse système
Objectif	Comprendre les besoins métier et les formaliser	Traduire les besoins en une solution informatique réalisable
Questions principales	Que fait le métier ? Pourquoi ? Pour qui ?	Comment va-t-on concevoir le système ? Avec quelles technologies ?
Portée	Organisation, processus, rôles, règles métier	Architecture du SI, bases de données, interfaces, traitements
Méthodes	Entretiens, ateliers, modélisation BPMN	UML (cas d’utilisation, séquence, classes), maquettage, prototypes
Livrables	Cahier des charges, diagrammes BPMN, matrice des besoins	Spécifications fonctionnelles, diagrammes UML, architecture logique
Intervenants	Analystes métier, utilisateurs, responsables métier	Analystes système, architectes, développeurs

Critère

Analyse métier

Analyse système

Objectif

Comprendre les besoins métier et les formaliser

Traduire les besoins en une solution informatique réalisable

Questions principales

Que fait le métier ? Pourquoi ? Pour qui ?

Comment va-t-on concevoir le système ? Avec quelles technologies ?

Portée

Organisation, processus, rôles, règles métier

Architecture du SI, bases de données, interfaces, traitements

Méthodes

Entretiens, ateliers, modélisation BPMN

UML (cas d’utilisation, séquence, classes), maquettage, prototypes

Livrables

Cahier des charges, diagrammes BPMN, matrice des besoins

Spécifications fonctionnelles, diagrammes UML, architecture logique

Intervenants

Analystes métier, utilisateurs, responsables métier

Analystes système, architectes, développeurs

3. L’analyse "Client" système

Les acteurs déjà identifiés dans la partie analyse métier ne seront pas redéfinis ici, afin d’éviter toute redondance.

En revanche, les acteurs non encore mentionnés dans l’analyse métier seront introduits au fur et à mesure, selon les besoins de cette partie.

3.1. Diagramme de cas d’utilisation (use case) : Client Système

Figure 1. Diagramme de cas d’utilisation : Client Système

3.2. Synthèse des cas d’utilisation – Client

Réf.	Nom du cas d’utilisation	Acteurs principaux	Objectif principal
UC_S1	Gérer le profil	Client, Système	Modifier ses informations personnelles ou supprimer son compte.
UC_S3	Chercher / Géolocaliser un salon	Client, API Géoloc	Localiser les salons proches en fonction de sa position ou d’une adresse.
UC_S4	Consulter les détails de salon	Client, Système	Afficher la fiche complète d’un salon (infos, services, galerie…).
UC_S5	Ajouter / Retirer un salon des favoris	Client, Système	Gérer sa liste de salons favoris pour un accès rapide.
UC_S6	Consulter les services et les tarifs	Client, Système	Visualiser les prestations, leurs prix et durées proposées par un salon.
UC_S7	Gérer le panier	Client, Application	Ajouter ou retirer des services en vue d’une réservation.
UC_S8	Gérer les rendez-vous	Client, Backend, DB	Réserver, modifier ou consulter ses rendez-vous.
UC_S9	Choisir un rendez-vous	Client, Backend, DB	Sélectionner un créneau disponible avant le paiement.
UC_S10	Valider et payer	Client, Backend, Stripe	Finaliser la réservation avec paiement sécurisé via Stripe.
UC_S11	Recevoir des notifications	Client, Email, Backend	Être notifié des événements (réservation, rappel, annulation…).
UC_S12	Entamer une conversation avec une coiffeuse	Client, Firebase, Backend	Échanger en temps réel avec une coiffeuse via messagerie intégrée.

Réf.

Nom du cas d’utilisation

Acteurs principaux

Objectif principal

UC_S1

Gérer le profil

Client, Système

Modifier ses informations personnelles ou supprimer son compte.

UC_S3

Chercher / Géolocaliser un salon

Client, API Géoloc

Localiser les salons proches en fonction de sa position ou d’une adresse.

UC_S4

Consulter les détails de salon

Client, Système

Afficher la fiche complète d’un salon (infos, services, galerie…).

UC_S5

Ajouter / Retirer un salon des favoris

Client, Système

Gérer sa liste de salons favoris pour un accès rapide.

UC_S6

Consulter les services et les tarifs

Client, Système

Visualiser les prestations, leurs prix et durées proposées par un salon.

UC_S7

Gérer le panier

Client, Application

Ajouter ou retirer des services en vue d’une réservation.

UC_S8

Gérer les rendez-vous

Client, Backend, DB

Réserver, modifier ou consulter ses rendez-vous.

UC_S9

Choisir un rendez-vous

Client, Backend, DB

Sélectionner un créneau disponible avant le paiement.

UC_S10

Valider et payer

Client, Backend, Stripe

Finaliser la réservation avec paiement sécurisé via Stripe.

UC_S11

Recevoir des notifications

Client, Email, Backend

Être notifié des événements (réservation, rappel, annulation…).

UC_S12

Entamer une conversation avec une coiffeuse

Client, Firebase, Backend

Échanger en temps réel avec une coiffeuse via messagerie intégrée.

3.3. UC_S1 : Gérer le profil

Élément	Détail
Nom du cas d’utilisation	Gérer le profil
Description	Ce cas d’utilisation offre au client la possibilité de visualiser, mettre à jour les informations de son profil utilisateur, telles que son nom, prénom, adresse, photo, email, ou mot de passe, il peut aussi supprimer son compte.
Acteurs	Client, Firebase
Précondition	Le client est authentifié et dispose d’un compte valide.
Postcondition	Le profil est mis à jour avec les nouvelles informations saisies.
Scénario nominal	Le client accède à la section "Mon profil". Il modifie les champs souhaités (photo, adresse, nom…). Il valide les changements. Le système enregistre les données modifiées et affiche une confirmation.
Scénario alternatif	Le client ne modifie que certains champs (ex : uniquement la photo ou le numéro de téléphone). Le client annule la modification avant validation.
Scénario d’exception	Le système rencontre une erreur lors de la sauvegarde (erreur serveur, base de données). Le format de l’email est invalide. Le fichier photo est trop lourd ou non autorisé.
Remarque	Firebase peut être sollicité si l’utilisateur modifie son adresse email ou son mot de passe (re-authentification, sécurité renforcée).

Élément

Détail

Nom du cas d’utilisation

Gérer le profil

Description

Ce cas d’utilisation offre au client la possibilité de visualiser, mettre à jour les informations de son profil utilisateur, telles que son nom, prénom, adresse, photo, email, ou mot de passe, il peut aussi supprimer son compte.

Acteurs

Client, Firebase

Précondition

Le client est authentifié et dispose d’un compte valide.

Postcondition

Le profil est mis à jour avec les nouvelles informations saisies.

Scénario nominal

Le client accède à la section "Mon profil".
Il modifie les champs souhaités (photo, adresse, nom…).
Il valide les changements.
Le système enregistre les données modifiées et affiche une confirmation.

Scénario alternatif

Le client ne modifie que certains champs (ex : uniquement la photo ou le numéro de téléphone).
Le client annule la modification avant validation.

Scénario d’exception

Le système rencontre une erreur lors de la sauvegarde (erreur serveur, base de données).
Le format de l’email est invalide.
Le fichier photo est trop lourd ou non autorisé.

Remarque

Firebase peut être sollicité si l’utilisateur modifie son adresse email ou son mot de passe (re-authentification, sécurité renforcée).

Figure 2. Diagramme d’activité : Gérer le profil

Figure 3. Diagramme de séquence : Gérer le profil

3.3.1. Ecrans – Gérer le profil

Modifier l’adresse (exemple)

Page de profil (client)

3.4. UC_S3 : Chercher / Géolocaliser un salon

Élément	Détail
Nom du cas d’utilisation	Chercher / Géolocaliser un salon
Description	Le client souhaite découvrir les salons disponibles proches de sa position actuelle. L’application utilise la géolocalisation pour afficher les résultats les plus pertinents.
Acteurs	Client, Système, API de géolocalisation
Précondition	Le client est connecté et a autorisé l’accès à sa localisation.
Postcondition	Une liste de salons à proximité est affichée avec leur distance, évaluation et détails.
Scénario nominal	Le client clique sur « Rechercher des salons ». Le système récupère la localisation du client via l’API. Le client choisit de filtrer les salons par distance. Une requête est envoyée pour filtrer les salons les plus proches. La liste est affichée avec les distances, notes et options de filtre supplémentaires.
Scénario alternatif	Le client choisit d’utiliser une adresse manuelle au lieu de la géolocalisation apartir de sa position. Le client modifie les filtres pour ajuster les résultats (chercher par nom de salon).
Scénario d’exception	La géolocalisation est désactivée ou non autorisée. L’API de localisation ne répond pas. Aucun salon trouvé dans la zone définie.
Remarque	L’expérience utilisateur peut varier selon la qualité du signal GPS et les autorisations données à l’application.

Élément

Détail

Nom du cas d’utilisation

Chercher / Géolocaliser un salon

Description

Le client souhaite découvrir les salons disponibles proches de sa position actuelle.
L’application utilise la géolocalisation pour afficher les résultats les plus pertinents.

Acteurs

Client, Système, API de géolocalisation

Précondition

Le client est connecté et a autorisé l’accès à sa localisation.

Postcondition

Une liste de salons à proximité est affichée avec leur distance, évaluation et détails.

Scénario nominal

Le client clique sur « Rechercher des salons ».
Le système récupère la localisation du client via l’API.
Le client choisit de filtrer les salons par distance.
Une requête est envoyée pour filtrer les salons les plus proches.
La liste est affichée avec les distances, notes et options de filtre supplémentaires.

Scénario alternatif

Le client choisit d’utiliser une adresse manuelle au lieu de la géolocalisation apartir de sa position.
Le client modifie les filtres pour ajuster les résultats (chercher par nom de salon).

Scénario d’exception

La géolocalisation est désactivée ou non autorisée.
L’API de localisation ne répond pas.
Aucun salon trouvé dans la zone définie.

Remarque

L’expérience utilisateur peut varier selon la qualité du signal GPS et les autorisations données à l’application.

Figure 4. Diagramme d’activité : Chercher / Géolocaliser un salon

Figure 5. Diagramme de séquence : Chercher / Géolocaliser un salon

3.4.1. Ecrans – Chercher / Géolocaliser un salon

Chercher des salons apartir de ma position

Chercher des salons apartir d’une adresse

3.5. UC_S4 : Consulter les détails de salon

Élément	Détail
Nom du cas d’utilisation	Consulter les détails de salon
Description	Ce cas d’utilisation permet au client de consulter la fiche complète d’un salon de coiffure après l’avoir sélectionné depuis la liste des résultats. L’utilisateur peut y voir les informations générales (adresse, slogan, services, équipements, galerie, etc.), interagir avec des onglets, et initier une action (réservation ou ajout aux favoris).
Acteurs	Client, Système
Précondition	Le client a effectué une recherche de salons et a sélectionné un salon dans la liste. Le salon sélectionné existe et est disponible.
Postcondition	La fiche détaillée du salon est affichée avec ses données actualisées.
Scénario nominal	Le client clique sur un salon dans la liste des résultats. Le système récupère les informations complètes du salon depuis la base de données. L’application affiche la page détaillée du salon (onglet actif : services). Le client peut naviguer entre les onglets (équipements, spécialiste, galerie).
Scénario alternatif	Le client ajoute directement le salon aux favoris depuis cette page. Le client clique sur "l’icon panier" pour ajouter un service au panier. Le client clique sur Horaire" pour afficher les horaires du salon.
Scénario d’exception	Le salon n’existe plus ou a été désactivé. Une erreur réseau empêche l’affichage des détails. Certaines données du salon sont manquantes ou corrompues.
Remarque	Cette page joue un rôle clé dans l’engagement client : elle combine informations pratiques et appels à l’action (favori, réservation, partage). Elle est souvent le dernier point avant la conversion vers une action concrète.

Élément

Détail

Nom du cas d’utilisation

Consulter les détails de salon

Description

Ce cas d’utilisation permet au client de consulter la fiche complète d’un salon de coiffure après l’avoir sélectionné depuis la liste des résultats.

L’utilisateur peut y voir les informations générales (adresse, slogan, services, équipements, galerie, etc.), interagir avec des onglets, et initier une action (réservation ou ajout aux favoris).

Acteurs

Client, Système

Précondition

Le client a effectué une recherche de salons et a sélectionné un salon dans la liste.
Le salon sélectionné existe et est disponible.

Postcondition

La fiche détaillée du salon est affichée avec ses données actualisées.

Scénario nominal

Le client clique sur un salon dans la liste des résultats.
Le système récupère les informations complètes du salon depuis la base de données.
L’application affiche la page détaillée du salon (onglet actif : services).
Le client peut naviguer entre les onglets (équipements, spécialiste, galerie).

Scénario alternatif

Le client ajoute directement le salon aux favoris depuis cette page.

Le client clique sur "l’icon panier" pour ajouter un service au panier.

Le client clique sur Horaire" pour afficher les horaires du salon.

Scénario d’exception

Le salon n’existe plus ou a été désactivé.

Une erreur réseau empêche l’affichage des détails.

Certaines données du salon sont manquantes ou corrompues.

Remarque

Cette page joue un rôle clé dans l’engagement client : elle combine informations pratiques et appels à l’action (favori, réservation, partage).
Elle est souvent le dernier point avant la conversion vers une action concrète.

Figure 6. Diagramme d’activité : Consulter les détails de salon

Figure 7. Diagramme de séquence : Consulter les détails de salon

3.5.1. Ecrans – Consulter les détails de salon

Détails salon 1

Détails salon 2

3.6. UC_S5 : Ajouter / Retirer un salon des favoris

Élément	Détail
Nom du cas d’utilisation	Ajouter / Retirer un salon des favoris
Description	Ce cas d’utilisation permet au client de marquer un salon comme favori ou de le retirer de sa liste de favoris. Cela facilite l’accès rapide à ses salons préférés lors de futures réservations.
Acteurs	Client, Système, API Favoris
Précondition	Le client est connecté à son compte.
Postcondition	Le salon est ajouté ou retiré de la liste des favoris du client.
Scénario nominal	Le client accède à la page d’un salon. Il clique sur l’icône de favori (cœur). Le système détecte si le salon est déjà favori. Si non favori : le salon est ajouté aux favoris. Si déjà favori : le salon est retiré des favoris. Une animation ou un message confirme l’action.
Scénario alternatif	Le client accède à ses favoris depuis son profil et peut retirer un salon directement depuis cette liste.
Scénario d’exception	Problème de réseau ou réponse serveur invalide. Erreur lors de la requête API (timeout, 500…).
Remarque	Cette fonctionnalité permet de renforcer l’expérience personnalisée et fidéliser les utilisateurs.

Élément

Détail

Nom du cas d’utilisation

Ajouter / Retirer un salon des favoris

Description

Ce cas d’utilisation permet au client de marquer un salon comme favori ou de le retirer de sa liste de favoris.
Cela facilite l’accès rapide à ses salons préférés lors de futures réservations.

Acteurs

Client, Système, API Favoris

Précondition

Le client est connecté à son compte.

Postcondition

Le salon est ajouté ou retiré de la liste des favoris du client.

Scénario nominal

Le client accède à la page d’un salon.
Il clique sur l’icône de favori (cœur).
Le système détecte si le salon est déjà favori.
Si non favori : le salon est ajouté aux favoris.
Si déjà favori : le salon est retiré des favoris.
Une animation ou un message confirme l’action.

Scénario alternatif

Le client accède à ses favoris depuis son profil et peut retirer un salon directement depuis cette liste.

Scénario d’exception

Problème de réseau ou réponse serveur invalide.
Erreur lors de la requête API (timeout, 500…).

Remarque

Cette fonctionnalité permet de renforcer l’expérience personnalisée et fidéliser les utilisateurs.

Figure 8. Diagramme d’activité : Ajouter / Retirer un salon des favoris

Figure 9. Diagramme de séquence : Ajouter / Retirer un salon des favoris

3.7. UC_S6 : Consulter les services et les tarifs

Élément	Détail
Nom du cas d’utilisation	Consulter les services et les tarifs
Description	Permet au client de visualiser l’ensemble des services proposés par un salon sélectionné, ainsi que leurs prix et durées. Le client peut aussi initier une action comme l’ajout au panier ou accéder aux détails d’un service.
Acteurs	Client, Système
Précondition	Le client a ouvert la fiche d’un salon existant.
Postcondition	Les services disponibles sont affichés dans l’onglet dédié.
Scénario nominal	Le client navigue vers l’onglet « Services » du salon. Le système interroge la base de données pour récupérer les services disponibles. L’application affiche la liste avec nom, description, prix, et durée de chaque service. Le client peut trier ou filtrer les services.
Scénario alternatif	Le client clique sur un service pour en voir les détails. Le client ajoute un service au panier depuis cette liste.
Scénario d’exception	Aucun service n’est associé à ce salon. Erreur de récupération des données (serveur indisponible ou timeout). Données corrompues (ex. : tarif manquant).
Remarque	Cette interface est souvent déterminante dans la décision de réservation, elle doit être claire, attractive et rapide.

Élément

Détail

Nom du cas d’utilisation

Consulter les services et les tarifs

Description

Permet au client de visualiser l’ensemble des services proposés par un salon sélectionné, ainsi que leurs prix et durées.

Le client peut aussi initier une action comme l’ajout au panier ou accéder aux détails d’un service.

Acteurs

Client, Système

Précondition

Le client a ouvert la fiche d’un salon existant.

Postcondition

Les services disponibles sont affichés dans l’onglet dédié.

Scénario nominal

Le client navigue vers l’onglet « Services » du salon.
Le système interroge la base de données pour récupérer les services disponibles.
L’application affiche la liste avec nom, description, prix, et durée de chaque service.
Le client peut trier ou filtrer les services.

Scénario alternatif

Le client clique sur un service pour en voir les détails.
Le client ajoute un service au panier depuis cette liste.

Scénario d’exception

Aucun service n’est associé à ce salon.
Erreur de récupération des données (serveur indisponible ou timeout).
Données corrompues (ex. : tarif manquant).

Remarque

Cette interface est souvent déterminante dans la décision de réservation, elle doit être claire, attractive et rapide.

Figure 10. Diagramme d’activité : Ajouter / Retirer un salon des favoris

Figure 11. Diagramme de séquence : Ajouter / Retirer un salon des favoris

3.7.1. Ecrans – Consulter les services et les tarifs

3.8. UC_S7 : Gérer le panier

Élément	Détail
Nom du cas d’utilisation	Gérer le panier
Description	Ce cas d’utilisation permet au client d’ajouter, consulter ou supprimer des services dans son panier en vue d’une réservation.
Acteurs	Client, Application, Backend
Précondition	Le client est connecté et a sélectionné au moins un service.
Postcondition	Le panier est mis à jour selon les actions effectuées (ajout, suppression).
Scénario nominal	Le client clique sur l’icône panier. L’application affiche le contenu actuel du panier. Le client peut supprimer un service. Le client peut ajouter de nouveaux services depuis les fiches. Le système met à jour le panier en temps réel.
Scénario alternatif	Le client vide complètement le panier. Le client ajoute plusieurs services d’un même salon.
Scénario d’exception	Service non disponible ou supprimé entre temps. Erreur de synchronisation avec le backend. Temps de réponse trop long (timeout).
Remarque	Le panier est local mais synchronisé avec le backend pour garantir la cohérence et disponibilité des services.

Élément

Détail

Nom du cas d’utilisation

Gérer le panier

Description

Ce cas d’utilisation permet au client d’ajouter, consulter ou supprimer des services dans son panier en vue d’une réservation.

Acteurs

Client, Application, Backend

Précondition

Le client est connecté et a sélectionné au moins un service.

Postcondition

Le panier est mis à jour selon les actions effectuées (ajout, suppression).

Scénario nominal

Le client clique sur l’icône panier.
L’application affiche le contenu actuel du panier.
Le client peut supprimer un service.
Le client peut ajouter de nouveaux services depuis les fiches.
Le système met à jour le panier en temps réel.

Scénario alternatif

Le client vide complètement le panier.
Le client ajoute plusieurs services d’un même salon.

Scénario d’exception

Service non disponible ou supprimé entre temps.
Erreur de synchronisation avec le backend.
Temps de réponse trop long (timeout).

Remarque

Le panier est local mais synchronisé avec le backend pour garantir la cohérence et disponibilité des services.

Figure 12. Diagramme d’activité : Gérer le panier

Figure 13. Diagramme de séquence : Gérer le panier

3.8.1. Ecrans – Gérer le panier

3.9. UC_S8 : Gérer les rendez-vous

Élément	Détail
Nom du cas d’utilisation	Gérer les rendez-vous
Description	Ce cas d’utilisation permet au client de consulter, réserver ou annuler ses rendez-vous coiffure via l’application Hairbnb.
Acteurs	Client, Application, Backend, Base de données
Précondition	Le client est authentifié et a un panier prêt à réserver ou des rendez-vous déjà enregistrés.
Postcondition	Le rendez-vous est créé, modifié ou annulé selon l’action du client.
Scénario nominal	Le client accède à la section "Mes rendez-vous". Le système affiche la liste des rendez-vous à venir. Le client peut cliquer sur "Réserver un créneau" depuis son panier. L’application affiche les horaires disponibles du salon. Le client choisit un créneau. Le système enregistre le rendez-vous et confirme la réservation.
Scénario alternatif	Le client modifie un créneau déjà réservé. Le client consulte les détails d’un ancien rendez-vous.
Scénario d’exception	Aucune disponibilité n’est trouvée pour la date choisie. Le créneau vient d’être réservé par un autre client. Échec de sauvegarde (erreur serveur ou base de données).
Remarque	L’enregistrement d’un rendez-vous bloque le créneau dans la base pour éviter les conflits. Le client est notifié automatiquement.

Élément

Détail

Nom du cas d’utilisation

Gérer les rendez-vous

Description

Ce cas d’utilisation permet au client de consulter, réserver ou annuler ses rendez-vous coiffure via l’application Hairbnb.

Acteurs

Client, Application, Backend, Base de données

Précondition

Le client est authentifié et a un panier prêt à réserver ou des rendez-vous déjà enregistrés.

Postcondition

Le rendez-vous est créé, modifié ou annulé selon l’action du client.

Scénario nominal

Le client accède à la section "Mes rendez-vous".
Le système affiche la liste des rendez-vous à venir.
Le client peut cliquer sur "Réserver un créneau" depuis son panier.
L’application affiche les horaires disponibles du salon.
Le client choisit un créneau.
Le système enregistre le rendez-vous et confirme la réservation.

Scénario alternatif

Le client modifie un créneau déjà réservé.
Le client consulte les détails d’un ancien rendez-vous.

Scénario d’exception

Aucune disponibilité n’est trouvée pour la date choisie.
Le créneau vient d’être réservé par un autre client.
Échec de sauvegarde (erreur serveur ou base de données).

Remarque

L’enregistrement d’un rendez-vous bloque le créneau dans la base pour éviter les conflits.
Le client est notifié automatiquement.

Figure 14. Diagramme d’activité : Gérer les rendez-vous

Figure 15. Diagramme de séquence : Gérer les rendez-vous

3.10. UC_S9 : Choisir un rendez-vous

Élément	Détail
Nom du cas d’utilisation	Choisir un rendez-vous
Description	Ce cas d’utilisation intervient après que le client a sélectionné un salon et ajouté des services à son panier. Avant de procéder au paiement, il doit choisir une date et un créneau disponible dans un calendrier dynamique.
Acteurs	Client, Application, Backend, Base de données
Précondition	Le client est connecté. Le panier contient au moins un service valide. Le salon associé propose des créneaux disponibles.
Postcondition	Un créneau est sélectionné et associé à la réservation en attente de paiement.
Scénario nominal	Le client clique sur "Réserver". L’application affiche un calendrier dynamique avec les créneaux du salon. Le client choisit un jour et une heure. Le système valide la disponibilité. Le créneau est réservé temporairement et ajouté à la réservation.
Scénario alternatif	Le client change d’avis et modifie son créneau. Le client consulte plusieurs dates avant de valider.
Scénario d’exception	Aucun créneau n’est disponible sur la période souhaitée. Le créneau choisi a été pris entre-temps (conflit de réservation). Problème de synchronisation avec la base de données.
Remarque	Cette étape précède le paiement. Une fois le créneau choisi, l’utilisateur passe au récapitulatif final et au paiement.

Élément

Détail

Nom du cas d’utilisation

Choisir un rendez-vous

Description

Ce cas d’utilisation intervient après que le client a sélectionné un salon et ajouté des services à son panier.
Avant de procéder au paiement, il doit choisir une date et un créneau disponible dans un calendrier dynamique.

Acteurs

Client, Application, Backend, Base de données

Précondition

Le client est connecté.
Le panier contient au moins un service valide.
Le salon associé propose des créneaux disponibles.

Postcondition

Un créneau est sélectionné et associé à la réservation en attente de paiement.

Scénario nominal

Le client clique sur "Réserver".
L’application affiche un calendrier dynamique avec les créneaux du salon.
Le client choisit un jour et une heure.
Le système valide la disponibilité.
Le créneau est réservé temporairement et ajouté à la réservation.

Scénario alternatif

Le client change d’avis et modifie son créneau.
Le client consulte plusieurs dates avant de valider.

Scénario d’exception

Aucun créneau n’est disponible sur la période souhaitée.
Le créneau choisi a été pris entre-temps (conflit de réservation).
Problème de synchronisation avec la base de données.

Remarque

Cette étape précède le paiement.
Une fois le créneau choisi, l’utilisateur passe au récapitulatif final et au paiement.

Figure 16. Diagramme d’activité : Choisir un rendez-vous

Figure 17. Diagramme de séquence : Choisir un rendez-vous

3.10.1. Écrans – Choisir un rendez-vous

Choisir une date

Choisir un horaire

Les dates affichées en gris dans le calendrier correspondent aux créneaux non disponibles à la réservation.

Cela peut être dû à des journées complètes, des fermetures exceptionnelles du salon ou des créneaux déjà réservés par d’autres clients.

Ces dates sont rendues inactives afin d’améliorer l’expérience utilisateur et d’éviter toute tentative de réservation sur des périodes bloquées.

La logique de disponibilité repose sur la durée totale des services sélectionnés.

Par exemple, si un client choisit plusieurs prestations totalisant 4 heures, mais que seuls 2 créneaux de 3 heures sont encore libres dans la journée (le reste étant déjà réservé), alors cette date sera considérée comme indisponible pour ce client.

Le système écarte automatiquement les dates qui ne permettent pas d’assurer la prestation complète.

3.11. UC_S10 : Valider et payer

Élément	Détail
Nom du cas d’utilisation	Valider et payer
Description	Ce cas d’utilisation permet au client de finaliser sa réservation en procédant au paiement via Stripe. Cela inclut la redirection vers la plateforme sécurisée de Stripe, la validation du paiement, et la confirmation côté serveur via webhook.
Acteurs	Client, Application, Backend, Stripe
Précondition	Le client a sélectionné un salon, des services et un créneau. Le panier est complet et prêt à être payé.
Postcondition	La réservation est confirmée et marquée comme payée dans la base de données.
Scénario nominal	Le client clique sur "Payer". Le backend génère une session Stripe Checkout. Le client est redirigé vers Stripe. Il entre ses coordonnées de paiement. Stripe traite le paiement. Stripe appelle le webhook backend avec confirmation. Le backend valide la réservation et envoie la confirmation à l’utilisateur.
Scénario alternatif	Le client abandonne le paiement (redirection vers page d’échec). Le client souhaite payer avec un autre moyen accepté par Stripe.
Scénario d’exception	Échec de création de session Stripe. Paiement refusé. Aucune réponse du webhook Stripe (échec de confirmation).
Remarque	L’utilisation de Stripe garantit la conformité PCI-DSS et simplifie la gestion des méthodes de paiement et des devises.

Élément

Détail

Nom du cas d’utilisation

Valider et payer

Description

Ce cas d’utilisation permet au client de finaliser sa réservation en procédant au paiement via Stripe.
Cela inclut la redirection vers la plateforme sécurisée de Stripe, la validation du paiement, et la confirmation côté serveur via webhook.

Acteurs

Client, Application, Backend, Stripe

Précondition

Le client a sélectionné un salon, des services et un créneau.
Le panier est complet et prêt à être payé.

Postcondition

La réservation est confirmée et marquée comme payée dans la base de données.

Scénario nominal

Le client clique sur "Payer".
Le backend génère une session Stripe Checkout.
Le client est redirigé vers Stripe.
Il entre ses coordonnées de paiement.
Stripe traite le paiement.
Stripe appelle le webhook backend avec confirmation.
Le backend valide la réservation et envoie la confirmation à l’utilisateur.

Scénario alternatif

Le client abandonne le paiement (redirection vers page d’échec).
Le client souhaite payer avec un autre moyen accepté par Stripe.

Scénario d’exception

Échec de création de session Stripe.
Paiement refusé.
Aucune réponse du webhook Stripe (échec de confirmation).

Remarque

L’utilisation de Stripe garantit la conformité PCI-DSS et simplifie la gestion des méthodes de paiement et des devises.

Figure 18. Diagramme d’activité : Valider et payer

Figure 19. Diagramme de séquence : Valider et payer

3.12. UC_S11 : Recevoir des notifications

Élément	Détail
Nom du cas d’utilisation	Recevoir des notifications
Description	Ce cas d’utilisation permet au client de recevoir automatiquement des notifications concernant ses activités sur la plateforme Hairbnb. Cela inclut : confirmations de réservation, rappels de rendez-vous, annulations, ou toute autre information pertinente envoyée par e-mail ou notification intégrée à l’application.
Acteurs	Client, Backend, Système Email (configuré avec le domaine hairbnb.be)
Précondition	Le client dispose d’un compte actif avec un email valide. Le backend a correctement configuré le domaine mail (ex : SMTP, SPF, DKIM pour hairbnb.be).
Postcondition	Le client est notifié par email et/ou dans l’app selon l’événement déclencheur (réservation, annulation…).
Scénario nominal	Un événement est déclenché dans le système (ex : nouvelle réservation). Le backend génère une notification et enregistre une entrée dans la table TblEmailNotification. Un email est envoyé via le système SMTP configuré. Le client reçoit la notification dans sa boîte mail ou dans l’application.
Scénario alternatif	La notification est affichée uniquement dans l’application sans envoi d’email.
Scénario d’exception	L’email échoue à être envoyé (erreur SMTP, domaine mal configuré). L’adresse mail du client est invalide ou injoignable. Le serveur de mail tiers est temporairement indisponible.
Remarque	Le système utilise une stratégie de retry pour les envois échoués. Les notifications sont également visibles dans l’interface utilisateur pour assurer une redondance.

Élément

Détail

Nom du cas d’utilisation

Recevoir des notifications

Description

Ce cas d’utilisation permet au client de recevoir automatiquement des notifications concernant ses activités sur la plateforme Hairbnb.

Cela inclut : confirmations de réservation, rappels de rendez-vous, annulations, ou toute autre information pertinente envoyée par e-mail ou notification intégrée à l’application.

Acteurs

Client, Backend, Système Email (configuré avec le domaine hairbnb.be)

Précondition

Le client dispose d’un compte actif avec un email valide.
Le backend a correctement configuré le domaine mail (ex : SMTP, SPF, DKIM pour hairbnb.be).

Postcondition

Le client est notifié par email et/ou dans l’app selon l’événement déclencheur (réservation, annulation…).

Scénario nominal

Un événement est déclenché dans le système (ex : nouvelle réservation).
Le backend génère une notification et enregistre une entrée dans la table TblEmailNotification.
Un email est envoyé via le système SMTP configuré.
Le client reçoit la notification dans sa boîte mail ou dans l’application.

Scénario alternatif

La notification est affichée uniquement dans l’application sans envoi d’email.

Scénario d’exception

L’email échoue à être envoyé (erreur SMTP, domaine mal configuré).
L’adresse mail du client est invalide ou injoignable.
Le serveur de mail tiers est temporairement indisponible.

Remarque

Le système utilise une stratégie de retry pour les envois échoués.
Les notifications sont également visibles dans l’interface utilisateur pour assurer une redondance.

Figure 20. Diagramme d’activité : Recevoir des notifications

Figure 21. Diagramme de séquence : Recevoir des notifications

3.13. UC_S12 : Entamer une conversation avec une coiffeuse

Élément	Détail
Nom du cas d’utilisation	Entamer une conversation avec une coiffeuse
Description	Ce cas d’utilisation permet à un client de démarrer une discussion en temps réel avec une coiffeuse. La communication se fait via messagerie instantanée intégrée, propulsée par Firebase.
Acteurs	Client, Coiffeuse, Firebase, Backend, Base de données
Précondition	Le client est connecté. Le salon a au moins une coiffeuse associée visible et active. Firebase est initialisé côté client et backend.
Postcondition	Une conversation est créée dans Firebase, les messages sont synchronisés en temps réel, et archivés en base si nécessaire.
Scénario nominal	Le client accède à la fiche d’un salon ou au profil d’une coiffeuse. Il clique sur “Contacter la coiffeuse”. L’application crée un canal Firebase unique pour la conversation si inexistant. Le client rédige et envoie un message. Le message est transmis en temps réel à la coiffeuse via Firebase. La coiffeuse peut répondre dans le même canal. L’historique des échanges est consultable à tout moment.
Scénario alternatif	Le client reprend une conversation existante depuis l’onglet “Messages”. La coiffeuse initie la conversation à la suite d’une réservation ou d’une notification.
Scénario d’exception	Problème de connexion à Firebase. L’utilisateur est banni ou bloqué. La coiffeuse n’est plus active ou désinscrite. Les messages ne s’envoient pas (timeout, échec Firebase SDK).
Remarque	Le système doit assurer la sécurité, la traçabilité (logs), et éventuellement la modération des échanges. Des mécanismes anti-spam peuvent être intégrés aussi.

Élément

Détail

Nom du cas d’utilisation

Entamer une conversation avec une coiffeuse

Description

Ce cas d’utilisation permet à un client de démarrer une discussion en temps réel avec une coiffeuse.
La communication se fait via messagerie instantanée intégrée, propulsée par Firebase.

Acteurs

Client, Coiffeuse, Firebase, Backend, Base de données

Précondition

Le client est connecté.

Le salon a au moins une coiffeuse associée visible et active.

Firebase est initialisé côté client et backend.

Postcondition

Une conversation est créée dans Firebase, les messages sont synchronisés en temps réel, et archivés en base si nécessaire.

Scénario nominal

Le client accède à la fiche d’un salon ou au profil d’une coiffeuse.
Il clique sur “Contacter la coiffeuse”.
L’application crée un canal Firebase unique pour la conversation si inexistant.
Le client rédige et envoie un message.
Le message est transmis en temps réel à la coiffeuse via Firebase.
La coiffeuse peut répondre dans le même canal.
L’historique des échanges est consultable à tout moment.

Scénario alternatif

Le client reprend une conversation existante depuis l’onglet “Messages”.
La coiffeuse initie la conversation à la suite d’une réservation ou d’une notification.

Scénario d’exception

Problème de connexion à Firebase.
L’utilisateur est banni ou bloqué.
La coiffeuse n’est plus active ou désinscrite.
Les messages ne s’envoient pas (timeout, échec Firebase SDK).

Remarque

Le système doit assurer la sécurité, la traçabilité (logs), et éventuellement la modération des échanges.
Des mécanismes anti-spam peuvent être intégrés aussi.

Figure 22. Diagramme d’activité : Entamer une conversation avec une coiffeuse

3.13.1. Ecrans – Entamer une conversation avec une coiffeuse

Entamer une conversation

Liste des conversations

Conversation

Figure 23. Diagramme de séquence : Entamer une conversation avec une coiffeuse

3.14. Diagramme d’activité global – Hairbnb (Client)

3.14.1. Qu’est-ce qu’un diagramme d’activité ?

Dans la première partie d’analyse métier, la définition du diagramme d’activité (DA) était volontairement concise pour conserver une lecture légère.

Toutefois, en raison de son utilisation fréquente dans ce rapport, il est apparu pertinent d’en proposer une redéfinition plus approfondie.

Cette nouvelle définition vise à mieux éclairer le rôle du DA dans l’analyse fonctionnelle (système).

Un diagramme d’activité est un type de diagramme UML (Unified Modeling Language) qui modélise le flux d’activités et les actions au sein d’un système, d’un processus métier ou d’un algorithme.

Il représente la séquence des étapes, les points de décision, les boucles et les activités parallèles.

Il est souvent considéré comme une évolution des diagrammes de flux traditionnels, mais avec des capacités de modélisation plus riches.

Voici les éléments clés d’un diagramme d’activité :

Nœud d’activité (Activity Node) : Représente une étape ou une action à exécuter, il est souvent symbolisé par un rectangle aux bords arrondis.
Nœud initial (Initial Node) : Indique le point de départ du flux d’activités, c’est un cercle plein.
Nœud final (Final Node) : Indique la fin du flux d’activités, c’est un cercle avec un cercle plein en son centre.
Flèches de transition (Control Flows) : Représentent le passage du contrôle d’une activité à une autre.
Nœud de décision (Decision Node) : Symbolisé par un losange, il représente un point où le flux peut se diviser en plusieurs branches basées sur une condition, chaque branche est étiquetée avec la condition.
Nœud de fusion (Merge Node) : Aussi un losange, il réunit les branches divergentes d’un nœud de décision.
Nœud de bifurcation (Fork Node) : Une barre horizontale épaisse qui divise un flux unique en plusieurs flux parallèles ou concurrents.
Nœud de jointure (Join Node) : Une barre horizontale épaisse qui synchronise les flux parallèles et les rassemble en un seul flux.
Pistes (Swimlanes / Partitions) : Des conteneurs visuels (colonnes ou lignes) qui regroupent les activités par responsable ou par unité organisationnelle, montrant quelle partie du système ou quel acteur est responsable de quelle action.
Nœud d’objet (Object Node) : Un rectangle montrant un objet qui est produit ou consommé par une activité.

À quoi sert un diagramme d’activité ?

Modélisation des processus métier : Il est excellent pour décrire la logique de processus métier complexes, montrant qui fait quoi et quand.
Analyse des flux de travail : Il aide à comprendre la séquence des étapes dans un flux de travail et à identifier les goulots d’étranglement ou les opportunités d’amélioration.
Conception d’algorithmes : Il peut être utilisé pour représenter la logique d’un algorithme ou d’une fonction logicielle.
Spécification des cas d’utilisation : Il détaille les étapes d’un cas d’utilisation, y compris les chemins alternatifs et les exceptions.
Documentation : Il offre une représentation visuelle claire et concise du comportement dynamique du système.^[1]

Figure 24. Diagramme d’activité global – Hairbnb (Client)

3.15. Diagramme de séquence global – Hairbnb (Client)

3.15.1. Qu’est-ce qu’un diagramme de séquence ?

Un diagramme de séquence est un type de diagramme UML (Unified Modeling Language) qui modélise les interactions entre les objets ou les participants d’un système dans un ordre chronologique.

Il est particulièrement utile pour visualiser le flux de contrôle et les échanges de messages au fil du temps.

Voici les éléments clés d’un diagramme de séquence :

Acteurs (Actors) : Représentent des entités externes qui interagissent avec le système (par exemple, un utilisateur, un autre système).
Lignes de vie (Lifelines) : Représentent les objets ou les participants au sein du système (par exemple, l’application mobile, le service backend, la base de données).
Elles sont représentées par des lignes verticales en pointillés, et le temps s’écoule de haut en bas le long de ces lignes.
Messages : Représentent les communications entre les lignes de vie, ls sont symbolisés par des flèches horizontales.
- Messages synchrones : L’expéditeur attend une réponse avant de continuer (flèche pleine avec une pointe pleine).
- Messages asynchrones : L’expéditeur n’attend pas de réponse immédiate et continue son activité (flèche pleine avec une pointe ouverte).
- Messages de réponse : Indiquent une réponse à un message précédent (flèche en pointillés).
Barres d’activation (Activation Bars) : Des rectangles étroits placés sur les lignes de vie, indiquant la période pendant laquelle un objet est actif ou exécute une opération.
Fragments combinés : Permettent de modéliser des logiques plus complexes comme :
- alt (alternative) : Pour des chemins d’exécution alternatifs (si/alors/sinon).
- opt (option) : Pour un chemin d’exécution optionnel.
- loop (boucle) : Pour des actions répétées.
- par (parallèle) : Pour des exécutions concurrentes.

À quoi sert un diagramme de séquence ?

Comprendre le comportement : Il aide à visualiser comment les différentes parties d’un système interagissent pour accomplir une tâche spécifique ou un cas d’utilisation.
Conception : Il est utilisé pour concevoir la logique d’interaction entre les objets d’un système.
Débogage : Il peut aider à identifier les problèmes potentiels de flux ou de communication entre les composants.
Documentation : Il sert de documentation claire pour les développeurs, les testeurs et les autres parties prenantes. ^[2]

Figure 25. Diagramme de sequence global – Hairbnb (Client)

3.16. Conclusion sur les cas d’utilisation côté client

Avant de passer à la suite, voici quelques précisions importantes afin de lever d’éventuelles ambiguïtés :

Dans les diagrammes de séquence :
- Certains échanges entre le backend et la base de données peuvent laisser penser à l’utilisation directe de requêtes SQL.
- Ce n’est pas le cas : Django utilise un ORM (Object-Relational Mapping) qui permet de manipuler la base de données sans écrire de SQL brut.
- L’objectif était uniquement d’illustrer de manière simplifiée les traitements réalisés en arrière-plan (lecture, écriture, suppression, etc.).
- Ce choix permet de rendre les échanges plus compréhensibles pour un lecteur non technique, sans compromettre la rigueur du modèle.
Concernant l’interface utilisateur :
- Il est possible que certains écrans diffèrent légèrement de ceux de la version finale de l’application.
- L’application étant encore en phase de développement, des ajustements UI/UX sont en cours.
- Ces ajustements ne remettent pas en cause les fonctionnalités définies dans les cas d’utilisation, qui restent stables.
À propos de l’authentification :
- Le cas d’utilisation UC_S2 : S’authentifier n’est pas traité dans cette section volontairement.
- Il fera l’objet d’un diagramme de cas d’utilisation spécifique qui détaillera tout le processus d’authentification, notamment l’interaction avec Firebase, la validation des identifiants, la sécurité, etc.
Sur la rédaction des scénarios :
- Certains scénarios sont issus de cas concrets rencontrés durant le développement et le teste.
- D’autres, plus hypothétiques, ont été élaborés à l’aide de l’intelligence artificielle pour anticiper des comportements utilisateurs ou des situations exceptionnelles que je n’avais pas envisagées.
- Cette aide m’a permis d’élargir la réflexion et de mieux me préparer à des cas d’usage réels.

Une section spécifique du rapport sera consacrée au rôle joué par l’IA dans l’ensemble du projet, tant dans l’analyse que dans le développement.

4. L’analyse "Système d’authentification"

4.1. À propos du choix de l’authentification avec Firebase Auth

Dans ce projet, j’ai choisi d’intégrer un module externe pour gérer l’authentification des utilisateurs : Firebase Authentication.

Firebase Authentication est un service proposé par Google permettant de gérer l’inscription, la connexion et la sécurité des utilisateurs dans une application.

Il prend en charge plusieurs méthodes d’authentification comme l’email/mot de passe, Google, Facebook, Apple, ou encore l’authentification anonyme.

J’ai découvert, plus tard dans le projet, que Django proposait également son propre module d’authentification.

Toutefois, je ne regrette pas mon choix car cela m’a permis de :

Découvrir un écosystème complet et puissant,
Expérimenter des cas concrets d’intégration de services cloud,
Me rendre compte que de nombreuses applications du quotidien utilisent Firebase Auth (ex. : Duolingo, TikTok, etc.).

Voici un comparatif synthétique entre Firebase Auth et le module natif Django Authentication :

Critère	Firebase Authentication	Django Authentication
Configuration initiale	Configuration rapide via console Firebase	Nécessite la mise en place manuelle de formulaires, vues et routes
Méthodes d’authentification	Multi-support (email, Google, Facebook, etc.)	Principalement email/mot de passe (extensions nécessaires pour OAuth)
Sécurité	Gérée et auditée par Google (2FA, sécurité renforcée, token JWT)	Bonne sécurité mais nécessite une gestion côté serveur (tokens, sessions)
Intégration mobile	Excellente, nativement conçue pour apps mobiles (Flutter, React Native, etc.)	Plus adaptée aux applications web Django classiques
Scalabilité	Hautement scalable via infrastructure cloud Firebase	Dépend du serveur Django et de l’architecture mise en place
Backend requis	Optionnel (stateless)	Requiert un backend complet Django

Critère

Firebase Authentication

Django Authentication

Configuration initiale

Configuration rapide via console Firebase

Nécessite la mise en place manuelle de formulaires, vues et routes

Méthodes d’authentification

Multi-support (email, Google, Facebook, etc.)

Principalement email/mot de passe (extensions nécessaires pour OAuth)

Sécurité

Gérée et auditée par Google (2FA, sécurité renforcée, token JWT)

Bonne sécurité mais nécessite une gestion côté serveur (tokens, sessions)

Intégration mobile

Excellente, nativement conçue pour apps mobiles (Flutter, React Native, etc.)

Plus adaptée aux applications web Django classiques

Scalabilité

Hautement scalable via infrastructure cloud Firebase

Dépend du serveur Django et de l’architecture mise en place

Backend requis

Optionnel (stateless)

Requiert un backend complet Django

Ce tableau ne vise pas à établir une hiérarchie entre les technologies, mais à illustrer leurs différences. Chaque développeur entretient souvent une forme d’« amour sectaire » pour certains outils ou frameworks, en fonction de son parcours, de ses expériences et de ses habitudes.

Le choix entre Firebase Auth et Django Auth dépend donc moins d’une vérité absolue que du contexte de développement, des objectifs du projet, et de cette affinité parfois passionnée que chacun peut avoir envers certaines technologies.

4.1.1. Pourquoi j’ai choisi Firebase Auth ?

Les raisons principales qui m’ont conduit à choisir ce module externe sont :

Pas besoin de gérer moi-même les mots de passe (stockage, hachage, récupération).
Authentification prête à l’emploi, avec des SDK bien documentés pour Flutter.
Prise en charge facile de plusieurs méthodes de connexion (Google, email).
Très bien intégré avec d’autres services Firebase (ex. : Firestore, Firebase Cloud Messaging).
Moins de charge serveur côté backend (tout est géré via Firebase).

La raison la plus importante pourquoi j’ai choisi cette technologie est que : je n’ai aucune responsabilité directe sur la sécurité liée à l’authentification :

la gestion des mots de passe, leur hachage, les risques de fuites ou d’attaques (comme le brute-force ou le credential stuffing) sont entièrement pris en charge par Firebase.

Et c’est un vrai soulagement, car cette plateforme repose sur une infrastructure solide et bénéficie du travail constant d’équipes spécialisées en sécurité.

Dans les sections suivantes, le thème de l’authentification sera encore abordé à travers d’autres aspects du projet.

Il peut y avoir des redondances, mais je trouve utile de poser clairement les bases avant d’analyser plus en détail le rôle de cette technologie dans l’architecture globale.

4.2. Diagramme de cas d’utilisation de l’authentification

Figure 26. Diagramme de cas d’utilisation de l’authentification

4.3. Synthèse des cas d’utilisation – Authentification Hairbnb

Réf.	Nom du cas d’utilisation	Acteurs principaux	Objectif principal
UC_SA1	Créer un compte client	Client, Firebase Authentication	Permettre à un nouvel utilisateur de s’inscrire en tant que client via email/mot de passe.
UC_SA2	Créer un compte coiffeuse	Coiffeuse, Firebase, Backend	Enregistrer les données spécifiques d’une professionnelle dans la base Hairbnb.
UC_S2	S’authentifier	Client / Coiffeuse, Firebase	Authentifier un utilisateur existant et récupérer son rôle.
UC_SA3	Utiliser un compte Google	Utilisateur, Firebase, Backend	S’inscrire ou se connecter avec un compte Google via OAuth 2.0.
UC_SA4	Créer un compte avec email et mot de passe	Utilisateur, Firebase, Backend	Créer un compte Hairbnb avec email/password et initier la validation email.
UC_SA5	Valider le compte (email)	Utilisateur, Firebase	Confirmer l’adresse email via un lien de vérification pour sécuriser l’accès.
UC_SA6	Se connecter avec email et mot de passe	Utilisateur, Firebase, Backend	Authentifier un utilisateur existant avec email/password.
UC_SA7	Réinitialiser le mot de passe	Utilisateur, Firebase	Envoyer un email de réinitialisation pour définir un nouveau mot de passe.
UC_SA8	Générer un token	Utilisateur, Firebase, Backend	Obtenir un token JWT Firebase pour sécuriser les requêtes vers le backend.

Réf.

Nom du cas d’utilisation

Acteurs principaux

Objectif principal

UC_SA1

Créer un compte client

Client, Firebase Authentication

Permettre à un nouvel utilisateur de s’inscrire en tant que client via email/mot de passe.

UC_SA2

Créer un compte coiffeuse

Coiffeuse, Firebase, Backend

Enregistrer les données spécifiques d’une professionnelle dans la base Hairbnb.

UC_S2

S’authentifier

Client / Coiffeuse, Firebase

Authentifier un utilisateur existant et récupérer son rôle.

UC_SA3

Utiliser un compte Google

Utilisateur, Firebase, Backend

S’inscrire ou se connecter avec un compte Google via OAuth 2.0.

UC_SA4

Créer un compte avec email et mot de passe

Utilisateur, Firebase, Backend

Créer un compte Hairbnb avec email/password et initier la validation email.

UC_SA5

Valider le compte (email)

Utilisateur, Firebase

Confirmer l’adresse email via un lien de vérification pour sécuriser l’accès.

UC_SA6

Se connecter avec email et mot de passe

Utilisateur, Firebase, Backend

Authentifier un utilisateur existant avec email/password.

UC_SA7

Réinitialiser le mot de passe

Utilisateur, Firebase

Envoyer un email de réinitialisation pour définir un nouveau mot de passe.

UC_SA8

Générer un token

Utilisateur, Firebase, Backend

Obtenir un token JWT Firebase pour sécuriser les requêtes vers le backend.

4.4. UC_SA1 : Créer un compte client

Élément	Détail
Nom du cas d’utilisation	Créer un compte client
Description	Ce cas d’utilisation permet à une personne souhaitant utiliser les services de la plateforme en tant que client de créer un compte via l’application Hairbnb.
Acteurs	Client, Firebase Authentication
Précondition	L’utilisateur n’est pas encore inscrit sur la plateforme Hairbnb.
Postcondition	Un compte client est créé et référencé dans Firebase Authentification. Le client est redirigé vers la suite du processus de connexion ou vers la page d’accueil.
Scénario nominal	L’utilisateur choisit de créer un compte en tant que client. Il saisit les informations demandées (email, mot de passe, etc.). Il valide les champs du formulaire. Le système Firebase crée le compte et retourne une réponse de succès. Le client est authentifié automatiquement et accède à l’application.
Scénario alternatif	L’utilisateur se rend compte qu’il a déjà un compte et revient à la page de connexion. L’utilisateur choisit d’utiliser son compte Google à la place (voir UC_SA3).
Scénario d’exception	L’adresse email est déjà utilisée. Le mot de passe ne respecte pas les critères de sécurité. Perte de connexion Internet au moment de l’envoi.
Remarque	Cette action repose entièrement sur Firebase Authentication qui prend en charge la validation, le hachage et le stockage sécurisé des identifiants. Dans le cas d’une inscription avec une adresse email et un mot de passe, la validation de l’adresse email est une étape obligatoire.

Élément

Détail

Nom du cas d’utilisation

Créer un compte client

Description

Ce cas d’utilisation permet à une personne souhaitant utiliser les services de la plateforme en tant que client de créer un compte via l’application Hairbnb.

Acteurs

Client, Firebase Authentication

Précondition

L’utilisateur n’est pas encore inscrit sur la plateforme Hairbnb.

Postcondition

Un compte client est créé et référencé dans Firebase Authentification.
Le client est redirigé vers la suite du processus de connexion ou vers la page d’accueil.

Scénario nominal

L’utilisateur choisit de créer un compte en tant que client.
Il saisit les informations demandées (email, mot de passe, etc.).
Il valide les champs du formulaire.
Le système Firebase crée le compte et retourne une réponse de succès.
Le client est authentifié automatiquement et accède à l’application.

Scénario alternatif

L’utilisateur se rend compte qu’il a déjà un compte et revient à la page de connexion.
L’utilisateur choisit d’utiliser son compte Google à la place (voir UC_SA3).

Scénario d’exception

L’adresse email est déjà utilisée.
Le mot de passe ne respecte pas les critères de sécurité.
Perte de connexion Internet au moment de l’envoi.

Remarque

Cette action repose entièrement sur Firebase Authentication qui prend en charge la validation, le hachage et le stockage sécurisé des identifiants.
Dans le cas d’une inscription avec une adresse email et un mot de passe, la validation de l’adresse email est une étape obligatoire.

Figure 27. Diagramme d’activité : Créer un compte client

Figure 28. Diagramme de séquence : Créer un compte client

4.4.1. Écrans – Créer un compte client

Email & mot de passe

Ecran de confirmation

Email de confirmation

Message émail est validé

Creation de profil

image::img/screens/Creer compte client/C4.png[Image A, 250, 200, align="center"]

Détection de l’adresse

Enregistrer

image::img/screens/Creer compte client/C7.png[Image A, 250, 200, align="center"]

Figure 29. Diagramme de séquence : Entamer une conversation avec une coiffeuse

4.5. UC_SA2 : Créer un compte coiffeuse

Élément	Détail
Nom du cas d’utilisation	Créer un compte coiffeuse
Description	Ce cas d’utilisation permet à une personne souhaitant utiliser la plateforme en tant que professionnelle (coiffeuse) de créer son compte, après avoir sélectionné ce rôle en fin de processus d’inscription.
Acteurs	Coiffeuse, Firebase Authentication, Backend, Firestore
Précondition	L’utilisateur a choisi le rôle "coiffeuse" à la fin du processus d’inscription.
Postcondition	Un compte de type coiffeuse est créé avec toutes les données de base nécessaires. Le compte est identifiable comme professionnel et pourra être enrichi plus tard avec les données du salon.
Scénario nominal	L’utilisateur est redirigé vers le formulaire de profil coiffeuse. Il renseigne les informations supplémentaires demandées (nom commercial, ville, numéro de téléphone, etc.). Il valide le formulaire. Le backend vérifie les données et crée une entrée dans la table TblCoiffeuse. Le système confirme la création du compte professionnel.
Scénario alternatif	L’utilisateur ne remplit pas tous les champs et souhaite y revenir plus tard. Certaines données sont préremplies depuis Firebase (ex : nom, email).
Scénario d’exception	Une erreur de validation des champs empêche l’enregistrement. Problème de connexion avec la base de données. Doublon d’inscription (une entrée coiffeuse existe déjà pour cet utilisateur).
Remarque a	- Cette étape ne correspond pas à la création du salon, mais uniquement à la création du profil de la coiffeuse. - Le lien avec un salon est géré plus tard dans un autre cas d’utilisation.

Élément

Détail

Nom du cas d’utilisation

Créer un compte coiffeuse

Description

Ce cas d’utilisation permet à une personne souhaitant utiliser la plateforme en tant que professionnelle (coiffeuse) de créer son compte, après avoir sélectionné ce rôle en fin de processus d’inscription.

Acteurs

Coiffeuse, Firebase Authentication, Backend, Firestore

Précondition

L’utilisateur a choisi le rôle "coiffeuse" à la fin du processus d’inscription.

Postcondition

Un compte de type coiffeuse est créé avec toutes les données de base nécessaires.
Le compte est identifiable comme professionnel et pourra être enrichi plus tard avec les données du salon.

Scénario nominal

L’utilisateur est redirigé vers le formulaire de profil coiffeuse.
Il renseigne les informations supplémentaires demandées (nom commercial, ville, numéro de téléphone, etc.).
Il valide le formulaire.
Le backend vérifie les données et crée une entrée dans la table TblCoiffeuse.
Le système confirme la création du compte professionnel.

Scénario alternatif

L’utilisateur ne remplit pas tous les champs et souhaite y revenir plus tard.
Certaines données sont préremplies depuis Firebase (ex : nom, email).

Scénario d’exception

Une erreur de validation des champs empêche l’enregistrement.
Problème de connexion avec la base de données.
Doublon d’inscription (une entrée coiffeuse existe déjà pour cet utilisateur).

Remarque a

- Cette étape ne correspond pas à la création du salon, mais uniquement à la création du profil de la coiffeuse.
- Le lien avec un salon est géré plus tard dans un autre cas d’utilisation.

Figure 30. Diagramme d’activité : Créer un compte coiffeuse

Figure 31. Diagramme de séquence : Créer un compte coiffeuse

4.6. UC_S2 : S’authentifier

Élément	Détail
Nom du cas d’utilisation	S’authentifier
Description	Ce cas d’utilisation permet à un utilisateur déjà inscrit (client ou coiffeuse) d’accéder à son espace personnel sur la plateforme Hairbnb via un mécanisme sécurisé d’authentification.
Acteurs	Utilisateur (client ou coiffeuse), Firebase Authentication, Application
Précondition	L’utilisateur dispose déjà d’un compte (email/mot de passe ou compte Google). L’application est en mesure de dialoguer avec Firebase.
Postcondition	L’utilisateur est authentifié et obtient un token Firebase. L’utilisateur est redirigé vers l’interface principale correspondant à son rôle.
Scénario nominal	L’utilisateur saisit ses identifiants. L’application les transmet à Firebase Authentication. Firebase vérifie les informations. Si elles sont valides, un token d’authentification est généré. L’application récupère le rôle et redirige l’utilisateur vers la bonne interface.
Scénario alternatif	L’utilisateur choisit de se connecter avec son compte Google (voir UC_SA3). L’utilisateur est déjà connecté (session persistée), et la vérification se fait en arrière-plan.
Scénario d’exception	Identifiants incorrects. Adresse email non vérifiée (voir UC_SA5). Compte désactivé ou supprimé. Problème de connexion Internet ou de communication avec Firebase.
Remarque	Le rôle n’est pas défini dans Firebase mais dans la base backend (Postgres). La validation côté Firebase ne concerne que l’identité ; les autorisations dépendent du rôle attribué.

Élément

Détail

Nom du cas d’utilisation

S’authentifier

Description

Ce cas d’utilisation permet à un utilisateur déjà inscrit (client ou coiffeuse) d’accéder à son espace personnel sur la plateforme Hairbnb via un mécanisme sécurisé d’authentification.

Acteurs

Utilisateur (client ou coiffeuse), Firebase Authentication, Application

Précondition

L’utilisateur dispose déjà d’un compte (email/mot de passe ou compte Google).
L’application est en mesure de dialoguer avec Firebase.

Postcondition

L’utilisateur est authentifié et obtient un token Firebase.
L’utilisateur est redirigé vers l’interface principale correspondant à son rôle.

Scénario nominal

L’utilisateur saisit ses identifiants.
L’application les transmet à Firebase Authentication.
Firebase vérifie les informations.
Si elles sont valides, un token d’authentification est généré.
L’application récupère le rôle et redirige l’utilisateur vers la bonne interface.

Scénario alternatif

L’utilisateur choisit de se connecter avec son compte Google (voir UC_SA3).
L’utilisateur est déjà connecté (session persistée), et la vérification se fait en arrière-plan.

Scénario d’exception

Identifiants incorrects.
Adresse email non vérifiée (voir UC_SA5).
Compte désactivé ou supprimé.
Problème de connexion Internet ou de communication avec Firebase.

Remarque

Le rôle n’est pas défini dans Firebase mais dans la base backend (Postgres).
La validation côté Firebase ne concerne que l’identité ; les autorisations dépendent du rôle attribué.

Figure 32. Diagramme d’activité : S’authentifier

Figure 33. Diagramme de séquence : S’authentifier

4.6.1. Écrans – Authentification

Email & mot de passe

Afficher mot de passe

4.7. UC_SA3 : Utiliser un compte Google

Élément Détail

Élément	Détail
Nom du cas d’utilisation	Utiliser un compte Google
Description	Ce cas d’utilisation permet à un utilisateur de s’inscrire ou de se connecter via son compte Google, en utilisant l’authentification OAuth 2.0 fournie par Firebase.
Acteurs	Utilisateur, Firebase Authentication, Firestore, Backend Django
Précondition	L’utilisateur dispose d’un compte Google actif. Il accepte les autorisations demandées par Firebase.
Postcondition	Un compte est créé (ou reconnu) côté Firebase. Un utilisateur est enregistré (ou mis à jour) dans Firestore et le backend Django avec le rôle sélectionné.
Scénario nominal	L’utilisateur clique sur "Continuer avec Google". L’application ouvre une pop-up d’authentification via Firebase. L’utilisateur autorise l’accès à ses données Google (email, nom, etc.). Firebase Auth retourne un `UID`. Firestore crée ou met à jour un document utilisateur. Le backend Django est informé de l’UID et enregistre le profil utilisateur. L’application redirige vers le choix de rôle (client / coiffeuse). Si “coiffeuse”, rediriger vers `UC_SA2`.
Scénario alternatif	L’utilisateur a déjà un compte Firebase avec la même adresse email : le système l’authentifie automatiquement. Si un compte avec le même email existe côté backend, il est synchronisé.
Scénario d’exception	Refus de l’utilisateur lors du consentement Google. L’UID Firebase n’est pas retourné. Problème de synchronisation avec Firestore ou le backend.
Remarque	Ce cas d’usage peut intervenir à la fois pour une première inscription ou pour une authentification récurrente. Une vérification du rôle (client/coiffeuse) est nécessaire si l’utilisateur est nouveau.

Nom du cas d’utilisation

Utiliser un compte Google

Description

Ce cas d’utilisation permet à un utilisateur de s’inscrire ou de se connecter via son compte Google, en utilisant l’authentification OAuth 2.0 fournie par Firebase.

Acteurs

Utilisateur, Firebase Authentication, Firestore, Backend Django

Précondition

L’utilisateur dispose d’un compte Google actif.
Il accepte les autorisations demandées par Firebase.

Postcondition

Un compte est créé (ou reconnu) côté Firebase.
Un utilisateur est enregistré (ou mis à jour) dans Firestore et le backend Django avec le rôle sélectionné.

Scénario nominal

L’utilisateur clique sur "Continuer avec Google".
L’application ouvre une pop-up d’authentification via Firebase.
L’utilisateur autorise l’accès à ses données Google (email, nom, etc.).
Firebase Auth retourne un UID.
Firestore crée ou met à jour un document utilisateur.
Le backend Django est informé de l’UID et enregistre le profil utilisateur.
L’application redirige vers le choix de rôle (client / coiffeuse).
Si “coiffeuse”, rediriger vers UC_SA2.

Scénario alternatif

L’utilisateur a déjà un compte Firebase avec la même adresse email : le système l’authentifie automatiquement.
Si un compte avec le même email existe côté backend, il est synchronisé.

Scénario d’exception

Refus de l’utilisateur lors du consentement Google.
L’UID Firebase n’est pas retourné.
Problème de synchronisation avec Firestore ou le backend.

Remarque

Ce cas d’usage peut intervenir à la fois pour une première inscription ou pour une authentification récurrente.
Une vérification du rôle (client/coiffeuse) est nécessaire si l’utilisateur est nouveau.

Figure 34. Diagramme d’activité : Utiliser un compte Google

Figure 35. Diagramme de séquence : Utiliser un compte Google

4.7.1. Écrans – Utiliser un compte google

4.8. UC_SA4 : Créer un compte avec email et mot de passe

Élément Détail

Élément	Détail
Nom du cas d’utilisation	Créer un compte avec email et mot de passe
Description	Ce cas d’utilisation permet à un utilisateur de créer un compte Hairbnb à l’aide d’une adresse email et d’un mot de passe. Un email de validation est envoyé automatiquement pour activer le compte.
Acteurs	Utilisateur, Firebase Authentication, Firestore, Backend Django
Précondition	L’utilisateur n’est pas connecté. Il dispose d’une adresse email valide et non utilisée.
Postcondition	Le compte est créé dans Firebase Authentication. Une entrée est ajoutée dans Firestore avec l’UID et les données de base. Le backend peut enregistrer l’utilisateur dès validation du rôle.
Scénario nominal	L’utilisateur accède au formulaire d’inscription. Il saisit son email, mot de passe, prénom, nom… L’application valide les champs localement. Les informations sont envoyées à Firebase. Firebase crée le compte et retourne un `UID`. Un email de vérification est envoyé (si n’est pas vérifié aprés l’inscription. L’UID est stocké dans Firestore avec les infos utilisateur. L’utilisateur est redirigé vers la "home page".
Scénario alternatif	L’adresse email est déjà utilisée → message d’erreur. Firebase retourne une erreur → afficher à l’utilisateur.
Scénario d’exception	Le champ email est invalide. Le mot de passe est trop faible. Problème réseau ou échec de Firebase SDK.
Remarque	La validation de l’email est obligatoire avant toute action sensible. L’authentification est ensuite gérée via Firebase + vérification backend avec token JWT.

Nom du cas d’utilisation

Créer un compte avec email et mot de passe

Description

Ce cas d’utilisation permet à un utilisateur de créer un compte Hairbnb à l’aide d’une adresse email et d’un mot de passe.
Un email de validation est envoyé automatiquement pour activer le compte.

Acteurs

Utilisateur, Firebase Authentication, Firestore, Backend Django

Précondition

L’utilisateur n’est pas connecté.
Il dispose d’une adresse email valide et non utilisée.

Postcondition

Le compte est créé dans Firebase Authentication.
Une entrée est ajoutée dans Firestore avec l’UID et les données de base.
Le backend peut enregistrer l’utilisateur dès validation du rôle.

Scénario nominal

L’utilisateur accède au formulaire d’inscription.
Il saisit son email, mot de passe, prénom, nom…
L’application valide les champs localement.
Les informations sont envoyées à Firebase.
Firebase crée le compte et retourne un UID.
Un email de vérification est envoyé (si n’est pas vérifié aprés l’inscription.
L’UID est stocké dans Firestore avec les infos utilisateur.
L’utilisateur est redirigé vers la "home page".

Scénario alternatif

L’adresse email est déjà utilisée → message d’erreur.
Firebase retourne une erreur → afficher à l’utilisateur.

Scénario d’exception

Le champ email est invalide.
Le mot de passe est trop faible.
Problème réseau ou échec de Firebase SDK.

Remarque

La validation de l’email est obligatoire avant toute action sensible.
L’authentification est ensuite gérée via Firebase + vérification backend avec token JWT.

Figure 36. Diagramme d’activité : Créer un compte avec email et mot de passe

Figure 37. Diagramme de séquence : Créer un compte avec email et mot de passe

4.8.1. Écrans – Créer un compte avec email et mot de passe

Email & confirmation demot de passe

Ecran de Vérification de l’émail

4.9. UC_SA5 : Valider le compte (email)

Élément Détail

Élément	Détail
Nom du cas d’utilisation	Valider le compte
Description	Ce cas d’utilisation permet à l’utilisateur d’activer son compte Hairbnb en confirmant son adresse email via le lien de vérification envoyé par Firebase lors de l’inscription.
Acteurs	Utilisateur, Firebase Authentication, App Mobile
Précondition	Le compte Firebase a été créé. L’utilisateur n’a pas encore confirmé son adresse email.
Postcondition	L’adresse email de l’utilisateur est marquée comme vérifiée dans Firebase. L’application peut autoriser les accès sécurisés à la plateforme.
Scénario nominal	L’utilisateur reçoit un email de validation envoyé par Firebase. Il clique sur le lien de vérification. Firebase confirme la validation. L’utilisateur ouvre l’app Hairbnb. L’app vérifie le statut de l’email via FirebaseAuth. Si l’email est vérifié, l’utilisateur est authentifié et redirigé vers la home page.
Scénario alternatif	L’utilisateur a supprimé l’email → option pour renvoyer l’email de vérification. Il clique sur le lien mais l’email a déjà été validé → message de confirmation.
Scénario d’exception	Le lien de validation est expiré → affichage d’un message d’erreur. L’utilisateur tente de se connecter sans avoir validé → message d’alerte.
Remarque	Il est essentiel que l’email soit validé avant d’autoriser des actions sensibles (création de salon, messagerie, réservation…). L’email est vérifié côté client (`user.emailVerified`) via FirebaseAuth.

Nom du cas d’utilisation

Valider le compte

Description

Ce cas d’utilisation permet à l’utilisateur d’activer son compte Hairbnb en confirmant son adresse email via le lien de vérification envoyé par Firebase lors de l’inscription.

Acteurs

Utilisateur, Firebase Authentication, App Mobile

Précondition

Le compte Firebase a été créé.
L’utilisateur n’a pas encore confirmé son adresse email.

Postcondition

L’adresse email de l’utilisateur est marquée comme vérifiée dans Firebase.
L’application peut autoriser les accès sécurisés à la plateforme.

Scénario nominal

L’utilisateur reçoit un email de validation envoyé par Firebase.
Il clique sur le lien de vérification.
Firebase confirme la validation.
L’utilisateur ouvre l’app Hairbnb.
L’app vérifie le statut de l’email via FirebaseAuth.
Si l’email est vérifié, l’utilisateur est authentifié et redirigé vers la home page.

Scénario alternatif

L’utilisateur a supprimé l’email → option pour renvoyer l’email de vérification.
Il clique sur le lien mais l’email a déjà été validé → message de confirmation.

Scénario d’exception

Le lien de validation est expiré → affichage d’un message d’erreur.
L’utilisateur tente de se connecter sans avoir validé → message d’alerte.

Remarque

Il est essentiel que l’email soit validé avant d’autoriser des actions sensibles (création de salon, messagerie, réservation…).
L’email est vérifié côté client (user.emailVerified) via FirebaseAuth.

Figure 38. Diagramme d’activité : Valider le compte

Figure 39. Diagramme de séquence : Valider le compte

4.9.1. Écrans – Valider le compte

Email De vérification (en attente)

Email de vérification

Méssage de vérification

4.10. UC_SA6 : Se connecter avec email et mot de passe

Élément	Détail
Nom du cas d’utilisation	Se connecter avec email et mot de passe
Description	Ce cas d’utilisation permet à un utilisateur existant de se connecter à son compte Hairbnb en utilisant une adresse email et un mot de passe déjà enregistrés dans Firebase.
Acteurs	Utilisateur, Firebase Authentication, Backend Django
Précondition	L’utilisateur a déjà créé un compte avec un email valide. Son email est vérifié.
Postcondition	L’utilisateur est authentifié auprès de Firebase. Un token est généré. Le backend vérifie le token et récupère les données utilisateur. L’accès est accordé à la plateforme.
Scénario nominal	L’utilisateur accède à l’écran de connexion. Il saisit son email et son mot de passe. L’application vérifie localement les champs. Les informations sont envoyées à Firebase Auth. Firebase retourne un UID + un ID Token. Le token est envoyé au backend pour validation. Le backend décode le token et récupère l’utilisateur en base. Si tout est conforme, l’utilisateur est connecté et redirigé vers la page d’accueil.
Scénario alternatif	L’email ou le mot de passe est incorrect → message d’erreur. L’email n’est pas encore vérifié → redemander validation.
Scénario d’exception	Firebase ne parvient pas à générer le token. Le backend retourne une erreur (utilisateur inexistant, désactivé, etc.). Problème de réseau.
Remarque	Le token Firebase (JWT) est utilisé comme preuve d’authentification côté serveur. Il est recommandé de le rafraîchir régulièrement.

Élément

Détail

Nom du cas d’utilisation

Se connecter avec email et mot de passe

Description

Ce cas d’utilisation permet à un utilisateur existant de se connecter à son compte Hairbnb en utilisant une adresse email et un mot de passe déjà enregistrés dans Firebase.

Acteurs

Utilisateur, Firebase Authentication, Backend Django

Précondition

L’utilisateur a déjà créé un compte avec un email valide.
Son email est vérifié.

Postcondition

L’utilisateur est authentifié auprès de Firebase.
Un token est généré.
Le backend vérifie le token et récupère les données utilisateur.
L’accès est accordé à la plateforme.

Scénario nominal

L’utilisateur accède à l’écran de connexion.
Il saisit son email et son mot de passe.
L’application vérifie localement les champs.
Les informations sont envoyées à Firebase Auth.
Firebase retourne un UID + un ID Token.
Le token est envoyé au backend pour validation.
Le backend décode le token et récupère l’utilisateur en base.
Si tout est conforme, l’utilisateur est connecté et redirigé vers la page d’accueil.

Scénario alternatif

L’email ou le mot de passe est incorrect → message d’erreur.
L’email n’est pas encore vérifié → redemander validation.

Scénario d’exception

Firebase ne parvient pas à générer le token.
Le backend retourne une erreur (utilisateur inexistant, désactivé, etc.).
Problème de réseau.

Remarque

Le token Firebase (JWT) est utilisé comme preuve d’authentification côté serveur.
Il est recommandé de le rafraîchir régulièrement.

Figure 40. Diagramme d’activité : Se connecter avec email et mot de passe

Figure 41. Diagramme de séquence : Se connecter avec email et mot de passe

4.10.1. Écrans – Se connecter avec email et mot de passe

4.11. UC_SA7 : Réinitialiser le mot de passe

Élément Détail

Élément	Détail
Nom du cas d’utilisation	Réinitialiser le mot de passe
Description	Ce cas d’utilisation permet à un utilisateur de demander la réinitialisation de son mot de passe, uniquement si son compte a été créé avec l’option email + mot de passe. Les comptes créés via Google ne sont pas concernés.
Acteurs	Utilisateur, Firebase Authentication, App Mobile
Précondition	L’utilisateur dispose d’un compte Firebase. Ce compte a été créé via la méthode email/mot de passe.
Postcondition	Un email de réinitialisation est envoyé par Firebase. L’utilisateur peut définir un nouveau mot de passe et se reconnecter.
Scénario nominal	L’utilisateur clique sur “Mot de passe oublié”. Il saisit son adresse email. L’app vérifie si le compte existe et s’il utilise l’authentification par mot de passe. Si oui, Firebase envoie un email de réinitialisation. L’utilisateur clique sur le lien dans l’email. Il définit un nouveau mot de passe via l’interface Firebase. Il peut ensuite se reconnecter avec ce nouveau mot de passe.
Scénario alternatif	L’adresse email est liée à un compte Google → l’utilisateur est informé qu’aucun mot de passe n’est défini. L’email de réinitialisation n’est pas reçu → possibilité de renvoi.
Scénario d’exception	L’adresse email est inconnue dans Firebase. Le lien de réinitialisation est expiré. Échec lors de la définition du nouveau mot de passe. Problème de réseau.
Remarque	Cette fonctionnalité est exclusivement destinée aux comptes créés par email et mot de passe (`signInMethods.contains("password")`). Les comptes Google sont gérés uniquement via OAuth et ne nécessitent pas de mot de passe local.

Nom du cas d’utilisation

Réinitialiser le mot de passe

Description

Ce cas d’utilisation permet à un utilisateur de demander la réinitialisation de son mot de passe, uniquement si son compte a été créé avec l’option email + mot de passe.
Les comptes créés via Google ne sont pas concernés.

Acteurs

Utilisateur, Firebase Authentication, App Mobile

Précondition

L’utilisateur dispose d’un compte Firebase.
Ce compte a été créé via la méthode email/mot de passe.

Postcondition

Un email de réinitialisation est envoyé par Firebase.
L’utilisateur peut définir un nouveau mot de passe et se reconnecter.

Scénario nominal

L’utilisateur clique sur “Mot de passe oublié”.
Il saisit son adresse email.
L’app vérifie si le compte existe et s’il utilise l’authentification par mot de passe.
Si oui, Firebase envoie un email de réinitialisation.
L’utilisateur clique sur le lien dans l’email.
Il définit un nouveau mot de passe via l’interface Firebase.
Il peut ensuite se reconnecter avec ce nouveau mot de passe.

Scénario alternatif

L’adresse email est liée à un compte Google → l’utilisateur est informé qu’aucun mot de passe n’est défini.
L’email de réinitialisation n’est pas reçu → possibilité de renvoi.

Scénario d’exception

L’adresse email est inconnue dans Firebase.
Le lien de réinitialisation est expiré.
Échec lors de la définition du nouveau mot de passe.
Problème de réseau.

Remarque

Cette fonctionnalité est exclusivement destinée aux comptes créés par email et mot de passe (signInMethods.contains("password")).
Les comptes Google sont gérés uniquement via OAuth et ne nécessitent pas de mot de passe local.

Figure 42. Diagramme d’activité : Réinitialiser le mot de passe

Figure 43. Diagramme de séquence : Réinitialiser le mot de passe

4.11.1. Écrans – Réinitialiser le mot de passe

4.12. UC_SA8 : Générer un token

Élément Détail

Élément	Détail
Nom du cas d’utilisation	Générer un token
Description	Ce cas d’utilisation permet à un utilisateur authentifié via Firebase de récupérer un ID Token sécurisé (JWT), qui sera ensuite transmis au backend pour identification et autorisation.
Acteurs	Utilisateur, Firebase Authentication, App Mobile, Backend Django
Précondition	L’utilisateur est déjà connecté via Firebase. La session est encore valide.
Postcondition	Un ID Token Firebase (JWT) est généré. Ce token est envoyé au backend via un header HTTP sécurisé (`Authorization: Bearer <token>`). Le backend peut authentifier l’utilisateur à chaque requête.
Scénario nominal	L’utilisateur effectue une action nécessitant une requête au backend. L’application appelle `getIdToken()` sur l’utilisateur Firebase. Firebase génère un token JWT. L’application attache ce token à la requête HTTP. Le backend vérifie le token avec Firebase Admin SDK. Si le token est valide, l’utilisateur est authentifié côté serveur.
Scénario alternatif	Le token est expiré → l’application appelle `getIdToken(true)` pour le régénérer. L’utilisateur est déconnecté → demande de reconnexion.
Scénario d’exception	L’appel à `getIdToken()` échoue (session expirée, problème réseau…). Le token est mal formé ou invalide côté backend. Firebase Admin SDK ne peut pas vérifier le token → erreur 401.
Remarque	Le token est un JWT signé contenant le UID, les claims, la date d’expiration et d’émission. Il ne faut jamais stocker ce token en base de données, seulement en mémoire côté client (temporairement).

Nom du cas d’utilisation

Générer un token

Description

Ce cas d’utilisation permet à un utilisateur authentifié via Firebase de récupérer un ID Token sécurisé (JWT), qui sera ensuite transmis au backend pour identification et autorisation.

Acteurs

Utilisateur, Firebase Authentication, App Mobile, Backend Django

Précondition

L’utilisateur est déjà connecté via Firebase.
La session est encore valide.

Postcondition

Un ID Token Firebase (JWT) est généré.
Ce token est envoyé au backend via un header HTTP sécurisé (Authorization: Bearer <token>).
Le backend peut authentifier l’utilisateur à chaque requête.

Scénario nominal

L’utilisateur effectue une action nécessitant une requête au backend.
L’application appelle getIdToken() sur l’utilisateur Firebase.
Firebase génère un token JWT.
L’application attache ce token à la requête HTTP.
Le backend vérifie le token avec Firebase Admin SDK.
Si le token est valide, l’utilisateur est authentifié côté serveur.

Scénario alternatif

Le token est expiré → l’application appelle getIdToken(true) pour le régénérer.
L’utilisateur est déconnecté → demande de reconnexion.

Scénario d’exception

L’appel à getIdToken() échoue (session expirée, problème réseau…).
Le token est mal formé ou invalide côté backend.
Firebase Admin SDK ne peut pas vérifier le token → erreur 401.

Remarque

Le token est un JWT signé contenant le UID, les claims, la date d’expiration et d’émission.
Il ne faut jamais stocker ce token en base de données, seulement en mémoire côté client (temporairement).

Figure 44. Diagramme d’activité : Générer un token

Figure 45. Diagramme de séquence : Générer un token

4.13. Diagramme d’activité global – Authentification

Figure 46. Diagramme d’activité global – Authentification

4.14. Diagramme de séquence global – Authentification

Figure 47. Diagramme de séquence global – Authentification

Firebase est également utilisé dans le projet Hairbnb pour gérer la messagerie instantanée entre le client et la coiffeuse.

Cependant, cette fonctionnalité a déjà été détaillée séparément dans la partie dédiée à la communication temps réel.

C’est pourquoi elle ne figure pas parmi les cas d’utilisation décrits ici, qui sont exclusivement consacrés au système d’authentification et de gestion des comptes utilisateur.

5. L’analyse "Coiffeuse" système

Comme déjà mentionné, l’analyse système présentée ici est le reflet direct de l’analyse métier To-Be.

Il est donc tout à fait normal de constater une forte ressemblance, voire une compatibilité totale entre les deux approches.

Cette section a pour but d’apporter davantage de clarté sur les fonctionnalités accessibles à la coiffeuse au sein de l’application Hairbnb.

Par ailleurs, même si l’analyse distingue clairement les rôles de coiffeuse et de propriétaire, il faut rappeler qu’il s’agit dans la réalité d’une application pensée pour de petites structures. Concrètement, la coiffeuse est aussi la propriétaire de son salon.

Ce découpage analytique a été volontairement maintenu afin de garder une ouverture sur une éventuelle évolution future de la plateforme, dans laquelle un salon pourrait être géré par plusieurs coiffeuses distinctes.

Certains cas d’utilisation, bien qu’ils apparaissent dans le diagramme de cas d’utilisation de la coiffeuse, ne seront pas réanalysés dans cette section.

En effet, ils ont déjà été traités en détail dans les parties précédentes, notamment : Gérer le profil, S’authentifier, Entamer une conversation avec un client.

Afin d’éviter toute redondance, ces éléments sont considérés comme acquis et sont référencés dans leur contexte d’origine.

En revanche, le cas d’utilisation Créer un compte coiffeuse sera à nouveau analysé ici.

La raison est simple : dans la partie précédente, cette action a été étudiée du point de vue de l’authentification Firebase — c’est-à-dire l’enregistrement de l’identité de l’utilisatrice (coiffeuse) dans le module Firebase Authentication, avec les mécanismes de création de compte, et la gestion de validation de l’email, etc.

Dans cette section, l’objectif est de compléter cette approche par une vision orientée système backend, en particulier la création du profil professionnel de la coiffeuse ainsi que l’association à un salon dans la base de données relationnelle PostgreSQL.

Il est important de souligner que Firebase et PostgreSQL jouent ici des rôles complémentaires :

Firebase Authentication gère l’identification sécurisée, les sessions, et les informations sensibles comme les mots de passe.
PostgreSQL, via le backend Django, gère les données métier : les profils coiffeuse, les salons, les services, les disponibilités, etc.

Ce découplage permet de combiner les atouts d’une infrastructure sécurisée et scalable pour l’authentification (Firebase) avec la puissance d’un système relationnel robuste pour la gestion des données fonctionnelles (PostgreSQL).

5.1. Diagramme de cas d’utilisation (use case) coiffeuse

Figure 48. Diagramme de cas d’utilisation : Coiffeuse Système

5.2. Synthèse des cas d’utilisation Coiffeuse / Propriétaire

Réf.	Nom du cas d’utilisation	Acteurs principaux	Objectif principal
UC_SC1	Gérer les services proposés	Coiffeuse	Ajouter, modifier ou supprimer les prestations proposées par la coiffeuse.
UC_SC2	Gérer les disponibilités	Coiffeuse	Définir les créneaux horaires disponibles et les absences.
UC_SC3	Être notifiée des nouvelles réservations	Coiffeuse	Recevoir une alerte instantanée lorsqu’un client réserve une prestation.
UC_SC4	Communiquer avec les clients	Coiffeuse, Client	Échanger des messages via messagerie en temps réel (Firebase).
UC_SC5	Réaliser une prestation	Coiffeuse	Marquer une prestation comme réalisée à la fin du rendez-vous.
UC_SC6	Consulter les avis clients	Coiffeuse	Lire les retours, notes et commentaires laissés par les clients.
UC_SC7	Gérer son image et sa galerie	Propriétaire de salon	Modifier le logo du salon et la galerie photo professionnelle.
UC_SC8	Consulter les paiements reçus	Coiffeuse	Suivre les revenus liés aux prestations réalisées.
UC_SC9	Consulter les statistiques/analytique	Coiffeuse, AI Agent, Backend	Obtenir des données analytiques via une interface IA conversationnelle.
UC_SC10	Créer un compte coiffeuse	Coiffeuse, Backend	Insérer les informations personnelles, professionnelles et adresse dans la base.
UC_SC11	Gérer les réservations	Coiffeuse	Accepter, refuser ou consulter l’historique des demandes de réservation.
UC_SC12	Gérer les promotions	Coiffeuse	Créer ou modifier des remises sur les services proposés.
UC_SC13	Gérer le compte coiffeuse	Propriétaire de salon	Modifier ou désactiver les comptes coiffeuses liés au salon.

Réf.

Nom du cas d’utilisation

Acteurs principaux

Objectif principal

UC_SC1

Gérer les services proposés

Coiffeuse

Ajouter, modifier ou supprimer les prestations proposées par la coiffeuse.

UC_SC2

Gérer les disponibilités

Coiffeuse

Définir les créneaux horaires disponibles et les absences.

UC_SC3

Être notifiée des nouvelles réservations

Coiffeuse

Recevoir une alerte instantanée lorsqu’un client réserve une prestation.

UC_SC4

Communiquer avec les clients

Coiffeuse, Client

Échanger des messages via messagerie en temps réel (Firebase).

UC_SC5

Réaliser une prestation

Coiffeuse

Marquer une prestation comme réalisée à la fin du rendez-vous.

UC_SC6

Consulter les avis clients

Coiffeuse

Lire les retours, notes et commentaires laissés par les clients.

UC_SC7

Gérer son image et sa galerie

Propriétaire de salon

Modifier le logo du salon et la galerie photo professionnelle.

UC_SC8

Consulter les paiements reçus

Coiffeuse

Suivre les revenus liés aux prestations réalisées.

UC_SC9

Consulter les statistiques/analytique

Coiffeuse, AI Agent, Backend

Obtenir des données analytiques via une interface IA conversationnelle.

UC_SC10

Créer un compte coiffeuse

Coiffeuse, Backend

Insérer les informations personnelles, professionnelles et adresse dans la base.

UC_SC11

Gérer les réservations

Coiffeuse

Accepter, refuser ou consulter l’historique des demandes de réservation.

UC_SC12

Gérer les promotions

Coiffeuse

Créer ou modifier des remises sur les services proposés.

UC_SC13

Gérer le compte coiffeuse

Propriétaire de salon

Modifier ou désactiver les comptes coiffeuses liés au salon.

5.3. UC_SC1 : Gérer les services proposés

Élément	Détail
Nom du cas d’utilisation	Gérer les services proposés
Description	Ce cas d’utilisation permet à la coiffeuse de gérer les services qu’elle propose dans le cadre de son activité : ajout de nouvelles prestations, modification des intitulés, des prix, du temps estimé ou suppression d’un service obsolète.
Acteurs	Coiffeuse, Backend Django, Base de données PostgreSQL
Précondition	La coiffeuse est authentifiée. Elle est active dans le système Hairbnb.
Postcondition	La liste des services proposés est mise à jour en base. Les modifications sont visibles sur son profil/salon.
Scénario nominal	La coiffeuse accède à l’interface de gestion des services. Elle ajoute un nouveau service (titre, description, prix, durée, catégorie). Ou elle modifie un service existant. Ou elle supprime un service. L’application envoie les données au backend. Le backend enregistre les modifications dans PostgreSQL. La coiffeuse reçoit une confirmation visuelle.
Scénario alternatif	Le service est déjà associé à un rendez-vous futur → désactivation possible mais pas suppression. Le backend retourne une erreur de validation → message explicite.
Scénario d’exception	L’enregistrement échoue (réseau, erreur serveur). La session de l’utilisateur a expiré → redirection vers la page de connexion.
Remarque	La gestion des services doit être fluide et intuitive pour permettre à la coiffeuse d’adapter son offre à tout moment.

Élément

Détail

Nom du cas d’utilisation

Gérer les services proposés

Description

Ce cas d’utilisation permet à la coiffeuse de gérer les services qu’elle propose dans le cadre de son activité : ajout de nouvelles prestations, modification des intitulés, des prix, du temps estimé ou suppression d’un service obsolète.

Acteurs

Coiffeuse, Backend Django, Base de données PostgreSQL

Précondition

La coiffeuse est authentifiée.
Elle est active dans le système Hairbnb.

Postcondition

La liste des services proposés est mise à jour en base.
Les modifications sont visibles sur son profil/salon.

Scénario nominal

La coiffeuse accède à l’interface de gestion des services.
Elle ajoute un nouveau service (titre, description, prix, durée, catégorie).
Ou elle modifie un service existant.
Ou elle supprime un service.
L’application envoie les données au backend.
Le backend enregistre les modifications dans PostgreSQL.
La coiffeuse reçoit une confirmation visuelle.

Scénario alternatif

Le service est déjà associé à un rendez-vous futur → désactivation possible mais pas suppression.
Le backend retourne une erreur de validation → message explicite.

Scénario d’exception

L’enregistrement échoue (réseau, erreur serveur).
La session de l’utilisateur a expiré → redirection vers la page de connexion.

Remarque

La gestion des services doit être fluide et intuitive pour permettre à la coiffeuse d’adapter son offre à tout moment.

Figure 49. Diagramme d’activité : Gérer les services proposés

Figure 50. Diagramme de séquence : Gérer les services proposés

5.3.1. Écrans – Gérer les services proposés

Bouton vers les services

Liste des services

Détails d’un service

Modifier un service

Ajouter une promotion

Service avec une promotion

5.4. UC_SC2 : Gérer les disponibilités

Élément Détail

Élément	Détail
Nom du cas d’utilisation	Gérer les disponibilités
Description	Ce cas d’utilisation permet à la coiffeuse de définir ses horaires de travail réguliers ainsi que ses indisponibilités exceptionnelles (ex : vacances, absences). Ces données sont utilisées pour la prise de rendez-vous en ligne par les clients.
Acteurs	Coiffeuse, Backend Django, Base de données PostgreSQL
Précondition	La coiffeuse est connectée et active. Elle a accès à l’interface de gestion de ses disponibilités.
Postcondition	Les horaires réguliers et/ou les indisponibilités sont enregistrés en base. La prise de rendez-vous tient compte de ces créneaux.
Scénario nominal	La coiffeuse accède à l’onglet "Mes disponibilités". Elle choisit les jours ouvrables et définit les plages horaires de chaque jour. Elle peut aussi ajouter une indisponibilité ponctuelle (vacances, absence). L’application envoie les données au backend. Le backend enregistre dans les tables `TblHoraireCoiffeuse` et `TblIndisponibilite`. L’interface affiche une confirmation.
Scénario alternatif	La coiffeuse modifie une disponibilité existante. Elle supprime une indisponibilité précédemment définie.
Scénario d’exception	Le format horaire est invalide (début > fin). Un chevauchement d’horaire est détecté. Erreur de réseau ou serveur indisponible.
Remarque	La combinaison des horaires hebdomadaires et des indisponibilités ponctuelles permet de construire un planning de réservation fiable. Ce module est essentiel pour éviter la surréservation et garantir la disponibilité réelle.

Nom du cas d’utilisation

Gérer les disponibilités

Description

Ce cas d’utilisation permet à la coiffeuse de définir ses horaires de travail réguliers ainsi que ses indisponibilités exceptionnelles (ex : vacances, absences).

Ces données sont utilisées pour la prise de rendez-vous en ligne par les clients.

Acteurs

Coiffeuse, Backend Django, Base de données PostgreSQL

Précondition

La coiffeuse est connectée et active.
Elle a accès à l’interface de gestion de ses disponibilités.

Postcondition

Les horaires réguliers et/ou les indisponibilités sont enregistrés en base.
La prise de rendez-vous tient compte de ces créneaux.

Scénario nominal

La coiffeuse accède à l’onglet "Mes disponibilités".
Elle choisit les jours ouvrables et définit les plages horaires de chaque jour.
Elle peut aussi ajouter une indisponibilité ponctuelle (vacances, absence).
L’application envoie les données au backend.
Le backend enregistre dans les tables TblHoraireCoiffeuse et TblIndisponibilite.
L’interface affiche une confirmation.

Scénario alternatif

La coiffeuse modifie une disponibilité existante.
Elle supprime une indisponibilité précédemment définie.

Scénario d’exception

Le format horaire est invalide (début > fin).
Un chevauchement d’horaire est détecté.
Erreur de réseau ou serveur indisponible.

Remarque

La combinaison des horaires hebdomadaires et des indisponibilités ponctuelles permet de construire un planning de réservation fiable.
Ce module est essentiel pour éviter la surréservation et garantir la disponibilité réelle.

Figure 51. Diagramme d’activité : Gérer les disponibilités

Figure 52. Diagramme de séquence : Gérer les disponibilités

5.4.1. Écrans – Gérer les disponibilités

Bouton vers les disponibilités

Horaire & indisponibilités

5.5. UC_SC3 : Être notifiée des réservations

Élément

Détail

Nom du cas d’utilisation

Être notifiée des réservations

Description

Ce cas d’utilisation permet à la coiffeuse d’être informée en temps réel lorsqu’un client réserve une prestation, via une notification instantanée (push) déclenchée par le backend ou Firebase.

Acteurs

Coiffeuse, Client, Backend Django, Firebase Cloud Messaging (FCM)

Précondition

La coiffeuse a activé les notifications sur son appareil.
Elle est associée à un salon actif et visible.
Un client effectue une réservation sur une plage disponible.

Postcondition

Une notification est reçue côté coiffeuse.
Les informations de la réservation sont disponibles dans l’interface de gestion des RDV.

Scénario nominal

Un client finalise une réservation.
Le backend enregistre la réservation en base.
Le backend identifie la coiffeuse concernée.
Il envoie une notification via Firebase Cloud Messaging (FCM).
La coiffeuse reçoit la notification en temps réel.
Elle peut consulter les détails dans l’app Hairbnb.

Scénario alternatif

La coiffeuse a désactivé les notifications → pas de réception.
L’app n’est pas au premier plan → la notification passe par la barre système.

Scénario d’exception

Échec de livraison de la notification (perte de réseau, jeton FCM expiré).
L’utilisateur a désinstallé l’app ou bloqué les permissions de notification.

Remarque

Le système utilise Firebase Cloud Messaging pour assurer une diffusion rapide, fiable et ciblée.
Des logs côté backend permettent de tracer les notifications envoyées.

Figure 53. Diagramme d’activité : Être notifiée des réservations

Figure 54. Diagramme de séquence : Être notifiée des réservations

5.6. UC_SC5 : Réaliser une prestation

Élément

Détail

Nom du cas d’utilisation

Réaliser une prestation

Description

Ce cas d’utilisation permet à la coiffeuse de marquer une réservation comme "réalisée" une fois la prestation terminée, afin d’assurer le suivi et de déclencher les étapes suivantes (paiement, avis client, statistiques).

Acteurs

Coiffeuse, Backend Django, Base de données PostgreSQL

Précondition

La prestation est planifiée et en statut "confirmée".
La date/heure du rendez-vous est atteinte ou dépassée.

Postcondition

Le statut de la réservation est mis à jour à "réalisée".
Cela peut déclencher la demande d’avis côté client.

Scénario nominal

La coiffeuse accède à la liste de ses réservations.
Elle sélectionne une réservation terminée.
Elle clique sur "Marquer comme réalisée".
L’application envoie la requête au backend.
Le backend met à jour le statut dans la base.
La prestation est archivée comme réalisée.
Le client est notifié (optionnel).

Scénario alternatif

La réservation est déjà marquée comme "réalisée" → bouton désactivé.
La date du rendez-vous n’est pas encore passée → action impossible.

Scénario d’exception

Échec de mise à jour (problème réseau).
Tentative d’accès non autorisé.

Remarque

Cette action permet de tracer l’historique réel des prestations effectuées et de garantir une transparence côté client comme côté coiffeuse.
Elle est également utile pour déclencher la demande d’avis.

Figure 55. Diagramme d’activité : Marquer une prestation comme-REALISÉE

Figure 56. Diagramme de séquence : Marquer une prestation comme-REALISÉE

5.6.1. Écrans – Marquer une prestation comme-REALISÉE

5.7. UC_SC6 : Consulter les avis clients

Élément

Détail

Nom du cas d’utilisation

Consulter les avis clients

Description

Ce cas d’utilisation permet à la coiffeuse de consulter les évaluations et commentaires laissés par ses clientes après une prestation.
Ces avis contribuent à sa réputation sur la plateforme.

Acteurs

Coiffeuse, Backend Django, Base de données PostgreSQL

Précondition

La coiffeuse est connectée à l’application.
Elle a effectué au moins une prestation terminée.
Un ou plusieurs clients ont laissé un avis.

Postcondition

La coiffeuse a accès à la liste des retours clients associés à ses prestations.

Scénario nominal

La coiffeuse accède à la section "Mes avis".
L’application interroge le backend pour récupérer les avis liés à ses prestations.
Le backend retourne les données filtrées.
L’application affiche la note, le commentaire et le client associé pour chaque avis.

Scénario alternatif

Aucun avis n’est encore publié → afficher un message "Aucun avis pour le moment".

Scénario d’exception

Problème de connexion ou de récupération des données.
Tentative de récupération d’avis sans autorisation (sécurité).

Remarque

Les avis peuvent être triés ou filtrés (par date, note…).
Un système de modération ou de signalement peut être envisagé dans une version future.

Figure 57. Diagramme d’activité : Consulter les avis clients

Figure 58. Diagramme de séquence : Consulter les avis clients

5.7.1. Écrans – Consulter les avis clients

Avis

Ajout Avis

5.8. UC_SC7 : Gérer son image et sa galerie

Élément Détail

Nom du cas d’utilisation

Gérer son image et sa galerie

Description

Ce cas d’utilisation permet au propriétaire d’un salon de gérer les visuels liés à son établissement : logo principal, photos de la galerie, image de couverture, etc.

Acteurs

Propriétaire de salon, Backend Django, Base de données PostgreSQL,

Précondition

Le propriétaire est connecté.
Le salon est déjà créé et lié à la coiffeuse propriétaire.

Postcondition

Les fichiers image sont mis à jour et enregistrés.
Le logo et la galerie sont visibles sur la fiche du salon.

Scénario nominal

Le propriétaire accède à l’espace “Mon salon”.
Il clique sur “Modifier mes images”.
Il peut :
1. Télécharger un nouveau logo
2. Ajouter ou supprimer des images dans la galerie
L’application envoie les fichiers au backend.
Les images sont sauvegardées et liées au salon via les modèles TblSalon.logo_salon et TblSalonImage.
Une confirmation visuelle est affichée.

Scénario alternatif

Le propriétaire souhaite supprimer une image → suppression logique ou physique (selon politique de gestion).

Scénario d’exception

Fichier trop lourd ou non supporté.
Problème de stockage ou de permission.
Erreur lors de la suppression.

Remarque

Une limite de nombre d’images par salon est appliquée (via validate_max_images).
Une image par défaut est utilisée si aucun logo n’est fourni.

Figure 59. Diagramme d’activité : Gérer son image et sa galerie

Figure 60. Diagramme de séquence : Gérer son image et sa galerie

5.9. UC_SC8 : Consulter les paiements reçus

Élément Détail

Nom du cas d’utilisation

Consulter les paiements reçus

Description

Ce cas d’utilisation permet à une coiffeuse de consulter l’historique des paiements liés aux prestations qu’elle a réalisées, avec les détails des montants perçus et des statuts (payé, en attente, remboursé…).

Acteurs

Coiffeuse, Backend Django, Base de données PostgreSQL

Précondition

La coiffeuse est connectée.
Elle a effectué au moins une prestation validée et payée via la plateforme.

Postcondition

La coiffeuse a accès à la liste des paiements qui lui sont associés, classés ou filtrés.

Scénario nominal

La coiffeuse accède à la section “Mes paiements”.
L’application envoie une requête au backend pour récupérer ses paiements.
Le backend interroge la base PostgreSQL.
Les informations sont retournées et affichées à la coiffeuse.

Scénario alternatif

Aucun paiement encore reçu → afficher un message d’information.
Possibilité de filtrer par date ou statut.

Scénario d’exception

Erreur de requête backend.
Problème de connexion ou session expirée.

Remarque

Ce module permet à la coiffeuse de suivre sa rémunération et l’état de ses transactions.
Les montants affichés peuvent être extraits des objets TblPaiement et TblTransaction.

Figure 61. Diagramme d’activité : Consulter les paiements reçus

Figure 62. Diagramme de séquence : Consulter les paiements reçus

5.10. UC_SC9 : Consulter les statistiques / analytique

Élément

Détail

Nom du cas d’utilisation

Consulter les statistiques / analytique

Description

Ce cas d’utilisation permet à la coiffeuse (propriétaire) d’obtenir des statistiques personnalisées via une interface de conversation avec une IA.

Elle peut poser des questions (ex. : "Quels sont mes revenus ce mois-ci ?", "Quels services sont les plus demandés ?") et recevoir une réponse basée sur ses propres données.

Acteurs

Coiffeuse, Agent conversationnel IA, Backend Django, Base de données PostgreSQL

Précondition

La coiffeuse est connectée.
Un agent IA est intégré à la plateforme et connecté à la base via le backend.

Postcondition

La coiffeuse reçoit des réponses personnalisées basées sur ses données statistiques.
Les informations sont présentées sous forme de texte, tableaux simples ou graphiques selon le contexte.

Scénario nominal

La coiffeuse accède à la section "Statistiques IA".
Elle saisit une question en langage naturel.
L’IA interprète la demande et envoie une requête ciblée au backend.
Le backend interroge les données pertinentes (réservations, paiements, services…).
L’IA reçoit la réponse, la reformule et la transmet à la coiffeuse via le chat.

Scénario alternatif

L’IA ne comprend pas la demande → demande de reformulation.
L’IA propose des suggestions ou modèles de questions fréquentes.

Scénario d’exception

Problème de connexion avec le moteur IA.
Erreur de récupération des données statistiques.
Absence de données suffisantes pour générer une réponse pertinente.

Remarque

Ce système permet une approche flexible et intuitive de la consultation analytique.
Il remplace l’approche traditionnelle par tableau de bord par une interaction personnalisée et dynamique.

Figure 63. Diagramme d’activité : Consulter les statistiques / analytique

Figure 64. Diagramme de séquence : Consulter les statistiques / analytique

5.10.1. Écrans – Consulter les statistiques / analytique

Bouton vers l’assistant IA

Liste des conversations

Une conversation avec l’IA

5.11. UC_SC10 : Créer un compte coiffeuse

Élément Détail

Nom du cas d’utilisation

Créer un compte coiffeuse (PostgreSQL)

Description

Ce cas d’utilisation permet d’enregistrer dans la base de données toutes les informations personnelles, professionnelles et d’adresse d’une utilisatrice ayant choisi le rôle "coiffeuse", après avoir été authentifiée via Firebase.

Acteurs

Coiffeuse, Backend Django, Base de données PostgreSQL

Précondition

L’utilisatrice est déjà authentifiée via Firebase (UID disponible).
Elle a choisi le rôle “coiffeuse” dans le processus initial.
Le frontend a collecté les données du formulaire complet.

Postcondition

Les données sont enregistrées dans les tables hairbnb_tbladresse, hairbnb_tbluser et hairbnb_tblcoiffeuse.
Un email de confirmation est généré si requis.
Le compte professionnel est désormais exploitable dans le système Hairbnb.

Scénario nominal

La coiffeuse remplit le formulaire complet (données perso, pro et adresse).
L’application envoie une requête POST vers le backend Django avec toutes les données.
Le backend valide les données et vérifie l’unicité de l’email.
Une transaction atomique est initiée.
Le backend crée dans l’ordre :
1. L’adresse dans tbladresse
2. Le profil dans tbluser avec le lien UID Firebase
3. Le profil coiffeuse dans tblcoiffeuse
La transaction est validée si tout est cohérent.
Une réponse de succès est envoyée au frontend.

Scénario alternatif

Certaines données (ex : nom, email) peuvent être préremplies depuis Firebase.
En cas d’erreur de validation, le formulaire est renvoyé avec des messages explicites.

Scénario d’exception

Échec de transaction.
Problème réseau → message d’erreur au client.

Remarque

Ce processus respecte l’architecture 3 couches (UI, logique métier, BDD) et s’appuie sur les mécanismes sécurisés de Django (ORM, transaction).

Figure 65. Diagramme d’activité : Créer un compte coiffeuse

Figure 66. Diagramme de séquence : Créer un compte coiffeuse

5.11.1. Écrans – Créer un compte coiffeuse

Créer un compte avec google

Remplir les informations de la coiffeuse

l’api détécte l’adresse

Ajouter l’adresse

Ajouter le nom commercial

Passer a la page de la creation salon

Créer le salon de la coiffeuse

Remplir les informations du salon

Ajouter un service

5.12. UC_SC11 : Gérer les réservations

Élément Détail

Nom du cas d’utilisation

Gérer les réservations

Description

Ce cas d’utilisation permet à la coiffeuse (ou propriétaire) de consulter, accepter, refuser ou archiver les demandes de réservation reçues, en fonction de sa disponibilité et de la nature du service demandé.

Acteurs

Coiffeuse, Backend Django, Base de données PostgreSQL

Précondition

La coiffeuse est connectée et authentifiée.
Elle a reçu au moins une demande de réservation.
Les données sont disponibles dans la base.

Postcondition

Le statut des réservations est mis à jour (en attente, confirmée, refusée, réalisée, annulée).
Les actions déclenchent éventuellement des notifications vers les clients.

Scénario nominal

La coiffeuse accède à la section "Mes réservations".
Le système affiche la liste des réservations filtrées par statut ou date.
Elle consulte les détails d’une réservation.
Elle choisit une action : "Accepter", "Refuser" ou "Archiver".
L’application envoie la décision au backend.
Le backend met à jour le statut de la réservation.
Le client est notifié si nécessaire.
La nouvelle liste est affichée à jour.

Scénario alternatif

La coiffeuse filtre ses réservations par statut ou date.
Elle annule une réservation qu’elle avait acceptée → motif facultatif.

Scénario d’exception

Échec de chargement des données (erreur serveur).
Tentative de modification sur une réservation expirée ou déjà traitée.
Session expirée → redirection vers l’authentification.

Remarque

Les actions doivent être rapides, traçables et sécurisées.
Elles ont un impact direct sur l’expérience client et la planification.

Figure 67. Diagramme d’activité : Gérer les réservations

Figure 68. Diagramme de séquence : Gérer les réservations

5.12.1. Écrans – Gérer les réservations

Réservations actifs

Réservations archivées

5.13. UC_SC12 : Gérer les promotions

Élément

Détail

Nom du cas d’utilisation

Gérer les promotions

Description

Ce cas d’utilisation permet à la coiffeuse ou la propriétaire de salon de créer, modifier ou supprimer des promotions liées à ses services, afin d’attirer plus de clients ou de fidéliser.

Acteurs

Coiffeuse, Backend Django, Base de données PostgreSQL

Précondition

La coiffeuse est connectée et authentifiée.
Elle a déjà des services enregistrés.

Postcondition

Une ou plusieurs promotions sont ajoutées, modifiées ou supprimées dans la base de données.
Elles sont visibles dans le profil public du salon ou du service.

Scénario nominal

La coiffeuse accède à l’interface de gestion des promotions.
Elle clique sur "Ajouter une promotion" et renseigne les champs requis (date début/fin, service concerné, pourcentage).
Elle peut également modifier ou supprimer une promotion existante.
L’application envoie les données au backend.
Le backend enregistre les modifications dans PostgreSQL.
Une confirmation s’affiche à l’écran.

Scénario alternatif

La promotion est liée à un service en cours d’édition → message d’avertissement.
La promotion est deja activée.

Scénario d’exception

Les champs sont invalides ou incomplets → erreur de validation.
Problème réseau ou erreur serveur → message d’échec.

Remarque

Les promotions doivent être activables/désactivables à tout moment.
Elles ont un impact sur le tarif affiché dans le processus de réservation.

Figure 69. Diagramme d’activité : Gérer les promotions

Figure 70. Diagramme de séquence : Gérer les promotions

5.13.1. Écrans – Gérer les promotions

Botton vers les promotions

Listes des promotions

Ajouter une promotion

Le service avec une promotion

5.14. Diagramme d’activité global – Hairbnb (Coiffeuse & Propriétaire)

Figure 71. Diagramme d’activité global – Hairbnb (Coiffeuse & Propriétaire)

Afin de garantir une meilleure lisibilité du diagramme d’activité global, une version compacte et synthétique a été privilégiée.

Elle met en lumière les activités principales des deux rôles – coiffeuse et propriétaire – en les organisant par thématiques fonctionnelles (services, réservations, relation client, etc…).

Ce choix permet d’éviter une surcharge visuelle due à l’utilisation excessive de forks et de conditions, qui aurait nécessité de scinder le diagramme en plusieurs sous-parties.

Ainsi, le diagramme joue un rôle complémentaire, en fournissant une vue d’ensemble claire et cohérente, tandis que les scénarios détaillés de chaque UC ont été décrits plus haut dans le document.

5.15. Diagramme d’activité global – Hairbnb (Coiffeuse & Propriétaire)

Figure 72. Diagramme de séquence global – Hairbnb (Coiffeuse & Propriétaire)

Afin d’assurer la lisibilité et la clarté du diagramme de séquence global, une stratégie similaire à celle adoptée pour le diagramme d’activité a été appliquée.

Plutôt que de représenter chaque cas d’utilisation individuellement — ce qui aurait rendu le diagramme complexe, surchargé et difficile à interpréter —, nous avons privilégié une approche synthétique.

Le diagramme global se concentre sur les grandes interactions typiques entre les principaux composants du système Hairbnb :

L’utilisateur (coiffeuse ou propriétaire),
L’application mobile,
Le système Firebase (authentification, messagerie),
Le backend Django (logique métier),
La base de données PostgreSQL (persistance),
L’agent IA (consultation des statistiques).

Cette représentation condensée permet de fournir une vue d’ensemble structurée et cohérente du système, tout en conservant les détails propres à chaque UC dans leurs diagrammes dédiés.

6. L’analyse "L’administrateur" système

L’administrateur joue un rôle central dans la gestion du back-office de l’application Hairbnb.

C’est un acteur disposant de privilèges élevés, souvent comparé à un développeur ou un gestionnaire de plateforme.

Il :
- Supervise l’ensemble des interactions entre les coiffeuses et les clients,
- Veille à la modération des contenus,
- Gère les éventuels litiges et garantit un environnement sécurisé et de confiance pour tous les utilisateurs.

Son rôle ne se limite pas à un simple contrôle, mais inclut aussi la supervision des statistiques globales, la validation de certains profils, la gestion des signalements et le suivi de la qualité de service.

Il agit comme un garant de la conformité et de la fluidité de l’écosystème Hairbnb.

Cela dit, dans le cadre d’un travail de fin de formation, mon objectif n’est pas d’approfondir les fonctionnalités liées à l’administrateur, afin de ne pas élargir excessivement le périmètre fonctionnel du projet (lutte contre le "scope creep").

J’ai donc choisi d’illustrer cet acteur de manière moderne et conceptuelle, en optant pour une interaction via une interface conversationnelle : l’administrateur dialogue avec un chatbot alimenté par l’IA, qui exécute les requêtes nécessaires de façon automatisée.

Cette démarche s’inscrit dans une tendance actuelle d’automatisation intelligente, permettant de conserver la dimension stratégique sans alourdir le développement technique du MVP.

— Soulaiman

6.1. Diagramme de cas d’utilisation – Administrateur

Figure 73. Diagramme de cas d’utilisation : Administrateur Système

6.2. Synthèse des cas d’utilisation – Administrateur

Réf.

Nom du cas d’utilisation

Acteurs principaux

Objectif principal

UC_A1

Suivre l’activité de la plateforme

Administrateur, AI Agent

Visualiser les indicateurs globaux de performance, de trafic et d’usage de la plateforme.

UC_A2

Modérer les utilisateurs

Administrateur, AI Agent

Suspendre ou désactiver les comptes en cas de comportement inapproprié.

UC_A3

Superviser les incidents techniques

Administrateur, AI Agent

Suivre les erreurs critiques, logs et anomalies signalées sur l’infrastructure.

UC_A4

Gérer les accès administrateurs

Administrateur

Ajouter, retirer ou modifier les rôles et autorisations des autres comptes admin.

UC_A5

Gérer la modération des avis

Administrateur, AI Agent

Ssupprimer les avis publics laissés par les clients.

6.3. UC_A1 : Suivre l’activité de la plateforme

Élément

Détail

Nom du cas d’utilisation

Suivre l’activité de la plateforme

Description

Ce cas d’utilisation permet à l’administrateur de consulter les statistiques et indicateurs d’usage de la plateforme à travers une interface conversationnelle avec une IA.

Acteurs

Administrateur, Agent IA, Backend, Base de données

Précondition

L’administrateur est connecté avec les droits requis.

L’agent IA est accessible et connecté au backend.

Postcondition

Des statistiques sont extraites du backend et affichées à l’administrateur sous forme synthétique ou visuelle.

Scénario nominal

L’administrateur ouvre l’interface de chat.
Il saisit une requête de type : "Voir les statistiques d’utilisation de cette semaine".
L’IA interprète la requête et génère une commande vers le backend.
Le backend récupère les données correspondantes.
L’IA formate la réponse et la renvoie à l’administrateur dans la conversation.

Scénario alternatif

L’administrateur clique sur un raccourci d’indicateur (ex : "trafic journalier").

L’IA répond avec les données préconfigurées.

Scénario d’exception

L’IA ne comprend pas la requête → demande de reformulation.

Le backend ne retourne aucune donnée → message d’erreur.

Remarque

Cette fonctionnalité ne nécessite pas de tableau de bord classique ; elle mise sur une interaction fluide et contextualisée avec l’IA.

Figure 74. Diagramme d’activité : Suivre l’activité de la plateforme

Figure 75. Diagramme de séquence : Suivre l’activité de la plateforme

6.4. Ecrans – Suivre l’activité de la plateforme

Demander des statistiques

Demander un tableau des résultats

6.5. UC_A2 : Modérer les utilisateurs

Élément

Détail

Nom du cas d’utilisation

Modérer les utilisateurs

Description

Ce cas d’utilisation permet à l’administrateur de désactiver temporairement ou définitivement un compte utilisateur en cas d’abus, via une commande adressée à une IA.

Acteurs

Administrateur, Agent IA, Backend Django, Base de données

Précondition

L’administrateur est connecté et autorisé à modérer.

Le compte ciblé existe et est actif.

Postcondition

Le compte utilisateur est désactivé en base.

L’utilisateur concerné est notifié de sa suspension.

Scénario nominal

L’administrateur accède à l’interface de chat.
Il saisit une commande du type : "Suspendre le compte de user123 pour comportement abusif".
L’IA identifie l’utilisateur et vérifie son statut.
L’IA envoie la requête de suspension au backend.
Le backend désactive le compte.
Une confirmation est envoyée à l’administrateur.

Scénario alternatif

L’IA propose plusieurs correspondances si le nom est ambigu.

L’admin peut spécifier une durée ou une raison plus précise.

Scénario d’exception

L’ID utilisateur est introuvable.

Le backend retourne une erreur de droits ou de connexion.

Le compte est déjà suspendu.

Remarque

Ce cas d’utilisation s’inscrit dans une stratégie de supervision intelligente : l’IA agit comme un intermédiaire entre l’humain et le système pour faciliter la modération.

Figure 76. Diagramme d’activité : Modérer les utilisateurs

Figure 77. Diagramme de séquence : Modérer les utilisateurs

6.6. UC_A3 : Superviser les incidents techniques

Élément

Détail

Nom du cas d’utilisation

Superviser les incidents techniques

Description

Ce cas d’utilisation permet à l’administrateur de suivre les erreurs critiques, logs et anomalies techniques signalées automatiquement par l’infrastructure, via une interface d’analyse pilotée par une IA.

Acteurs

Administrateur, Agent IA, Backend, Outils de monitoring

Précondition

L’administrateur est connecté et a les autorisations requises.

Les outils de monitoring sont actifs et correctement intégrés au backend.

Postcondition

Les logs et incidents récents sont affichés ou signalés.

L’administrateur peut consulter ou archiver les incidents signalés.

Scénario nominal

L’administrateur accède à l’espace de conversation avec l’IA.
Il saisit une requête comme : "Montre-moi les erreurs critiques du jour".
L’IA génère une requête backend pour interroger les logs.
Les incidents sont extraits et analysés.
L’IA présente une synthèse lisible à l’administrateur (liste, gravité, timestamp, origine).
Option : l’admin peut cliquer sur un log pour en voir le détail.

Scénario alternatif

L’IA détecte automatiquement une anomalie et notifie l’admin sans requête manuelle.

Des incidents sont classés par priorité ou par module technique.

Scénario d’exception

Aucune donnée de log n’est disponible → message d’indisponibilité.

Erreur de récupération depuis les outils de monitoring → message d’échec.

Requête IA mal formulée → suggestion de reformulation.

Remarque

L’objectif est de proposer une supervision proactive et intelligente, sans imposer une interface de surveillance complexe.
Le chatbot agit ici comme un point d’entrée unique pour toutes les demandes techniques.

6.7. Diagramme d’activité : Superviser les incidents techniques (UC_A3)

Figure 78. Diagramme d’activité : Superviser les incidents techniques

6.8. Diagramme de séquence : Superviser les incidents techniques (UC_A3)

Figure 79. Diagramme de séquence : Superviser les incidents techniques

6.9. UC_A4 : Suivre l’activité de la plateforme

Élément

Détail

Nom du cas d’utilisation

Gérer les accès administrateurs

Description

Ce cas d’utilisation permet à un administrateur principal d’attribuer ou de révoquer les droits d’administration à d’autres utilisateurs via une interface dédiée, sans passer par le chatbot.

Acteurs

Administrateur, Backend, Base de données PostgreSQL

Précondition

L’administrateur est connecté et dispose des autorisations nécessaires.
L’utilisateur ciblé est déjà enregistré sur la plateforme.

Postcondition

Le rôle administrateur est attribué ou retiré à un utilisateur.
La modification est persistée en base.

Scénario nominal

L’administrateur accède à l’espace "Gestion des accès".
Il consulte la liste des utilisateurs.
Il sélectionne un utilisateur.
Il clique sur "Attribuer les droits admin" (ou les retire).
Le système vérifie ses propres droits.
Le backend met à jour le rôle dans la base.
Une confirmation s’affiche.

Scénario alternatif

L’administrateur retire les droits d’un utilisateur admin.
Il consulte un historique d’attribution de rôles.

Scénario d’exception

L’administrateur ne dispose pas des autorisations suffisantes → accès refusé.
Échec de mise à jour en base → message d’erreur.
Utilisateur ciblé inexistant ou déjà administrateur.

Remarque

Cette fonctionnalité repose sur une gestion sécurisée des rôles.
Elle est accessible uniquement aux administrateurs ayant le niveau "superadmin" si cette granularité est prévue dans l’application.

6.9.1. Diagramme d’activité : Gérer les accès administrateurs (UC_A4)

Figure 80. Diagramme d’activité : Gérer les accès administrateurs

6.9.2. Diagramme de séquence : Gérer les accès administrateurs (UC_A4)

Figure 81. Diagramme de séquence : Gérer les accès administrateurs

6.10. UC_A5 : Gérer la modération des avis

Élément

Détail

Nom du cas d’utilisation

Gérer la modération des avis

Description

Ce cas d’utilisation permet à l’administrateur de consulter les avis publiés par les clients sur les coiffeuses ou les salons, et de supprimer ceux jugés inappropriés ou contraires aux règles de la plateforme.
La demande est transmise à un agent conversationnel (IA), qui interprète l’ordre et exécute la suppression via le backend.

Acteurs

Administrateur, IA, Backend, Base de données

Précondition

L’administrateur est connecté et autorisé à modérer les contenus.
L’IA a accès aux avis via les API backend.

Postcondition

L’avis est supprimé ou marqué comme modéré dans la base de données.
Une trace d’action est conservée dans les logs de modération.

Scénario nominal

L’administrateur accède à l’espace de modération (via l’interface IA ou menu dédié).
Il consulte la liste des avis récents ou signalés.
Il sélectionne un avis à supprimer ou à masquer.
L’IA interprète la commande (ex. : "Supprime l’avis 152").
Une requête est envoyée au backend pour mise à jour.
L’avis est supprimé ou marqué comme inactif.
Une confirmation est renvoyée à l’administrateur.

Scénario alternatif

L’IA propose une pré-analyse (score de toxicité, mots-clés suspects, etc.) pour aider à la décision.
L’avis est archivé au lieu d’être supprimé, selon les règles internes.

Scénario d’exception

L’avis est introuvable ou déjà supprimé.
Problème de communication entre l’IA et le backend.
L’administrateur n’a pas les droits requis.

Remarque

Ce processus renforce la confiance des utilisateurs et garantit un environnement de publication sain et respectueux.

6.10.1. Diagramme d’activité : Gérer la modération des avis (UC_A5)

Figure 82. Diagramme d’activité : Gérer la modération des avis

6.10.2. Diagramme de séquence : Gérer la modération des avis (UC_A5)

Figure 83. Diagramme de séquence : Gérer la modération des avis

7. Conclusion de l’analyse système

Dans cette section consacrée à l’analyse système, j’ai veillé à fournir une modélisation aussi claire et cohérente que possible.

L’objectif principal était de rendre cette partie lisible, structurée, et directement exploitable pour les phases de conception et de développement à venir.

J’ai fait le choix de limiter volontairement les blocs de texte trop longs afin de préserver une lecture fluide, tout en apportant les définitions nécessaires lorsqu’elles s’avéraient pertinentes.

Les éléments plus terminologiques, spécifiques ou répétitifs seront explicités de manière centralisée dans une section dédiée au lexique, afin de ne pas alourdir cette partie.

Cette analyse s’est concentrée sur la modélisation fonctionnelle à travers différents types de diagrammes UML (cas d’utilisation, activités, séquences), dans une logique d’expressivité orientée utilisateur.

Elle permet de cadrer les interactions majeures, les rôles clés et les processus applicatifs essentiels du projet Hairbnb.

Enfin, il est important de noter que cette étape de modélisation ne constitue qu’un deuxiéme volet.

Elle sera complétée ultérieurement par une analyse orientée données, à travers une méthode adaptée (MERISE), qui viendra structurer la base de données relationnelle PostgreSQL et renforcer l’articulation backend ↔ logique métier.

Je dois reconnaître que cette partie de l’analyse système a été particulièrement exigeante.

Elle m’a demandé beaucoup d’efforts, de rigueur, et surtout de persévérance.

Le travail a parfois été long, répétitif, et pas toujours motivant — mais je reste convaincu qu’il était nécessaire d’aller aussi loin pour poser des bases solides et structurées.

Il est possible que la qualité de rédaction ou de présentation varie légèrement entre le début et la fin de cette section, reflet naturel de la fatigue accumulée au fil des jours.

Néanmoins, parvenir au bout de cette phase est pour moi une réelle source de soulagement et de satisfaction.

J’espère que la lecture de cette partie, malgré sa densité, ne s’est pas révélée trop lourde ou ennuyeuse.

Merci à ceux qui prendront le temps de la parcourir avec attention.

— Note personnelle – Soulaiman

8. Lexique des termes techniques

Terme technique

Définition

API (Application Programming Interface)

Interface de programmation permettant à différentes applications de communiquer entre elles via des protocoles standardisés.

Backend

Partie serveur d’une application qui gère la logique métier, les bases de données et les traitements côté serveur, invisible pour l’utilisateur final.

Base de données relationnelle

Système de gestion de base de données organisant les informations en tables liées par des relations, permettant l’intégrité et la cohérence des données.

BPMN (Business Process Model and Notation)

Standard de modélisation graphique pour représenter les processus métier de manière visuelle et standardisée.

Cloud

Infrastructure informatique accessible via Internet, permettant le stockage et le traitement de données sur des serveurs distants.

Credential stuffing

Attaque informatique consistant à utiliser massivement des combinaisons login/mot de passe volées pour accéder à des comptes utilisateurs.

Django

Framework web Python open-source suivant le pattern Model-View-Template, facilitant le développement rapide d’applications web sécurisées.

FCM (Firebase Cloud Messaging)

Service de Google permettant l’envoi de notifications push gratuitement vers des applications mobile et web.

Firebase

Plateforme de développement d’applications mobiles et web de Google, offrant des services backend comme l’authentification, les bases de données et l’hébergement.

Firestore

Base de données NoSQL en temps réel de Firebase, permettant la synchronisation automatique des données entre clients.

Flutter

Framework de développement d’applications mobiles créé par Google, permettant de créer des apps natives pour iOS et Android avec un seul code source.

Fork (diagramme d’activité)

Élément UML représentant la division d’un flux d’activité en plusieurs branches parallèles, symbolisé par une barre horizontale.

Framework

Structure logicielle réutilisable fournissant des fonctionnalités de base pour développer des applications, réduisant le temps de développement.

Frontend

Partie client d’une application avec laquelle l’utilisateur interagit directement, incluant l’interface utilisateur et l’expérience utilisateur.

Géolocalisation

Technologie permettant de déterminer la position géographique d’un dispositif à l’aide de GPS, Wi-Fi ou données de réseau mobile.

HTTPS

Protocole de communication sécurisé basé sur HTTP, utilisant le chiffrement SSL/TLS pour protéger les échanges de données.

JWT (JSON Web Token)

Standard ouvert pour transmettre des informations de manière sécurisée entre parties sous forme de token JSON signé numériquement.

ORM (Object-Relational Mapping)

Technique de programmation permettant de manipuler une base de données relationnelle en utilisant des objets plutôt que du SQL direct.

OAuth 2.0

Protocole d’autorisation permettant à une application d’accéder aux ressources d’un utilisateur sans connaître ses identifiants.

PCI-DSS

Standard de sécurité pour les entreprises qui traitent des informations de cartes de crédit, garantissant la protection des données financières.

PostgreSQL

Système de gestion de base de données relationnelle open-source, réputé pour sa robustesse et ses fonctionnalités avancées.

Push notification

Message envoyé automatiquement par une application vers l’appareil d’un utilisateur, même quand l’application n’est pas active.

REST API

Architecture pour les services web utilisant les méthodes HTTP standard (GET, POST, PUT, DELETE) pour les opérations sur les ressources.

SDK (Software Development Kit)

Ensemble d’outils de développement permettant d’intégrer des fonctionnalités spécifiques dans une application.

SMTP

Protocole standard pour l’envoi d’emails sur Internet, gérant l’acheminement des messages entre serveurs de messagerie.

SPF (Sender Policy Framework)

Mécanisme d’authentification email permettant de vérifier qu’un email provient bien du serveur autorisé par le domaine expéditeur.

SQL

Langage de programmation standardisé pour gérer et manipuler les bases de données relationnelles.

SSL/TLS

Protocoles cryptographiques assurant la sécurité des communications sur Internet en chiffrant les données échangées.

Stripe

Plateforme de paiement en ligne permettant aux entreprises d’accepter des paiements par carte bancaire de manière sécurisée.

Timeout

Délai d’attente maximal pour une opération, après lequel le système considère que l’opération a échoué.

Token

Chaîne de caractères sécurisée utilisée pour authentifier un utilisateur ou autoriser l’accès à des ressources sans révéler les identifiants.

UML (Unified Modeling Language)

Langage de modélisation graphique standardisé utilisé pour spécifier, visualiser et documenter les systèmes logiciels.

UID (User Identifier)

Identifiant unique attribué à chaque utilisateur dans un système, permettant de le distinguer de manière univoque.

UI/UX (User Interface/User Experience)

Conception de l’interface utilisateur (UI) et optimisation de l’expérience utilisateur (UX) pour améliorer l’utilisabilité d’une application.

Webhook

Mécanisme permettant à une application d’envoyer automatiquement des données à une autre application lors d’événements spécifiques.

9. Sources et références

Type

Titre/Description

Source

Année

Méthodologie UML

UML 2.5.1 Specification - Unified Modeling Language

Object Management Group (OMG)

2017

Méthodologie UML

What is Activity Diagram? - UML Activity Diagram Tutorial

Visual Paradigm

2024

Méthodologie UML

Qu’est-ce qu’un diagramme de séquence UML ? - Guide complet

Miro

2024

Analyse système

Analyse de système - Définition et méthodologie

Office québécois de la langue française

2024

Tutorial YouTube

Firebase Darija

YouTube - GOTOCODE

2021

Tutorial YouTube

Stripe Payment Integration Tutorial

YouTube - Web Dev Simplified

2023

Tutorial YouTube

API Design Best Practices

YouTube - Hussein Nasser

2024

Tutorial YouTube

Cours Complet et exercice sur Astah UML

YouTube - Prof. Fatimazahra BARRAMOU

2021

Tutorial YouTube

Cours UML

YouTube - Abdelkhalek BENHOUMINE

2020

Documentation API

Stripe API Reference - Payment Methods

Stripe Developers

2024

Documentation API

Firebase Admin SDK Documentation

Google Cloud

2024

9.1. Notes sur les sources

9.1.1. Sources YouTube

Les tutoriels issus de YouTube ont été principalement utilisés dans un objectif pédagogique, à savoir :

Réviser les principes fondamentaux de la modélisation UML.
Apprendre mieux à utiliser des outils comme Astah pour la création de diagrammes.
Approfondir certains concepts via des contenus en langue arabe (ma langue maternelle), afin de faciliter leur compréhension.
Réduire l’effort cognitif lié à l’apprentissage en accédant à des explications plus intuitives, souvent illustrées de cas concrets.

9.1.2. Sources académiques

Les ressources académiques et les standards reconnus ont servi de socle théorique pour :

Structurer l’analyse système selon des normes rigoureuses (selon ma degree de comprehension).
Comprendre et intégrer les spécifications techniques des protocoles et méthodes utilisés.
S’appuyer sur des méthodologies UML standardisées dans le domaine de l’ingénierie logicielle.

9.1.3. Sources techniques et pratiques

Les documentations officielles et articles spécialisés ont joué un rôle fondamental pour :

L’implémentation concrète des fonctionnalités définies dans le cahier des charges.
La résolution de problèmes techniques spécifiques rencontrés lors du développement.
L’optimisation des performances de l’application Hairbnb.
Le respect (selon ma degree de comprehension) des bonnes pratiques industrielles dans les technologies employées (Django, Flutter, Firebase, PostgreSQL…).

Méthodologie de traitement des sources :

Copie directe : certaines définitions jugées claires et pertinentes ont été reprises telles quelles depuis leurs sources officielles.
Compression assistée par IA : pour les contenus trop denses ou techniques, une synthèse a été effectuée à l’aide de l’intelligence artificielle afin d’en extraire l’essentiel tout en préservant la rigueur.
Validation personnelle : chaque contenu issu d’une source externe a été relu, validé et, si nécessaire, reformulé pour s’assurer de sa pertinence dans le contexte du projet.
Utilisation transversale : les sources listées ici ont souvent été mobilisées dans plusieurs sections du document, en particulier pour les aspects techniques et la documentation des technologies utilisées dans Hairbnb.