Réservation événementielle
Un dossier de mariage qui vivait dans un agenda papier, un tableur et une boîte mail, ramené à un tunnel unique.
Mon rôle
Application écrite seul de bout en bout : neuf modèles de données, authentification maison avec vérification d'email et réinitialisation de mot de passe, tunnel de réservation, paiements échelonnés, dépôt et distribution sécurisée des pièces justificatives, contrats en PDF, emails transactionnels, back-office de la mairie et mise en ligne. Aucune ligne ne vient de quelqu'un d'autre.
Le problème
Les demandes arrivaient par email et par téléphone. Les disponibilités vivaient dans un agenda partagé, les acomptes dans un tableur, les pièces justificatives dans des pièces jointes, et les contrats étaient retapés à chaque dossier. Le risque de double réservation était permanent, et personne ne pouvait dire qui avait validé quoi.
Ce que j'ai livré
- Catalogue des salles avec options tarifées, et calendrier des disponibilités croisant les réservations en cours et les dates fermées manuellement par la mairie.
- Réservation en ligne avec acompte à la demande, puis paiements partiels et solde suivis dans un historique par dossier.
- Dépôt des pièces justificatives par le demandeur, stockées hors du serveur applicatif et redistribuées uniquement par lien signé à durée courte.
- Modification d'un dossier existant avec règlement du différentiel avant validation.
- Génération des contrats et documents en PDF, regroupés en archive téléchargeable pour l'agent qui instruit le dossier.
- Authentification maison : session signée en cookie, vérification d'adresse email par lien, réinitialisation de mot de passe à jeton expirant.
- Quatre rôles — demandeur, agent, administrateur, administrateur mairie — et protection des espaces par middleware.
- Emails transactionnels à chaque étape : acompte reçu, dossier validé, dossier refusé.
- Formulaire de contact protégé du spam par limitation à l'adresse IP.
- Tableau de bord avec indicateurs graphiques du remplissage et du chiffre d'affaires, et export des données.
- Journal horodaté, avec adresse IP, sur les suppressions et les modifications de compte.
Les points durs
Une disponibilité affichée n'est pas une disponibilité réservée
Le calendrier vu par le navigateur date d'il y a quelques minutes, et deux familles peuvent viser la même date le même soir. Je refais donc la vérification côté serveur au moment de créer le dossier, contre les réservations non refusées et les dates fermées par la mairie, et je refuse la demande plutôt que de la laisser passer. Le calendrier oriente, il ne décide pas.
Des pièces d'identité qui ne doivent pas traîner sur un serveur web
Un dossier de mariage contient des papiers d'identité. Je ne les sers jamais depuis un dossier public : ils vivent dans un stockage privé, et chaque consultation passe par une route qui régénère un lien signé valable soixante secondes. Un lien recopié dans un email ou resté dans un historique de navigation ne vaut plus rien une minute plus tard.
Un contrat, pas une page imprimée
Je n'ai pas voulu d'un rendu HTML envoyé à l'imprimante. Le contrat est un PDF que je génère à partir des données du dossier, avec le récapitulatif des options retenues, et que l'agent récupère groupé en archive avec les pièces justificatives — un dossier complet en un téléchargement.
Un calendrier qui connaît ses jours fériés
Une commune ne marie pas un jour férié, et la liste n'est pas celle de la métropole : le 27 mai, jour de l'abolition de l'esclavage, en fait partie. La règle est appliquée à la création du dossier, pas seulement grisée dans le sélecteur de dates — une règle de fermeture qui ne vit que dans l'interface n'est pas une règle.
Aperçus
