TRAVAUX DIRIGÉS DE SYSTÈME D'INFORMATION

SÉRIE D'ÉTUDES DE CAS - UML

SERIE 2
CLASSE DE Tle TI
Lycée scientique de Bertoua
Enseignant : M. BLOUM Leon
Décembre, 2025
Diagrammes de Cas d'Utilisation et de Séquence

ÉTUDE DE CAS 1 : SYSTÈME DE GESTION DE BIBLIOTHÈQUE

UNIVERSITAIRE

Une bibliothèque universitaire souhaite informatiser son système de gestion. Le système doit
permettre aux étudiants et enseignants d'emprunter des documents, et au personnel de gérer le fonds
documentaire. Les étudiants et enseignants peuvent consulter le catalogue en ligne, réserver des
documents disponibles et emprunter des ouvrages. Les étudiants ont droit à 3 emprunts simultanés
pour une durée de 2 semaines. Les enseignants ont droit à 10 emprunts simultanés pour une durée
de 2 mois. Les bibliothécaires peuvent enregistrer les emprunts et les retours, gérer les retards (envoi
automatique de rappels), et ajouter de nouveaux documents au catalogue. Le responsable de la
bibliothèque peut, en plus des fonctions du bibliothécaire, générer des statistiques d'emprunt et gérer
les acquisitions de nouveaux ouvrages. Avant tout emprunt, le système doit vérier la disponibilité
du document. Si un document est en retard, une pénalité nancière est calculée automatiquement. Le
système envoie automatiquement des rappels par email 3 jours avant la date de retour. Les utilisateurs
peuvent renouveler un emprunt en ligne si le document n'est pas réservé par un autre utilisateur.
Travail demandé :
1. Identication des acteurs
 Identier et lister tous les acteurs du système
 Préciser pour chacun s'il s'agit d'un acteur principal ou secondaire
 Justier les relations de généralisation entre acteurs si nécessaire
2. Recensement des cas d'utilisation
 Lister tous les cas d'utilisation du système
 Classer les cas d'utilisation par acteur
 Identier les cas d'utilisation communs à plusieurs acteurs
3. Diagramme de cas d'utilisation
 Représenter le diagramme complet de cas d'utilisation
 Faire ressortir toutes les relations possibles : Relations d'association (acteur-cas), Re-
lations d'inclusion (<<include>>), Relations d'extension (<<extend>>), Relations de
généralisation (entre acteurs)
 Justier chaque type de relation utilisée
4. Description d'un scénario

1
Le savoir ne prend pas de congé - reste curieux, même en célébrant.
  Décrire le scénario nominal du cas "Emprunter un document" pour un étudiant
 Décrire au moins 2 scénarios alternatifs (document indisponible, utilisateur avec retards)
 Identier les pré-conditions et post-conditions

ÉTUDE DE CAS 2 : PLATEFORME DE RÉSERVATION DE TRANS-

PORT EN LIGNE

Une entreprise de transport souhaite développer une plateforme en ligne permettant aux clients de
réserver des billets de bus, train ou avion. Les visiteurs peuvent consulter les horaires et les tarifs sans
s'inscrire. Pour eectuer une réservation, un visiteur doit d'abord créer un compte et devenir client.
Les clients peuvent : Rechercher des trajets selon diérents critères (origine, destination, date, heure),
Comparer les prix entre diérents modes de transport, Eectuer une réservation (choix du siège si
disponible), Payer en ligne par carte bancaire ou mobile money, Recevoir leur billet électronique par
email et SMS, Consulter l'historique de leurs réservations, Annuler une réservation (avec ou sans
frais selon le délai), Modier une réservation (sous conditions). Les clients VIP (plus de 10 voyages)
bénécient de réductions automatiques de 15%. Le paiement en ligne nécessite une vérication auprès
du système bancaire. Après chaque paiement réussi, une conrmation est envoyée au service de
messagerie (email et SMS). Les agents de l'entreprise peuvent : Eectuer des réservations au nom
des clients (par téléphone ou au guichet), Consulter toutes les réservations, Traiter les demandes de
remboursement. Le gestionnaire peut, en plus des fonctions d'agent : Gérer les tarifs et les promotions,
Générer des rapports de ventes, Gérer les itinéraires et horaires.
Travail demandé :
1. Identication des acteurs
 Identier tous les acteurs humains et systèmes externes
 Établir la hiérarchie entre les acteurs
 Représenter les relations de généralisation
2. Liste des cas d'utilisation
 Recenser tous les cas d'utilisation principaux
 Identier les cas d'utilisation inclus (obligatoires)
 Identier les cas d'utilisation étendus (optionnels)
3. Diagramme de cas d'utilisation complet
 Représenter le diagramme avec tous les acteurs et cas
 Utiliser les relations <<include>> pour les cas obligatoires
 Utiliser les relations <<extend>> pour les cas optionnels
 Montrer les généralisations d'acteurs
