Objectifs pédagogiques
Cette étude de cas, filée sur l’ensemble des 13 séances du cours, s’appuie sur un projet unique, AutoLoc, enrichi progressivement à chaque atelier. Elle fait observer la construction incrémentale d’une architecture logicielle complète, depuis la modélisation jusqu’à l’évaluation de la qualité et aux pistes d’amélioration continue.
1. Contexte métier
AutoLoc est une entreprise de location de véhicules disposant de plusieurs agences réparties dans différentes villes. Chaque agence gère une flotte de véhicules de catégories variées (citadine, berline, SUV, utilitaire). Les clients réservent un véhicule pour une période donnée ; à la signature, un contrat est établi et des paiements y sont rattachés.
L’entreprise souhaite numériser l’ensemble du processus (réservation, contractualisation, facturation, suivi de flotte, relances automatiques) au travers d’une application back-end Spring Boot exposant une API REST.
2. Acteurs du système
| Rôle | Description | Droits principaux |
|---|---|---|
| Client | Particulier ou professionnel souhaitant louer un véhicule. | Consulter les véhicules disponibles, créer/annuler une réservation, consulter ses contrats. |
| Agent d’agence | Employé en charge de la gestion opérationnelle d’une agence. | Gérer les véhicules, valider une réservation, établir un contrat, enregistrer un paiement. |
| Responsable d’agence (Manager) | Supervise une agence et son personnel. | Droits Agent, plus gestion des employés et consultation des statistiques de l’agence. |
| Administrateur | Administre la plateforme. | Gestion des agences, des catégories de véhicules, statistiques globales, configuration. |
3. Modules fonctionnels
| Module | Description |
|---|---|
| Gestion des agences et de la flotte | CRUD des agences, des véhicules et de leurs catégories ; suivi de la disponibilité et du statut (disponible, loué, en maintenance). |
| Gestion des clients | Inscription, mise à jour du profil, historique des réservations et des contrats. |
| Réservation | Recherche de véhicules disponibles par ville, catégorie et période ; création, modification et annulation de réservations. |
| Contractualisation et paiement | Génération d’un contrat à la validation d’une réservation, enregistrement des paiements (acompte, solde, pénalités). |
| Tarification | Calcul du tarif selon la catégorie du véhicule, la durée, la période (semaine/week-end) et les équipements optionnels (GPS, siège bébé, etc.). |
| Tâches planifiées | Libération automatique des véhicules en fin de location, alertes de contrats arrivant à échéance, statistiques. |
| Reporting et qualité | Statistiques d’occupation et de chiffre d’affaires par agence, indicateurs de qualité du code et de couverture de tests. |
4. Modèle de données conceptuel
Le modèle, construit progressivement à la Séance 2 (entités) et à la Séance 3 (associations), illustre les différents types d’associations et mécanismes de gestion des relations entre entités : @OneToMany, @ManyToOne, @OneToOne, @ManyToMany, ainsi que les stratégies de cascade et de fetch.
| Entité | Attributs principaux | Association | Type / Cascade-Fetch |
|---|---|---|---|
| Agence | id, nom, ville, adresse, telephone | 1 Agence vers N Vehicule ; 1 Agence vers N Employe | @OneToMany, FetchType.LAZY |
| Vehicule | id, immatriculation, marque, modele, categorie, tarifJournalier, statut | N Vehicule vers 1 Agence ; N Vehicule vers N Equipement | @ManyToOne / @ManyToMany (table de jointure) |
| Equipement | id, libelle (GPS, siège bébé, coffre de toit…) | N Equipement vers N Vehicule | @ManyToMany, FetchType.LAZY |
| Client | id, nom, prenom, email, telephone, numPermis, dateInscription | 1 Client vers N Reservation | @OneToMany, cascade PERSIST |
| Employe | id, nom, prenom, role (AGENT/MANAGER) | N Employe vers 1 Agence | @ManyToOne, FetchType.LAZY |
| Reservation | id, dateDebut, dateFin, statut | N Reservation vers 1 Client ; N Reservation vers 1 Vehicule ; 1 Reservation vers 1 Contrat | @ManyToOne x2, @OneToOne |
| Contrat | id, dateSignature, montantTotal, valide | 1 Contrat vers 1 Reservation ; 1 Contrat vers N Paiement | @OneToOne, @OneToMany cascade ALL |
| Paiement | id, montant, datePaiement, modePaiement | N Paiement vers 1 Contrat | @ManyToOne, FetchType.LAZY |
| Maintenance | id, dateDebut, dateFin, description | N Maintenance vers 1 Vehicule | @ManyToOne, cascade PERSIST |
La relation Contrat vers Paiement en cascade ALL illustre la suppression en cascade (supprimer un contrat supprime ses paiements), tandis que Agence vers Vehicule reste volontairement sans cascade de suppression (supprimer une agence ne supprime pas ses véhicules).
5. Architecture retenue
L’application cible adopte un style architectural monolithique, structuré selon le patron en couches (Layered Architecture), avec une séparation claire des responsabilités entre les couches et plusieurs patterns de conception.
| Couche | Package | Contenu de la solution |
|---|---|---|
| Présentation (API) | web.controller | VehiculeController, ClientController, ReservationController, ContratController, StatistiqueController, OpenApiConfig. |
| Transfert (DTO) | web.dto | VehiculeDTO, ReservationRequestDTO/ResponseDTO, VehiculeMapper. |
| Service (métier) | service | IReservationService/Impl, ITarificationService et ses stratégies. |
| Persistance | repository | IVehiculeRepository, IClientRepository, IReservationRepository. |
| Domaine | domain | Vehicule, Client, Reservation, CategorieVehicule, StatutVehicule. |
| Transverse | aspect / scheduler | LoggingAspect, PerformanceAspect, ContratEcheanceScheduler. |
Rôle de chaque couche :
- Présentation (contrôleurs) : la porte d’entrée de l’application. Elle reçoit les requêtes HTTP et y répond, en manipulant des DTO plutôt que les données internes, pour ne rien exposer d’inutile ou de sensible.
- Métier (services) : contient les règles et la logique, par exemple gérer une réservation ou calculer un prix.
- Transversale (AOP) : centralise les tâches qui concernent toute l’application (logs, gestion des erreurs) plutôt que de répéter ce code partout.
- Domaine (objets métier) : les briques de base du métier (véhicule, réservation, client), avec leurs propres règles.
- Persistance (accès aux données) : sauvegarde et récupère les données sans que le reste de l’application ait besoin de savoir comment.
- Base de données : le stockage durable des informations, avec des règles garantissant leur cohérence.
6. Stack technique recommandée
| Catégorie | Outils / bibliothèques |
|---|---|
| Langage / Build | Java 17+, Maven |
| Framework | Spring Boot, Spring Data JPA, Spring MVC, Spring AOP, Spring Scheduler |
| Base de données | MySQL ou PostgreSQL en développement, H2 en mémoire pour les tests |
| Productivité | Lombok, SLF4J/Logback, MapStruct (mapping DTO, optionnel) |
| Documentation API | springdoc-openapi (Swagger UI) |
| Qualité | SonarLint (IDE), SonarQube (optionnel, séance 13) |
| Outillage | Git/GitHub, Postman, IntelliJ IDEA |