Cas d'entraînement : portail de réservation de véhicules de service

Vertex Ingénierie n'existe pas. Cette entreprise est le sujet d'un cas que j'ai rédigé pour ma certification : un bureau d'études de 65 salariés, 12 véhicules de service partagés sur 3 sites, une gestion des réservations tenue dans un tableur et confirmée par téléphone. Aucune prestation n'a été facturée, aucune solution n'a été installée.

Les pièces sont présentées dans l'ordre où elles ont été produites.

Note de cadrage

Contexte, objectifs et échéances, acteurs, périmètre, contraintes, risques et indicateurs. Le périmètre énonce sept exclusions explicites, et le numéro de permis de conduire y est traité dans le modèle de données plutôt que par une mention de conformité.

Ouvrir la note de cadrage (PDF, 4 pages).

Processus existant

Le collaborateur consulte le tableur partagé, appelle pour confirmer la disponibilité, inscrit sa réservation, puis se présente au départ. Les deux issues défavorables du schéma constituent l'objet du projet.

Schéma du processus actuel : le collaborateur consulte un tableur partagé, appelle pour confirmer, note sa réservation, puis se présente le jour du départ. Deux issues négatives : aucune solution trouvée à temps, et conflit découvert trop tard parce que le véhicule est déjà pris.
Schéma du processus actuel.

Processus cible

Trois couloirs : le collaborateur dépose sa demande, le système écarte les chevauchements puis applique les deux règles de routage, et le responsable de flotte n'intervient que si l'une d'elles se déclenche, mission de plus de trois jours, ou véhicule qui ne revient pas à son site de départ.

Schéma du processus cible en trois couloirs : le collaborateur dépose une demande, le système détecte les chevauchements de créneau puis applique les deux règles de routage, et le responsable de flotte n'intervient que lorsqu'une des deux règles se déclenche.
Schéma du processus cible en trois couloirs.

Architecture

Les briques retenues et leurs échanges : interface de saisie, base de données, moteur d'automatisation, service de notification.

Schéma d'architecture globale de la solution : interface de réservation, base de données centralisée, moteur d'automatisation et service de notification, avec les échanges entre ces briques.
Schéma d'architecture globale de la solution.

Modèle de données

Les entités et leurs relations. Deux tables méritent l'attention : le permis de conduire, isolé et purgé automatiquement, et l'historique de localisation, qui trace le site réel de chaque véhicule au lieu de figer un champ sur sa fiche.

Modèle entité-association de la solution : véhicules, réservations, utilisateurs, table permis isolée et table d'historique de localisation, avec les cardinalités entre elles.
Modèle entité-association de la solution.

Base de données

La base centralise les véhicules, les réservations, les collaborateurs, les permis et l'historique de localisation. Les vues du responsable de flotte couvrent les trois sites ; celles des collaborateurs n'exposent pas la table des permis.

Automatisation

Le workflow se déclenche à la création d'une demande, recherche les réservations actives du même véhicule, compare les créneaux, puis oriente la demande vers la confirmation, le refus ou l'arbitrage.

Le workflow d'automatisation : déclencheur sur la base, recherche des réservations existantes, comparaison des créneaux en JavaScript, puis deux conditions successives orientant vers la validation, la mise en attente ou le refus, chacune suivie d'une notification.
Le workflow d'automatisation.

Portail de réservation

L'interface est rudimentaire, et c'est assumé : elle sert à déposer et à consulter des demandes, pas à démontrer un savoir-faire graphique. Ce qui est construit et vérifié dans ce dossier, ce sont les règles qui la commandent.

L'interface consultée par les collaborateurs : les réservations en cours, leurs statuts, les filtres par véhicule et par demandeur, et le dépôt d'une nouvelle demande. Les données affichées sont celles des tests.

Le portail de réservation : la liste des réservations en cours avec leurs dates, leur statut, le site de départ et le site de retour, des filtres par statut, véhicule et demandeur, et un bouton pour réserver un véhicule.
Le portail de réservation.

Livraison

Cahier de recette, documentation utilisateur et présentation de la solution pour un lecteur non technique. Onze scénarios couvrent les quatre chemins de décision, les cas limites et le contrôle d'accès à la table protégée. L'un d'eux reste sans résultat attendu : la question du jour de battement entre deux réservations relève de l'exploitation et appartient au commanditaire.

Ouvrir la livraison (PDF, 4 pages).

Analyse de performance

Choix des indicateurs, lecture du jeu de données, correspondance avec les tests effectivement exécutés. Un cinquième indicateur a été écarté, et son exclusion est motivée : le nombre de conflits passés inaperçus ne peut pas être calculé, un conflit que le système n'a pas détecté ne figurant par construction nulle part dans ses données.

Ouvrir l'analyse de performance (PDF, 3 pages).

Statut de ce dossier

L'activité vient d'être créée et ne dispose pas encore de dossier client communicable. Publier une application complète d'une démarche, en indiquant son origine, permet d'en apprécier la méthode : le raisonnement, les arbitrages et les documents produits sont ceux qu'appelle une mission réelle ; seul le commanditaire est fictif. Une mise en service demanderait ensuite le travail que l'exercice ne couvrait pas : le reste des automatisations, la reprise des données, la formation, et une interface soignée.

Voir l'autre cas d'entraînement : réservation multi-sites pour un réseau de coworking
Retour à l'accueil