Cycle d'une réservation : création, modification et annulation

2. Définir une machine d'états non ambiguë

Le mot réservation masque demande, option, préautorisation éventuelle, confirmation, modification, séjour en cours, annulation, non-présentation et clôture. Chaque état possède des conditions d’entrée, des actions autorisées et une sortie attendue. Une demande n’ouvre pas nécessairement le logement ; une option peut bloquer temporairement sans déclencher les opérations ; une annulation demandée ne vaut pas annulation effective.

Évitez les statuts qui mélangent deux dimensions, par exemple « confirmée et payée » : confirmation contractuelle et paiement évoluent séparément. Le dossier peut être confirmé avec paiement attendu, ou annulé avec remboursement encore en cours. Conservez l’état source original et l’état interne dérivé. Une transition forcée exige motif, auteur et preuve. Aucun traitement automatique ne doit passer à l’état suivant lorsque la source, la version ou le logement est incertain.

3. Créer le dossier minimal sans recopier tout le canal

Le dossier opérationnel contient ce qui est nécessaire pour exécuter le séjour : référence, logement, dates, statut, contact autorisé, nombre utile d’occupants, horaires connus, conditions ou demandes validées et provenance. Ne recopiez pas automatiquement documents, messages, moyens de paiement ou données visibles mais sans finalité. La CNIL recommande de minimiser les données et de limiter les habilitations.

Avant de confirmer la reprise, contrôlez que le logement correspond à l’annonce, que les dates utilisent le bon fuseau, que le blocage n’entre pas en conflit et que l’identifiant n’existe pas déjà. Séparez les notes internes des informations destinées au voyageur ou au prestataire. Un contact métier n’est pas automatiquement un compte applicatif. Le dossier conserve une réserve visible pour chaque donnée manquante ; la réserve a un responsable et une échéance. Cette méthode reste applicable dans un tableur ou un autre PMS.

4. Définir un seuil de planification avant de créer les missions

Une réservation reçue ne doit pas toujours déclencher immédiatement ménage, linge, accès et messages. L’équipe définit un seuil : statut confirmé dans la source, logement identifié, dates cohérentes et risque d’annulation compatible avec la procédure. Certaines opérations peuvent être préparées sans être affectées ; d’autres, coûteuses ou irréversibles, attendent une confirmation plus forte.

Lorsque le seuil est atteint, créez les besoins depuis le dossier mais gardez des objets séparés. Une mission possède son propre état, responsable et rapport ; elle n’est pas annulée par la simple disparition d’un événement calendrier. Un accès possède sa fenêtre et sa révocation. Un message possède son déclencheur et son canal. Cette séparation permet de propager une modification de façon contrôlée et d’expliquer pourquoi une opération a été maintenue, déplacée ou annulée. Le gestionnaire reste responsable des exceptions.

5. Traiter une modification comme un nouvel événement

Ne remplacez pas silencieusement dates, nombre d’occupants, logement, horaires ou conditions. Conservez la version précédente, la nouvelle valeur, l’auteur, la source, l’heure et le moment d’effet. Vérifiez que le canal ou la partie compétente a accepté le changement. Une demande reste en attente tant que l’autorité n’a pas confirmé.

Après confirmation, recalculez nuits, disponibilité, tarif ou taxe selon les règles applicables, accès, messages, rotation, linge et missions. Un import périodique peut arriver après une affectation terrain : le système signale alors les dépendances incohérentes et attribue leur revue. N’écrasez pas un rapport déjà remis ni une mission exécutée pour faire paraître l’historique cohérent ; liez plutôt l’écart à la modification. Informez seulement les rôles touchés et protégez les données qui ne leur sont pas nécessaires.

1. Lire la demande et son auteur.
2. Vérifier l'autorité et la version.
3. Conserver avant et après.
4. Calculer les impacts.
5. Décider chaque dépendance.
6. Informer les rôles concernés.
7. Clore la réserve.

6. Séparer annulation demandée, effective et conséquences

Une demande du voyageur, une annulation acceptée, un statut annulé dans le canal, un remboursement et une date libérée sont des événements distincts. Les plateformes publient leurs propres parcours et conditions ; le gestionnaire vérifie le dossier réel. Conservez un état intermédiaire tant que l’annulation n’est pas effective au lieu de la présenter comme acquise.

Lorsque le statut est confirmé, traitez séparément le calendrier, les messages, les accès, les missions et le financier. Une mission déjà exécutée ou un achat engagé ne disparaît pas parce que le séjour est annulé. À l’inverse, rembourser un montant ne prouve pas que la date peut être rouverte ni que les accès ont été révoqués. Le dossier conserve la politique ou version utile, la chronologie et les décisions. Ce guide ne détermine ni droit au remboursement ni responsabilité pour un cas individuel.

7. Arbitrer prolongation, départ tardif et changement de logement

Une prolongation est une modification de dates tant que le canal ou le contrat ne l’a pas confirmée. Vérifiez disponibilité, prix, conditions, accès, ménage et voyageur suivant avant de l’accepter. Une garde après départ peut protéger temporairement le calendrier sans prolonger le séjour ni générer une mission. Un départ tardif concerne l’exécution de la réservation existante : il réduit la fenêtre de rotation sans modifier automatiquement les dates contractuelles.

Un changement de logement crée un risque plus large : capacité, adresse, équipements, accès, annonce, prix, information du voyageur et missions doivent être revus. Ne déplacez pas simplement l’identifiant du logement en conservant les consignes précédentes. Pour toute exception, distinguez fait observé, demande, décision et effet. Une conversation ne remplace pas le statut du canal ; le statut du canal ne suffit pas à réorganiser le terrain. Une personne identifiée arbitre et fixe la prochaine vérification.

8. Détecter doublons, imports tardifs et conflits

