Ce qu'une plateforme de location de voitures m'a appris sur les modèles de données
Construire LocoAuto revenait à relier un parcours de réservation client à un tableau de bord opérationnel interne — et le modèle de données est le point où les deux se rencontrent.
LocoAuto a commencé comme un site de réservation et s'est transformé en outil d'exploitation. Ce glissement est fréquent, et c'est là que se joue l'ingénierie la plus intéressante.
Deux publics, un seul schéma
Un client veut chercher des voitures, choisir des dates et recevoir une confirmation. Un administrateur veut savoir quel véhicule se trouve où, quel chauffeur est affecté et quelle réservation attend encore un document. Les deux vues lisent les mêmes tables.
Vouloir servir ces deux publics avec des modèles séparés est tentant et presque toujours une erreur : dès qu'ils divergent, les données commencent à se contredire. Un schéma, deux projections : c'est plus simple à garder cohérent.
Les documents sont des données dérivées
Les reçus sont générés à partir des données de réservation plutôt que stockés en texte libre. Si une réservation est corrigée, le document qui la décrit doit suivre automatiquement. Tout ce qu'un humain ressaisit est quelque chose qui peut dériver.
L'affectation est une relation, pas un champ
La première version de l'affectation des chauffeurs était une colonne sur la réservation. Cela fonctionnait jusqu'à ce qu'une livraison nécessite deux personnes, et jusqu'à ce qu'un chauffeur ait besoin d'un historique. Modéliser l'affectation comme une relation à part entière — avec un début, une fin et un statut — a résolu ces deux cas et plusieurs autres auxquels je n'avais pas encore pensé.
La leçon
Les interfaces sont faciles à changer. Les modèles de données ne le sont pas. Le temps passé sur le modèle avant le premier écran est le temps le moins cher de tout le projet.