4. Scénarios détaillés
 Scénario nominal : "Réserver un billet de bus" (client normal)
 Scénario alternatif 1 : Paiement refusé par la banque
 Scénario alternatif 2 : Aucun siège disponible pour la date choisie
5. Diagramme de séquence
 Construire le diagramme de séquence pour "Réserver un billet avec paiement réussi"
 Inclure tous les objets : Client, Interface, Gestionnaire de réservation, Système bancaire,
Service de messagerie
 Préciser le type de chaque message (synchrone, asynchrone, retour)

2
Le savoir ne prend pas de congé - reste curieux, même en célébrant.
ÉTUDE DE CAS 3 : SYSTÈME DE GESTION D'UN RESTAURANT

Un restaurant souhaite informatiser la prise de commandes et la gestion de la cuisine. Le client

arrive au restaurant et consulte le menu (papier ou tablette). Le serveur prend la commande du
client sur une tablette. La commande est automatiquement envoyée à la cuisine selon le type de
plat : Les entrées et salades vont au poste entrées froides, Les plats chauds vont au poste cuisine
chaude, Les desserts vont au poste pâtisserie, Les boissons vont directement au bar. Chaque cuisinier
spécialisé reçoit les commandes de son poste et marque les plats comme "en préparation" puis "prêts".
Le chef de cuisine supervise toutes les préparations et peut voir l'état d'avancement de toutes les
commandes. Quand tous les plats d'un service sont prêts, le serveur est notié. Le serveur marque
les plats comme "servis" une fois déposés à table. À la n du repas, le serveur génère l'addition. Le
client peut payer : En espèces au serveur, Par carte bancaire (terminal de paiement connecté), Par
mobile money. Le paiement par carte nécessite une validation du centre de paiement électronique.
Le manager peut consulter les statistiques de vente, gérer le menu (ajouter/modier/supprimer des
plats), gérer les stocks d'ingrédients et éditer les rapports journaliers. En n de journée, le système
génère automatiquement le rapport de caisse.
Travail demandé :
1. Acteurs du système
 Identier tous les acteurs
 Distinguer acteurs principaux et secondaires
 Justier la hiérarchie entre serveur et manager
2. Cas d'utilisation
 Lister tous les cas d'utilisation
 Regrouper par acteur
 Identier les dépendances entre cas
3. Diagramme de cas d'utilisation
 Représenter le diagramme complet
 Utiliser la relation <<include>> pour "Envoyer commande à la cuisine" (obligatoire
après prise de commande)
 Utiliser la relation <<extend>> pour "Gérer les stocks" (optionnel après consultation
des statistiques)
4. Description de scénarios
 Scénario nominal complet : "Passer une commande et payer par carte"
 Scénario alternatif 1 : Plat non disponible (rupture de stock)
 Scénario alternatif 2 : Paiement par carte refusé
