Disponibilité déclarée, calendrier synchronisé et temps réel : trois niveaux différents

Les quatre niveaux à distinguer

La déclaration manuelle est une observation datée. Le calendrier synchronisé transporte des périodes selon une fréquence. Le système canonique connaît immédiatement ses propres mutations. Le temps réel démontré ajoute un contrat mesuré de bout en bout avec des sources externes.

Aucun niveau n’est universellement meilleur. Une déclaration récente et confirmée peut être plus sûre qu’un flux automatisé en erreur. Un système canonique est fiable pour ses propres ventes, mais reste aveugle à un canal externe qui n’a pas encore transmis sa mutation.

Déclaration manuelle : utile si elle expire

L’hébergeur peut déclarer une période libre après avoir vérifié son calendrier. La donnée indique alors qui a contrôlé quoi et quand. Cette simplicité convient à un petit inventaire ou à une offre très courte, à condition de ne pas prolonger silencieusement la déclaration.

Définissez une durée de validité adaptée au risque. À l’expiration, l’offre disparaît du résultat courant jusqu’à une nouvelle vérification. Une demande reçue dans l’intervalle reste soumise à confirmation ; elle ne transforme pas l’observation en réservation.

La déclaration doit porter sur des dates, une capacité et un hébergement exacts. Un message général “disponible ce week-end” sans année, fuseau, nombre de nuits ou responsable est difficile à réconcilier et à corriger.

• Auteur ou rôle habilité identifié.
• Date et heure de vérification conservées.
• Hébergement, arrivée et départ exacts.
• Expiration automatique.
• Procédure de retrait immédiat.
• Confirmation distincte de la déclaration.

iCalendar : synchronisation périodique, pas inventaire complet

La RFC 5545 définit un format d’échange d’événements. Dans l’hébergement, un événement sert souvent à bloquer une période. Il ne contient pas nécessairement prix, capacité, règles de séjour, canal d’encaissement ou état commercial complet.

Une absence d’événement ne prouve donc pas qu’une nuit est réservable. La source peut limiter sa fenêtre, omettre certains blocages ou être temporairement indisponible. Airbnb documente par exemple sa propre fréquence d’actualisation des calendriers importés et certaines limites ; ce comportement ne doit pas être généralisé aux autres opérateurs.

La formulation honnête est “dernière synchronisation réussie à”, accompagnée de l’âge du snapshot. Le lecteur doit savoir qu’une demande reste à confirmer.

Système canonique : immédiat pour ses propres mutations

Le système canonique possède l’état de référence d’un logement pour les opérations qu’il traite. Lorsqu’il confirme une demande ou pose un hold, il peut mettre à jour ce stock dans la même transaction et empêcher deux opérations locales concurrentes de consommer la même nuit.

Cette immédiateté locale ne donne pas une connaissance magique des autres canaux. Une réservation externe reste inconnue jusqu’à son import, son webhook ou sa saisie. Le système doit donc publier la provenance et l’âge de chaque composante du stock.

Un seul service pilote la synchronisation d’une source. Si un channel manager ou MAESTHOM en est déjà propriétaire, un autre produit consomme un snapshot qualifié ou reste en dehors ; il ne lance pas un second poller concurrent.

Temps réel : un contrat de bout en bout à mesurer

Pour revendiquer du temps réel, documentez le point de départ de la mutation, le transport, le traitement, la publication et le délai maximal ou observé. Mesurez aussi les pannes : source muette, message en retard, doublon, désordre ou indisponibilité du consommateur.

Une fréquence de polling élevée ne suffit pas. Si la source publie toutes les trois heures, interroger chaque minute ne crée pas une fraîcheur supplémentaire. Cela augmente les requêtes et le risque de limite sans améliorer la preuve.

Le système doit savoir se dégrader : signaler la dernière donnée connue, fermer une offre à risque, demander une confirmation ou refuser de publier. Un badge “temps réel” qui reste affiché pendant une panne serait plus trompeur qu’une synchronisation périodique clairement datée.

Provenance et fraîcheur : les deux informations minimales

La provenance dit qui a produit l’état et par quel canal il est arrivé. La fraîcheur dit quand la dernière lecture complète et valide a réussi. L’heure du téléchargement ne doit pas être confondue avec l’heure déclarée dans l’événement ou la mutation source.

Conservez l’identifiant du logement, la source, la version ou l’ETag, la fenêtre couverte, le dernier succès, l’échec courant et l’expiration. Les journaux restent expurgés des URL confidentielles et des descriptions de réservation.

L’interface publique n’a besoin que d’un état agrégé : dates potentiellement ouvertes, niveau de preuve, heure de vérification et confirmation requise. Elle n’expose ni le flux brut, ni l’identité d’un voyageur.

Déduplication, idempotence et ordre des événements