Un même séjour peut arriver par flux calendrier, import structuré, e-mail ou saisie manuelle. Utilisez l’identifiant externe, le logement, les dates, le canal et les horodatages pour rapprocher les objets. Une ressemblance de nom ou de période n’autorise pas une fusion automatique. Gardez un dossier en réserve lorsqu’un doute subsiste et bloquez l’action irréversible.

Un import tardif peut créer un conflit avec un blocage ou une réservation directe. Figez les événements, comparez source et heure, protégez les voyageurs et appliquez la règle d’autorité publiée. Une fusion conserve les identifiants et l’origine ; elle ne supprime pas l’historique utile. Une séparation corrige les objets sans dupliquer les missions déjà réalisées. Mesurez doublons détectés, transitions forcées et temps d’arbitrage pour corriger les connecteurs ou procédures, sans classer automatiquement l’utilisateur qui a saisi le dossier.

9. Suivre paiement et opérations dans deux cycles reliés

Le cycle financier peut comporter montant attendu, préautorisation, encaissement, versement, ajustement, remboursement ou litige selon le canal. Il ne doit pas être comprimé dans le statut de réservation. Un séjour confirmé avec paiement en attente n’est pas identique à une demande ; un remboursement traité ne transforme pas le séjour en opération jamais planifiée.

Rapprochez la référence, la devise, les composantes du montant, la version des conditions et la pièce applicable. Limitez l’accès aux données financières et n’insérez jamais un moyen de paiement dans une mission terrain ou une URL. Les frais de plateforme, de conciergerie, de ménage et les taxes appartiennent à des catégories distinctes. Une ligne inconnue reste à rapprocher ; elle ne devient ni marge ni erreur du canal par hypothèse. MAESTHOM ne doit pas être présenté comme comptabilité ou paiement complet sans preuve produit correspondante.

10. Protéger données, droits et accès pendant le cycle

Chaque étape n’ouvre que les données nécessaires : le gestionnaire traite le dossier, le prestataire reçoit la mission, le propriétaire reçoit la synthèse prévue, le voyageur reçoit les informations de séjour. Un changement de statut ne justifie pas de copier les messages ou l’identité vers tous les objets. Les habilitations sont revues lors d’un changement de logement, d’une annulation et à la clôture.

Les codes d’accès sont associés à une fenêtre et révoqués si le séjour n’a plus lieu. Les journaux conservent l’action utile sans stocker le secret en clair. Les données de réservation ne doivent pas apparaître dans les paramètres de page du site éditorial, dans les mesures de navigation ou dans un cache public. La durée de conservation dépend de la finalité et du cadre ; la vue opérationnelle ne reste pas ouverte indéfiniment. Une demande de droit est orientée vers le responsable désigné, pas traitée par le prestataire terrain.

11. Cas concret : modification tardive reçue par calendrier

Une réservation confirmée du vendredi au dimanche a déjà généré une rotation dimanche après-midi. Samedi à 18 h, un événement iCalendar indique une fin lundi, sans détail de prix ni message du canal. Le gestionnaire ne prolonge pas automatiquement le séjour : il conserve la nouvelle période comme alerte, ouvre la source officielle, vérifie l’identifiant et le statut, puis qualifie la modification.

Si le canal confirme lundi, la version est enregistrée avec sa date. Le calendrier, l’accès, la communication et la mission de dimanche sont revus. La mission n’est pas supprimée sans décision : elle peut être déplacée, annulée ou remplacée selon son état. Le prix et le paiement suivent le canal et sont rapprochés séparément. Si la source ne confirme pas, l’alerte reste visible avec une échéance et la rotation demeure protégée. Ce scénario montre pourquoi iCalendar transmet un événement mais ne remplace pas le dossier de réservation.

1. Recevoir sans confirmer.
2. Identifier source et événement.
3. Vérifier dans le canal.
4. Créer une nouvelle version.
5. Propager objet par objet.
6. Informer les rôles touchés.
7. Clore l'alerte.

12. Clore le séjour sans perdre les actions ouvertes

La clôture intervient après le départ lorsque accès, missions, incidents, objets oubliés et réserves ont un état décidé. Elle ne signifie pas que toutes les données sont supprimées immédiatement ni que le cycle financier est achevé. Le dossier quitte la vue opérationnelle selon la règle prévue ; les éléments nécessaires à une obligation ou un litige sont isolés avec des droits et une durée adaptés.

Vérifiez que les codes sont révoqués, les missions terminées ou expliquées, les anomalies affectées, le compte rendu prêt et les écarts financiers reliés. Les indicateurs utilisent des conventions documentées et privilégient les agrégats lorsque l’identité n’est plus nécessaire. Une réouverture est un événement tracé avec motif, pas une modification silencieuse du statut clos. Cette règle permet de corriger un incident ultérieur sans présenter l’historique comme s’il avait toujours été connu.

13. Tester le cycle de bout en bout et mesurer les ruptures

La recette couvre une réservation directe, une OTA, une modification de dates, une annulation tardive, un doublon, un import en retard, un changement de logement et une perte temporaire du canal. Pour chaque scénario, vérifiez statut source et interne, calendrier, mission, accès, message, financier séparé, journal et mode dégradé. Les données sont fictives et les comptes de test autorisés.

Mesurez dossiers sans source, réserves sans responsable, transitions forcées, missions corrigées, accès non révoqués, conflits, écarts de rapprochement et délai d’arbitrage. Une automatisation rapide mais opaque n’est pas plus efficace. Le critère est la capacité à expliquer et reprendre chaque transition sans exposer de données inutiles. La démo MAESTHOM illustre un calendrier fictif ; elle ne prouve ni intégration OTA, ni paiement, ni persistance réelle isolée lorsqu’elle n’est pas qualifiée comme telle.