5. Diagrammes de séquence
 Construire le diagramme de séquence pour "Passer une commande" (de la prise de com-
mande jusqu'à la notication cuisine)
 Préciser les types de messages : Messages synchrones (avec attente de réponse), Messages
asynchrones (sans attente), Messages de retour

3
Le savoir ne prend pas de congé - reste curieux, même en célébrant.
ÉTUDE DE CAS 4 : SYSTÈME DE GESTION D'UNE CLINIQUE MÉ-

DICALE

Une clinique privée souhaite informatiser la gestion des consultations, des dossiers patients et
de la facturation. Le patient peut prendre rendez-vous en ligne ou par téléphone via la secrétaire.
Pour prendre rendez-vous en ligne, le patient doit d'abord créer un compte (nouveau patient) ou
se connecter (ancien patient). Lors de la prise de rendez-vous, le système vérie la disponibilité du
médecin. Le patient peut consulter, modier ou annuler ses rendez-vous en ligne. Un rappel automa-
tique est envoyé par SMS 24h avant le rendez-vous via le service SMS. Le jour de la consultation :
La secrétaire enregistre l'arrivée du patient, Le médecin consulte le dossier médical du patient, Le
médecin eectue l'examen et met à jour le dossier médical (symptômes, diagnostic, prescriptions),
Le médecin peut prescrire des examens complémentaires (analyses, radiographies, etc.), Le médecin
imprime l'ordonnance. Si des examens sont prescrits : Le technicien de laboratoire enregistre les résul-
tats d'analyses, Le radiologue enregistre les résultats d'imagerie, Les résultats sont automatiquement
ajoutés au dossier du patient, Le médecin est notié de la disponibilité des résultats. La secrétaire
génère la facture de consultation et l'édite. Le patient règle la facture : En espèces, Par chèque,
Par carte bancaire (validation avec le système bancaire), Via son assurance (envoi électronique à la
compagnie d'assurance). Le directeur de la clinique peut : Gérer les emplois du temps des médecins,
Consulter les statistiques de consultation, Générer les rapports nanciers, Gérer les utilisateurs du
système.
Travail demandé :
1. Identication des acteurs
 Lister tous les acteurs humains et systèmes
 Classer par type (principal/secondaire)
 Identier les relations de généralisation possibles
2. Recensement des cas d'utilisation
 Lister tous les cas d'utilisation du système
 Identier les cas d'utilisation communs à plusieurs acteurs
 Identier les cas qui en incluent d'autres obligatoirement
 Identier les cas qui en étendent d'autres optionnellement
3. Diagramme de cas d'utilisation
 Représenter le diagramme complet avec tous les acteurs et cas
 Montrer clairement les relations <<include>>
 Montrer clairement les relations <<extend>>
 Montrer les généralisations d'acteurs
 Justier chaque relation
4. Scénarios détaillés
 Scénario nominal : "Consultation médicale complète" (de la prise de RDV au paiement)
 Scénario alternatif 1 : Patient en retard, modication du rendez-vous
 Scénario alternatif 2 : Examens complémentaires prescrits
5. Diagrammes de séquence
 Diagramme 1 : "Prise de rendez-vous en ligne par un nouveau patient"
 Diagramme 2 : "Consultation avec prescription d'examens et paiement par assurance"
 Préciser pour chaque message : type (synchrone/asynchrone/retour) et nom du message

4
Le savoir ne prend pas de congé - reste curieux, même en célébrant.
ÉTUDE DE CAS 5 : PLATEFORME E-LEARNING

Une université veut développer une plateforme d'apprentissage en ligne permettant aux ensei-
gnants de créer des cours et aux étudiants de les suivre. Les visiteurs peuvent consulter le catalogue
des cours disponibles. Pour s'inscrire à un cours, un visiteur doit créer un compte et devenir étu-
diant. Les étudiants peuvent : S'inscrire à un ou plusieurs cours (gratuits ou payants), Pour les cours
payants, eectuer le paiement via le système de paiement en ligne, Consulter les contenus du cours
(vidéos, documents PDF, présentations), Télécharger les ressources pédagogiques, Participer aux fo-
rums de discussion du cours, Soumettre les devoirs avant la date limite, Passer les quiz et examens
en ligne, Consulter leurs notes et leur progression, Obtenir un certicat si toutes les conditions sont
remplies (note ≥ 60%). Les enseignants peuvent : Créer et publier des cours, Organiser le cours en
modules et leçons, Ajouter diérents types de contenus (vidéos, documents, quiz), Créer des quiz avec
correction automatique, Créer des devoirs avec date limite, Corriger les devoirs soumis et attribuer
des notes, Consulter les statistiques de progression des étudiants, Modérer les forums de discussion,
Générer les certicats pour les étudiants ayant réussi. Les modérateurs peuvent : Superviser tous
les forums, Supprimer les messages inappropriés, Suspendre temporairement des utilisateurs. L'ad-
ministrateur de la plateforme peut : Gérer tous les utilisateurs (création, suppression, modication),
Valider les nouveaux cours avant publication, Consulter toutes les statistiques de la plateforme, Gé-
rer les catégories de cours, Congurer les paramètres du système. Lorsqu'un devoir est soumis, le
système vérie automatiquement le respect de la date limite. Lorsqu'un quiz est complété, le système
calcule automatiquement la note. Des notications automatiques sont envoyées pour : Rappeler les
dates limites de devoirs (3 jours avant), Annoncer la publication de nouveaux contenus, Informer de
la disponibilité d'une note.
Travail demandé :
1. Acteurs
 Identier et lister tous les acteurs
 Établir la hiérarchie (généralisations)
 Distinguer acteurs internes et externes
2. Cas d'utilisation
 Recenser tous les cas d'utilisation
 Les classer par acteur
 Identier les cas nécessitant une authentication préalable
3. Diagramme de cas d'utilisation
 Représenter le diagramme complet
 Utiliser <<include>> pour "S'authentier" (requis pour toute action d'étudiant/enseignant)
 Utiliser <<extend>> pour "Télécharger ressources" (optionnel après consultation)
 Montrer toutes les autres relations pertinentes
4. Scénarios
 Scénario nominal : "Étudiant passe un quiz et obtient sa note"
 Scénario alternatif 1 : "Étudiant soumet un devoir en retard"
 Scénario alternatif 2 : "Paiement d'un cours échoue"
5. Diagrammes de séquence
 Construire le diagramme pour "Soumettre un devoir"
 Inclure : Étudiant, Interface Web, Gestionnaire de cours, Base de données, Service de
notication
 Préciser les types de messages
5
Le savoir ne prend pas de congé - reste curieux, même en célébrant.
ÉTUDE DE CAS 6 : SYSTÈME DE GESTION D'UN HÔTEL

Un hôtel 4 étoiles souhaite moderniser son système de gestion pour améliorer l'expérience client
et optimiser les opérations. Les clients peuvent : Consulter les chambres disponibles sur le site web,
Faire une réservation en ligne (avec ou sans compte), Choisir le type de chambre (simple, double,
suite), Ajouter des services supplémentaires (petit-déjeuner, spa, parking), Payer un acompte par
carte bancaire (30% du montant total), Recevoir une conrmation de réservation par email, Modier
ou annuler leur réservation (selon les conditions). Le paiement en ligne nécessite une validation du
système bancaire. Les réceptionnistes peuvent : Eectuer le check-in des clients (vérication de la
réservation, remise des clés), Enregistrer les informations d'identité du client, Eectuer le check-
out (calcul du montant total, encaissement du solde), Traiter les réservations téléphoniques, Gérer
les demandes spéciales des clients, Consulter l'état d'occupation des chambres. Lors du check-in,
le système vérie automatiquement la disponibilité de la chambre. Le personnel de ménage peut :
Consulter la liste des chambres à nettoyer, Marquer une chambre comme nettoyée, Signaler des
problèmes de maintenance. Le service technique peut : Consulter les demandes de maintenance,
Marquer les interventions comme résolues. Le gérant de l'hôtel peut : Consulter le taux d'occupation
et les statistiques, Gérer les tarifs (prix des chambres, variations saisonnières), Créer des promotions
et réductions, Gérer les employés du système, Générer des rapports nanciers, Consulter les avis
clients. Un système de gestion des chambres intelligentes permet : Le contrôle automatique de la
climatisation selon la présence, L'ouverture des portes avec carte magnétique (validation auprès du
système de contrôle d'accès). Le système envoie automatiquement des emails de rappel 2 jours avant
l'arrivée. Les clients peuvent laisser un avis après leur séjour.
Travail demandé :
1. Identication
 Lister tous les acteurs (internes, externes, systèmes)
 Montrer les généralisations entre acteurs
2. Cas d'utilisation
 Recenser tous les cas
 Identier les relations de dépendance
 Préciser les cas obligatoires vs optionnels
3. Diagramme complet
 Représenter le diagramme de cas d'utilisation
 Inclure toutes les relations appropriées
 Justier l'utilisation de chaque relation
4. Scénarios
 Scénario complet : "Réservation en ligne avec services supplémentaires"
 Scénario alternatif : "Check-in avec problème de chambre non nettoyée"
5. Diagramme de séquence
 "Processus de check-out avec paiement par carte"
 Inclure tous les acteurs et systèmes impliqués
 Préciser types de messages

6
Le savoir ne prend pas de congé - reste curieux, même en célébrant.
ÉTUDE DE CAS 7 : SYSTÈME DE GESTION D'UNE SALLE DE SPORT

Une salle de sport moderne souhaite digitaliser la gestion des abonnements, des cours collectifs
et du suivi des membres. Les visiteurs peuvent consulter les ores d'abonnement et les horaires des
cours collectifs. Pour s'inscrire, un visiteur remplit un formulaire et devient membre après validation.
Les membres peuvent : Accéder à la salle en badgeant à l'entrée (le système de contrôle d'accès
vérie la validité de l'abonnement), Réserver des cours collectifs (yoga, tness, spinning, etc.) dans
la limite des places disponibles, Annuler une réservation jusqu'à 2h avant le cours, Consulter leur
historique de présence, Renouveler leur abonnement en ligne, Réserver des séances avec un coach
personnel (membres premium uniquement). Le paiement des abonnements se fait : Par carte bancaire
en ligne (validation par le système bancaire), En espèces à l'accueil, Par prélèvement automatique
mensuel (pour abonnements annuels). Les coachs peuvent : Créer et publier des cours collectifs,
Dénir le nombre maximum de participants, Consulter la liste des inscrits à leurs cours, Marquer la
présence eective des participants, Gérer leurs disponibilités pour les séances personnelles, Créer des
programmes d'entraînement personnalisés pour leurs clients. Les nutritionnistes (service premium)
peuvent : Consulter les prols des membres premium, Créer des plans alimentaires personnalisés,
Suivre l'évolution des membres. Le personnel d'accueil peut : Enregistrer les nouveaux membres,
Gérer les renouvellements d'abonnements, Traiter les réclamations, Vendre des accessoires (bouteilles,
serviettes, cadenas). Le gérant peut : Consulter les statistiques de fréquentation, Gérer les tarifs et
promotions, Gérer les équipements et planier leur maintenance, Consulter les rapports nanciers,
Gérer les employés (coachs, nutritionnistes, personnel), Envoyer des newsletters aux membres. Le
système envoie automatiquement : Un rappel 1h avant un cours réservé (SMS via service SMS), Une
alerte 7 jours avant l'expiration d'un abonnement, Des félicitations après 10 présences consécutives.
Si un membre ne se présente pas à 3 cours réservés sans annulation, il est temporairement bloqué
des réservations.
Travail demandé :
1. Acteurs
 Identier tous les acteurs
 Justier la distinction entre membre et membre premium
 Montrer les hiérarchies
2. Cas d'utilisation
 Lister tous les cas
 Regrouper par fonctionnalité (gestion abonnements, cours, suivi)
 Identier dépendances
3. Diagramme de cas d'utilisation
 Représenter le diagramme complet
 Utiliser <<include>> pour "Vérier validité abonnement" (avant accès salle)
 Utiliser <<extend>> pour "Créer plan alimentaire" (service optionnel pour membres
premium)
 Toutes autres relations pertinentes
4. Scénarios
 Scénario nominal : "Réserver et assister à un cours collectif"
 Scénario alternatif 1 : "Tentative de réservation pour un cours complet"
 Scénario alternatif 2 : "Accès refusé (abonnement expiré)"
5. Diagrammes de séquence
 "Renouveler un abonnement avec paiement en ligne"
7
Le savoir ne prend pas de congé - reste curieux, même en célébrant.
  Inclure : Membre, Interface, Gestionnaire abonnements, Système bancaire, Service noti-
cation
 Préciser types de messages

ÉTUDE DE CAS 8 : SYSTÈME DE GESTION D'UN PARKING INTEL-

LIGENT

Une société de gestion de parkings souhaite développer un système intelligent pour optimiser
l'utilisation des places et faciliter le paiement. Des capteurs détectent l'occupation de chaque place
en temps réel. Un panneau d'achage à l'entrée indique le nombre de places disponibles par niveau.
Les conducteurs occasionnels peuvent : Consulter la disponibilité sur une application mobile ou des
panneaux, Prendre un ticket à l'entrée (la barrière automatique s'ouvre après délivrance du ticket),
Se garer dans une place libre, Payer avant de partir via : Borne automatique dans le parking (carte
bancaire ou espèces), Application mobile (carte bancaire enregistrée), Scanner le ticket payé à la sortie
pour lever la barrière. Les abonnés mensuels peuvent : S'abonner en ligne ou à la borne d'accueil,
Accéder au parking en scannant leur carte d'abonné (ouverture automatique de la barrière), Avoir une
place réservée (pour abonnements premium), Consulter leur historique de stationnement, Renouveler
leur abonnement automatiquement. Le système de surveillance : Enregistre les entrées et sorties avec
horodatage, Détecte les stationnements anormalement longs (> 24h pour occasionnels), Déclenche
une alerte sécurité si nécessaire. Le paiement par carte bancaire nécessite une connexion au système
bancaire. Les agents de sécurité peuvent : Consulter les images des caméras de surveillance, Intervenir
manuellement pour ouvrir les barrières en cas de problème, Traiter les réclamations des clients,
Eectuer des rondes et signaler les incidents. Le technicien de maintenance peut : Consulter l'état des
équipements (capteurs, barrières, bornes), Recevoir des alertes en cas de dysfonctionnement, Marquer
les interventions comme réalisées. Le gestionnaire peut : Consulter les statistiques d'occupation,
Gérer les tarifs (horaires, abonnements, majorations), Créer des promotions (parking gratuit après
20h, weekend à tarif réduit), Générer les rapports de revenus, Gérer les places réservées, Exporter
les données pour la comptabilité. Le système calcule automatiquement : Le montant à payer selon
la durée et le tarif, Les revenus journaliers, hebdomadaires, mensuels, Le taux d'occupation moyen.
Des notications sont envoyées : Par SMS aux abonnés 3 jours avant expiration de l'abonnement,
Aux techniciens en cas de panne d'équipement, Au gestionnaire si le taux d'occupation dépasse 95%
(saturation).
Travail demandé :
1. Identication des acteurs
 Lister tous les acteurs (humains et non-humains)
 Justier l'identication des systèmes externes comme acteurs
 Montrer les relations entre conducteur occasionnel et abonné
2. Recensement des cas
 Lister tous les cas d'utilisation
 Identier les cas automatiques (déclenchés par le système)
 Identier les cas nécessitant une interaction humaine
3. Diagramme de cas d'utilisation
 Représenter le diagramme complet
 Inclure tous les acteurs et cas
 Montrer toutes les relations (include, extend, généralisation)
8
Le savoir ne prend pas de congé - reste curieux, même en célébrant.
  Justier chaque relation
4. Scénarios détaillés
 Scénario nominal : "Conducteur occasionnel se gare et paie à la borne"
 Scénario alternatif 1 : "Parking complet"
 Scénario alternatif 2 : "Paiement refusé, utilisation d'un autre moyen"
5. Diagrammes de séquence
 "Abonné entre dans le parking avec place réservée"
 Inclure : Abonné, Barrière d'entrée, Système de gestion, Capteurs, Panneau d'indication
 Préciser types de messages (synchrone, asynchrone)

ÉTUDE DE CAS 9 : PLATEFORME DE COVOITURAGE

Une startup veut développer une application de covoiturage pour connecter les conducteurs ayant
des places disponibles avec des passagers cherchant un trajet. Les utilisateurs non inscrits peuvent :
Consulter les trajets disponibles, Voir les prols publics des conducteurs (note, nombre de trajets).
Pour réserver ou proposer un trajet, il faut créer un compte et devenir membre. Les conducteurs
(membres ayant enregistré un véhicule) peuvent : Publier un trajet (départ, arrivée, date, heure,
prix par place, nombre de places disponibles), Dénir des critères de voyage (musique, animaux,
bagages, discussion), Accepter ou refuser les demandes de réservation des passagers, Modier ou
annuler un trajet (avec notication aux passagers conrmés), Consulter la liste des passagers conr-
més, Marquer le trajet comme terminé, Évaluer les passagers après le trajet. Les passagers (tous les
membres) peuvent : Rechercher des trajets selon critères (ville départ/arrivée, date, fourchette de
prix), Réserver une ou plusieurs places sur un trajet, Payer en ligne via le système de paiement (carte
bancaire ou portefeuille électronique), L'argent est bloqué jusqu'à conrmation du trajet, Recevoir
une conrmation de réservation par email et SMS, Annuler une réservation (remboursement selon
délai : 100% si >24h avant, 50% si <24h, 0% si <2h), Consulter les coordonnées du conducteur
une fois la réservation conrmée, Évaluer le conducteur après le trajet, Contacter le conducteur via
messagerie interne. Le système de paiement gère : Le blocage du montant lors de la réservation, Le
transfert au conducteur après conrmation du trajet (moins commission de 10%), Les rembourse-
ments en cas d'annulation. Un système de vérication permet : La vérication d'identité (photo de
pièce d'identité) pour devenir conducteur vérié, La vérication du permis de conduire, La vérica-
tion de l'assurance du véhicule. Les conducteurs vériés ont un badge spécial sur leur prol. Le service
de messagerie envoie : Conrmations de réservation, Rappels 24h et 2h avant le départ, Notications
en cas d'annulation, Demandes d'évaluation après le trajet. Un modérateur peut : Consulter les si-
gnalements d'utilisateurs, Suspendre ou bannir des comptes, Arbitrer les litiges entre conducteurs
et passagers, Consulter toutes les conversations, Valider les remboursements exceptionnels. L'admi-
nistrateur peut : Gérer tous les utilisateurs, Consulter toutes les statistiques (nombre de trajets,
revenus, taux de satisfaction), Gérer les paramètres de commission, Gérer les promotions (réductions
pour nouveaux utilisateurs), Exporter les données pour analyse. Le système calcule automatique-
ment : La note moyenne des utilisateurs (sur 5) basée sur les évaluations, Le taux de conrmation
des trajets pour chaque conducteur, Les revenus de la plateforme (commissions). Si un conducteur
annule 3 trajets conrmés en 1 mois, son compte est temporairement suspendu. Si un passager reçoit
3 évaluations négatives, il doit contacter le support avant de faire de nouvelles réservations.
Travail demandé :
1. Identication des acteurs
 Lister tous les acteurs humains et systèmes
9
Le savoir ne prend pas de congé - reste curieux, même en célébrant.
  Justier pourquoi le conducteur et le passager peuvent être le même acteur ou des acteurs
diérents
 Établir toutes les relations de généralisation
 Distinguer acteurs primaires et secondaires
2. Liste complète des cas d'utilisation
 Recenser TOUS les cas d'utilisation (environ 30-35)
 Les regrouper par thématique (gestion compte, trajets, paiements, évaluations, adminis-
tration)
 Identier les cas qui nécessitent une authentication
 Identier les cas automatiques déclenchés par le système
3. Diagramme de cas d'utilisation complet
 Représenter le diagramme avec tous les acteurs et cas
 Utiliser <<include>> pour les cas obligatoires : "S'authentier" (requis pour toute action
membre), "Vérier disponibilité" (avant réservation), "Traiter paiement" (inclus dans
réservation)
 Utiliser <<extend>> pour les cas optionnels : "Vérier identité" (optionnel pour conduc-
teur), "Ajouter critères de voyage" (optionnel lors de publication), "Contacter conduc-
teur" (optionnel après réservation)
 Montrer toutes les généralisations d'acteurs
 Justier chaque relation en 1-2 phrases
4. Scénarios détaillés
 Scénario nominal complet : "Passager recherche, réserve et eectue un trajet" (de la
recherche à l'évaluation)
 Scénario alternatif 1 : "Conducteur annule un trajet avec passagers conrmés"
 Scénario alternatif 2 : "Paiement échoue lors de la réservation"
 Scénario d'erreur : "Passager tente de réserver mais n'a pas assez d'argent"
 Pour chaque scénario : préconditions, étapes numérotées, postconditions
5. Diagrammes de séquence
 Diagramme 1 : "Publication d'un trajet par un conducteur vérié"
 Diagramme 2 : "Réservation d'un trajet avec paiement et notications"
 Pour chaque diagramme : Inclure tous les objets participants, Numéroter les messages,
Préciser le type : (S) = synchrone, (A) = asynchrone, (R) = retour, Montrer les boucles
et conditions si nécessaire

ÉTUDE DE CAS 10 : SYSTÈME DE GESTION D'UNE BANQUE EN

LIGNE

Une banque veut moderniser ses services en ligne pour permettre à ses clients d'eectuer la plupart
de leurs opérations bancaires via une plateforme web et mobile. Les visiteurs peuvent : Consulter les
ores de produits bancaires (comptes, cartes, prêts, épargne), Utiliser des simulateurs (crédit immobi-
lier, capacité d'emprunt, épargne), Faire une demande d'ouverture de compte en ligne. Pour eectuer
des opérations, un visiteur doit ouvrir un compte et devenir client. L'ouverture de compte nécessite :
10
Le savoir ne prend pas de congé - reste curieux, même en célébrant.
Remplir un formulaire en ligne, Télécharger des documents justicatifs (pièce d'identité, justicatif
de domicile), Une validation par un conseiller bancaire, La signature électronique du contrat. Les
clients s'authentient avec identiant, mot de passe et code OTP envoyé par SMS (authentication
à deux facteurs). Les clients peuvent : Consulter le solde et l'historique de leurs comptes (courant,
épargne, titres), Eectuer des virements : Virement interne (vers un autre compte du client), Vi-
rement vers un bénéciaire enregistré, Virement vers un nouveau bénéciaire (nécessite validation
par code OTP), Mettre en place des virements permanents ou programmés, Eectuer des paiements
de factures (électricité, eau, téléphone, impôts), Commander un chéquier, Commander une nouvelle
carte bancaire (en cas de perte, vol ou expiration), Faire opposition sur une carte (immédiatement
eective, nécessite conrmation par le service sécurité), Gérer leurs plafonds de paiement et de re-
trait, Télécharger leurs relevés de compte (PDF), Demander un RIB, Prendre rendez-vous avec leur
conseiller, Envoyer des messages sécurisés à leur conseiller, Souscrire à des produits d'épargne (livret,
assurance-vie, plan d'épargne), Faire une demande de crédit (personnel, immobilier, auto). Pour les
clients professionnels (entreprises), fonctionnalités supplémentaires : Gérer plusieurs comptes d'en-
treprise, Eectuer des virements multiples (chier CSV), Gérer les autorisations d'accès pour les
employés (comptable, directeur), Eectuer des opérations de change, Consulter des rapports nan-
ciers détaillés. Les virements de plus de 5000¿ nécessitent une double validation (client + conseiller).
Les conseillers bancaires peuvent : Consulter les dossiers de leurs clients, Valider les demandes d'ou-
verture de compte, Valider les demandes de crédit (montant < 50 000¿), Débloquer des comptes
temporairement bloqués, Répondre aux messages des clients, Eectuer des opérations au nom du
client (avec son autorisation écrite). Le directeur d'agence peut : Valider les crédits de 50 000¿ à
200 000¿, Consulter tous les dossiers clients de son agence, Consulter les statistiques de l'agence,
Gérer l'équipe de conseillers. Le service des crédits (back-oce) peut : Analyser les demandes de
crédit, Demander des documents complémentaires, Proposer une décision (acceptation, refus, contre-
proposition), Valider les crédits > 200 000¿. Le service sécurité peut : Détecter les transactions
suspectes (montants anormaux, pays à risque), Bloquer temporairement des comptes ou des cartes,
Contacter les clients en cas d'activité suspecte, Consulter l'historique de toutes les connexions, Déblo-
quer des comptes après vérication. Le système se connecte à plusieurs systèmes externes : Système
de paiement interbancaire pour les virements vers d'autres banques, Service SMS pour l'envoi des
codes OTP et notications, Bureau de crédit pour vérier la solvabilité lors des demandes de crédit,
Service de signature électronique pour les contrats. Le système envoie automatiquement : Conr-
mations pour chaque opération, Alertes en cas de solde négatif, Rappels avant échéances de crédit,
Notication 1 mois avant expiration de carte, Alertes en cas de transaction inhabituelle. Le système
calcule automatiquement : Les intérêts sur les comptes épargne (mensuellement), Les frais de tenue
de compte (trimestriellement), Les échéances de crédit, Les agios en cas de découvert. Si 3 tentatives
de connexion échouent, le compte est temporairement bloqué (15 minutes). Si une opposition carte
n'est pas conrmée dans les 24h, le service sécurité contacte le client.
Travail demandé :
1. Identication exhaustive des acteurs
 Lister TOUS les acteurs (humains et systèmes)
 Pour les acteurs humains, établir une hiérarchie complète (généralisation/spécialisation)
 Distinguer acteurs primaires, secondaires et systèmes externes
 Justier pourquoi certains systèmes externes sont considérés comme acteurs
 Créer un petit tableau récapitulatif : Acteur | Type (Primaire/Secondaire) | Description
2. Recensement exhaustif des cas d'utilisation
 Lister TOUS les cas d'utilisation du système (environ 40-50)
 Les organiser en catégories claires : Gestion de compte et authentication, Opérations
courantes (consultation, virements), Gestion des moyens de paiement, Produits bancaires
(épargne, crédits), Administration et sécurité
11
Le savoir ne prend pas de congé - reste curieux, même en célébrant.
  Pour chaque cas, indiquer l'acteur principal
 Identier les cas qui incluent obligatoirement d'autres cas
 Identier les cas qui peuvent étendre d'autres cas
3. Diagramme de cas d'utilisation complet et détaillé
 Représenter le diagramme complet avec TOUS les acteurs et cas
 Utiliser les relations <<include>> pour montrer les dépendances obligatoires : "S'authen-
tier" inclus dans toutes les opérations client, "Envoyer code OTP" inclus dans opérations
sensibles, "Vérier solde" inclus dans "Eectuer virement", "Notier client" inclus dans
toute opération
 Utiliser les relations <<extend>> pour les comportements optionnels : "Consulter dé-
tails" étend "Consulter historique", "Télécharger relevé" étend "Consulter compte", "Ajou-
ter bénéciaire" étend "Eectuer virement"
 Montrer toutes les généralisations : Client professionnel hérite de Client, Directeur et
Conseiller héritent d'Employé bancaire
 Organiser le diagramme de manière claire et lisible
 Ajouter des notes explicatives pour les relations complexes
4. Scénarios détaillés et complets
 Scénario nominal 1 : "Virement vers nouveau bénéciaire avec authentication OTP"
(étapes détaillées de la connexion au virement)
 Scénario nominal 2 : "Demande et validation d'un crédit immobilier de 150 000¿"
(processus complet)
 Scénario alternatif 1 : "Tentative de virement avec solde insusant"
 Scénario alternatif 2 : "Opposition carte bancaire suite à un vol"
 Scénario d'erreur 1 : "Blocage du compte après 3 tentatives de connexion"
 Scénario d'erreur 2 : "Transaction détectée comme suspecte par le service sécurité"
 Pour CHAQUE scénario : Titre et objectif, Acteur(s) impliqué(s), Préconditions (état
avant le scénario), Étapes détaillées et numérotées, Postconditions (état après le scénario),
Exceptions possibles
5. Diagrammes de séquence détaillés
 Diagramme 1 : "Connexion client avec authentication à deux facteurs (OTP)" : Objets :
Client, Interface Web, Serveur d'authentication, Service SMS, Base de données
 Diagramme 2 : "Virement vers un autre compte bancaire avec notication" : Objets :
Client, Interface, Gestionnaire de virements, Système interbancaire, Service notication,
Base de données
 Diagramme 3 : "Détection et traitement d'une transaction suspecte" : Objets : Client,
Interface, Système de paiement, Analyseur de fraude, Service sécurité, Service notication
 Pour CHAQUE diagramme : Représentation complète avec tous les objets, Messages
numérotés dans l'ordre chronologique, Type de message précisé : [S] = Synchrone (appel
avec attente de réponse), [A] = Asynchrone (envoi sans attente), [R] = Retour (réponse
à un appel), Conditions (alt, opt) si nécessaire, Boucles (loop) si répétitions, Fragments
combinés pour les cas complexes

12
Le savoir ne prend pas de congé - reste curieux, même en célébrant.
CONSEILS POUR LA RÉALISATION

Pour l'identication des acteurs :

1. Posez-vous : "Qui interagit DIRECTEMENT avec le système?"
2. Les systèmes externes qui fournissent ou reçoivent des informations sont des acteurs
3. Ne confondez pas utilisateur et rôle (une personne peut avoir plusieurs rôles)
4. Pensez aux acteurs temporels (système qui déclenche des actions automatiques)
Pour les cas d'utilisation :
1. Commencez par lister les objectifs de chaque acteur
2. Un cas = une fonctionnalité complète du point de vue de l'acteur
3. Utilisez des verbes d'action à l'innitif
4. Évitez les cas trop généraux ("Gérer") ou trop détaillés ("Cliquer sur bouton")
5. Un bon cas d'utilisation apporte de la valeur à l'acteur
Pour les relations :
 <<include>> : Obligatoire, toujours exécuté (ex : authentication)
 <<extend>> : Optionnel, conditionnel (ex : demander un reçu)
 Généralisation : Spécialisation/héritage entre acteurs ou cas
 Association : Simple lien acteur-cas
Pour les scénarios :
1. Scénario nominal = cas où tout se passe bien
2. Scénarios alternatifs = chemins diérents mais valides
3. Scénarios d'erreur = problèmes, exceptions
4. Numérotez chaque étape clairement
5. Précisez QUI fait QUOI
Pour les diagrammes de séquence :
1. Listez d'abord tous les objets participants
2. Tracez les lignes de vie verticales
3. Numérotez les messages dans l'ordre chronologique
4. Message synchrone (→) : l'émetteur attend la réponse
5. Message asynchrone (→) : l'émetteur n'attend pas
6. Message de retour (↶) : réponse à un appel
7. Utilisez des fragments pour conditions (alt) et boucles (loop)

Bon courage !

13
Le savoir ne prend pas de congé - reste curieux, même en célébrant.