Un import relu doit reconnaître le même événement à partir de la source et de son UID, puis appliquer une révision plutôt que créer un nouveau blocage. Une action réseau répétée avec la même clé ne doit pas créer deux demandes ou deux holds.

Les événements peuvent arriver dans le désordre. Une révision plus ancienne ne doit pas écraser une donnée plus récente sans règle. Une suppression doit être confirmée selon le contrat de la source : un fichier vide ou tronqué pendant une panne ne signifie pas que toutes les nuits sont libres.

Ces protections améliorent la cohérence, mais elles ne garantissent pas l’exactitude commerciale d’une source. La confirmation finale demeure nécessaire lorsque le contrat ne prouve pas l’exclusivité du stock.

Publication atomique, cache et rollback

Le prochain snapshot est validé hors ligne de lecture, puis publié en une seule bascule. Les consommateurs voient soit l’ancienne version complète, soit la nouvelle, jamais un mélange de calendriers, métadonnées et fenêtres.

Les snapshots adressés par version ou empreinte peuvent être mis en cache longtemps. Un petit manifeste courant reçoit un TTL court et indique la version, la fraîcheur et l’expiration. Une réponse authentifiée ou contenant des données de séjour reste `no-store` ou strictement privée.

Si la nouvelle version échoue, le manifeste revient à l’artefact précédent. Le rollback ne rajeunit pas les données : l’âge et la limite restent visibles, et une offre trop ancienne demeure fermée.

Concurrence sur le dernier stock

Deux voyageurs peuvent demander les mêmes nuits presque simultanément. Une simple lecture “libre” suivie d’une écriture crée une course. Le système canonique doit réclamer le stock atomiquement, avec une clé idempotente et une expiration.

Le hold n’est pas une réservation. Il protège temporairement le traitement et doit être libéré après refus, expiration ou erreur. Une confirmation transforme l’état selon les règles du propriétaire ; un paiement éventuel relève d’un contrat distinct.

Si le stock dépend d’un canal externe non verrouillable, l’interface ne doit pas promettre une disponibilité ferme. Elle présente une demande à confirmer et peut fermer les dernières nuits lorsque la fraîcheur dépasse le seuil.

1. Relire l’état canonique dans la transaction.
2. Vérifier qu’aucun hold compatible n’existe.
3. Créer ou retrouver le hold idempotent.
4. Fixer une expiration bornée.
5. Soumettre à la confirmation autorisée.
6. Confirmer, refuser ou libérer sans double effet.

Critères neutres pour choisir un niveau

Comparer les formulations publiques

Sécurité et confidentialité

Une URL de calendrier peut donner accès à des périodes et parfois à des descriptions sensibles. Traitez-la comme un secret : stockage chiffré côté serveur, accès par service et logement, rotation et révocation, jamais de présence dans le HTML, les paramètres, les logs ou les analytics.

Réduisez le contenu importé au besoin : intervalles occupés, provenance, révision et statut technique. N’exposez ni nom de voyageur, ni note privée, ni référence de réservation dans un snapshot public.

Les résultats personnalisés restent `noindex` et ne passent pas dans un cache partagé. Le guide, lui, reste statique et ne reçoit aucune date de séjour personnelle.

Cas concrets

Ce que TOO NICE TO MISS prouve aujourd’hui

Sites v61 gère publiquement en D1 provenance, fraîcheur, idempotence, demande, hold et décision dans le périmètre du compte. La démonstration 1.0.0 reste fictive et isolée.

Le runtime ne prouve aucun partenaire, flux iCalendar réel, paiement ou réservation humaine non synthétique. Le stock manuel reste daté et sous confirmation.

Les CTA publics distinguent application, compte Voyageur, espace Professionnel et démonstration.

Checklist de qualification

• Propriétaire du stock identifié.
• Source et logement associés sans ambiguïté.
• Dernier succès et âge visibles.
• Fréquence conforme au contrat de la source.
• Déduplication et idempotence testées.
• Suppression et annulation traitées.
• Publication atomique et rollback prévus.
• Dernier stock protégé contre la concurrence.
• URL de calendrier absente des sorties publiques.
• Formulation alignée sur la preuve.
• Confirmation distincte de la demande.

Sources, révision et limites

La RFC 5545 soutient les notions iCalendar et leurs précautions. La documentation Airbnb illustre le comportement de cet opérateur, sans être généralisée. Les repères DGCCRF, Légifrance et EUR-Lex cadrent l’information du consommateur et le rôle des plateformes.

Dernière révision humaine : 25 août 2026. Les fréquences, contrats et fonctions produit doivent être relus sur leurs sources et passations actuelles. Le comparatif ne publie aucun indicateur de performance inventé.

Une correction peut être proposée avec une source publique et une date, sans URL de calendrier, identité, dates de séjour ou détail de réservation.