Étude de cas · 2026
Gestion d'Hôtel
Hôtel Lumière — un système de gestion hôtelière à double interface : un tableau de bord Django rendu côté serveur pour le personnel et une SPA Vue 3 pour les clients consommant une API REST. Réservation de chambres, check-in/out, tarification dynamique, paiements Stripe, avis, gestion des tâches et notifications.
DjangoDjango REST FrameworkVue.js 3PostgreSQLChart.jsStripe APIRenderVercel
2Interfaces : tableau de bord personnel + SPA client
DRFAPI REST entre MVT et SPA
StripePaiements sur le parcours de réservation
93Performance Lighthouse (mobile, oct. 2026)
01
Le défi
- Problème Couvrir tout le cycle de réservation d'un hôtel — tableau de bord Django pour le personnel et SPA Vue 3 pour les clients — avec des flux de réservation, de tarification et de compte corrects des deux côtés.
- Contraintes Travail solo sur un PFA de 4e année ; l'architecture hybride impliquait de maintenir deux frontends dans un seul projet ; aucun budget.
- Principaux obstacles Dates de réservation inversées, champs de mot de passe acceptant des espaces en début/fin, et tarification automatique non déclenchée à la sélection d'une chambre dans une nouvelle réservation.
- Cause Gestion des fuseaux horaires implicite, entrées non normalisées avant persistance, et formulaire de réservation non relié à l'API de tarification.
- Solution immédiate Gestion explicite des fuseaux horaires dans les réglages Django, validation strip() des identifiants, et liaison du formulaire de réservation à une API de tarification dynamique qui recalcule selon l'occupation réelle.
02
L'approche
- Architecture API REST Django + DRF sur PostgreSQL ; le tableau de bord du personnel est resté rendu côté serveur (MVT) pour un CRUD rapide, tandis que le parcours de réservation client devenait une SPA Vue 3.
- Couche API Les serializers DRF définissent le contrat entre le tableau de bord MVT et la SPA.
- Tarification Un endpoint de tarification dynamique recalcule les tarifs selon l'occupation en temps réel et est appelé dès qu'une chambre est sélectionnée.
- Intégrité des données Gestion des dates sensible aux fuseaux horaires et normalisation des entrées (identifiants trimmés).
- Reporting Tableaux de bord Chart.js pour l'occupation et les revenus.
- Paiements Stripe pour les paiements de réservation.
- Déploiement Backend sur Render, SPA sur Vercel.
Impact
Terminé et présenté comme PFA de 4e année — un seul système couvrant tout le cycle de réservation : recherche, tarification dynamique, réservation, paiement et check-in/out.
03
Captures d'écran
04
Ce que je ferais différemment
- Les dates de réservation s'affichaient à l'envers car la gestion des fuseaux horaires était implicite. Je fixe désormais un contrat de fuseau horaire explicite (stockage, API, rendu) avant d'écrire la moindre logique de date.
- Les champs de mot de passe acceptaient des espaces parasites — je valide et normalise chaque entrée à la frontière plutôt que de faire confiance au client.
- Maintenir un tableau de bord Django MVT et une SPA Vue dans un même projet, c'est deux frontends. La prochaine fois, je choisirais une seule stratégie de rendu avec une API unique.