Une nuit vendue quelque part se ferme partout

Les plateformes reçoivent nos fermetures et nos prix, et nous renvoient leurs réservations. Le passage se fait par Beds24, relié par API, relu à intervalle régulier et à chaque événement.

Une réservation prise sur Airbnb entre dans la console avec sa provenance, ferme la nuit sur Abritel / Vrbo, Booking et votre site. Une réservation prise sur votre site part dans l'autre sens. Les nuits qu'une plateforme nous a envoyées ne lui sont jamais renvoyées fermées : une annulation faite chez elle rouvre la nuit au lieu de tourner en boucle.

Une passe qui a écrit n'est déclarée bonne qu'après relecture : un accusé de réception ne prouve rien, seule la relecture du calendrier fait foi.

Deux calendriers qui se contredisent sont montrés, avec l'occupant de chaque canal. La console ne choisit pas à votre place.

Quand une plateforme dit « vendue » et une autre « libre » sur la même nuit, la nuit est tenue, le conflit est inscrit, et le geste à faire est nommé. Un courriel groupé par passe, jamais un par nuit.

Le choix final vous revient : annuler l'un, déplacer l'autre, ou confirmer. La console garde la trace.

Chaque maison ouvre et ferme à ses propres dates, et cela se répète chaque année. Hors saison, la nuit est bloquée partout, pas seulement sans tarif.

Une maison qui ferme fin septembre et une autre fin octobre gardent chacune leur fenêtre. La fermeture est posée dans le calendrier comme un blocage de source « saison », exporté vers toutes les plateformes : sans cela, le moteur refuserait une date qu'Airbnb continuerait de vendre.

Une nuit déjà réservée n'est jamais écrasée par une fenêtre : elle est signalée comme conflit.

Sept nuits en été, moins hors pic si vous le décidez : le minimum se règle par palier de saison, et les plateformes le reçoivent.

Le moteur refuse un séjour trop court avant même de le chiffrer. Un trou de quelques nuits entre deux séjours n'est vendable que si vous l'autorisez explicitement.

Certaines plateformes ne transportent pas les minimums par leurs flux : là où c'est le cas, la console vous dit où le poser à la main, et le note.

Avant de vendre, vous posez une arrivée et un départ sur le calendrier et vous lisez ce que ce séjour vous rapporterait, canal par canal.

Le simulateur repasse par le moteur : saison, fenêtre de la maison, séjour minimum, promotion en cours. Il rend le prix affiché et le net attendu pour chaque plateforme, et peut poser une réservation de test que vous libérez ensuite.

La libération n'accepte que les réservations de test : un vrai séjour vendu ne se libère jamais depuis cet écran.

Si vos annonces sont encore sur le compte d'une agence, la console lit leur calendrier public pour ne pas revendre une semaine déjà vendue.

Les nuits lues sont posées comme bloquées, jamais comme réservées : la page publique ne dit pas la cause, et la console ne l'invente pas. Les longues plages de fermeture de saison ne sont pas importées, pour ne pas contaminer vos propres annonces.

On lit, on n'écrit rien chez l'agence. Le jour du transfert, les vraies liaisons prennent le relais.

Un flux qui ne répond plus, une passe qui n'a pas tourné, une nuit en conflit : un seul courriel par passe, et un courriel quand c'est rétabli.

Les alertes sont groupées, nomment les maisons en clair, et respectent un délai entre deux envois pour un même flux. Quand c'est nous qui n'avons pas tourné, aucune alerte « muet » n'est envoyée à tort.

L'exploitant reçoit une copie de chaque événement ; le voyageur, jamais.