# Calendrier de disponibilité en bloc, pour un hôtel indépendant sans moteur coûteux

> Comment construire un bloc calendrier lisant des disponibilités saisies à la main, pour un hôtel indépendant qui refuse l'abonnement mensuel d'un moteur de réservation.

- Auteur : Clément Hadrot
- Publié le : 2025-03-09
- Mis à jour le : 2025-03-09
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/calendrier-disponibilite-bloc-hotel-independant/

## L’essentiel

- Les disponibilités vivent en post meta, saisies deux fois par semaine
- Le bloc lit ces données, il n'écrit jamais de réservation
- Un CPT « chambre » distinct du calendrier d'affichage

Faut-il un moteur de réservation pour afficher un simple calendrier de disponibilité ? Pour un hôtel indépendant de huit chambres dans les Cévennes, la réponse était non : le propriétaire gère déjà son planning sur un tableau papier au comptoir, et voulait simplement qu'un visiteur du site puisse voir, chambre par chambre, les périodes libres — sans processus de réservation en ligne, sans commission prélevée par un moteur tiers.

Le cahier des charges excluait explicitement le paiement d'un acompte en ligne : la réservation finale se fait par téléphone, comme toujours. Restait à construire un bloc qui affiche fidèlement un calendrier, alimenté par une saisie manuelle simple, sans dépendance à un service de réservation payant.

## Architecture retenue : deux entités distinctes

La première décision structurante a été de séparer deux notions souvent confondues : la chambre (un contenu qui décrit un lieu, ses photos, son tarif) et la disponibilité (une donnée qui change chaque semaine). Le schéma retenu ressemble à ceci :

```
Custom Post Type "hotel_chambre"
├── post_title            : nom de la chambre
├── post_content          : description
├── meta: prix_nuit       : nombre
└── meta: periodes_indispo : tableau sérialisé de [debut, fin]

Bloc "hotel/calendrier-dispo"
├── attribut: chambreId   : ID du CPT ciblé
├── attribut: moisAffiches : nombre de mois visibles (1 à 3)
└── render.php            : lit periodes_indispo, dessine la grille
```

Le bloc ne stocke lui-même aucune donnée de disponibilité : il se contente de lire le post meta de la chambre référencée. Cette séparation évite un piège classique — dupliquer la même information dans l'attribut d'un bloc et dans un meta, avec le risque qu'elles divergent au fil des mises à jour.

## Saisir les indisponibilités sans formulaire complexe

> L'essentiel à retenir : Les disponibilités vivent en post meta, saisies deux fois par semaine ; Le bloc lit ces données, il n'écrit jamais de réservation ; Un CPT « chambre » distinct du calendrier d'affichage

Plutôt qu'une interface de calendrier interactive pour la saisie — complexe à développer et à maintenir pour un usage aussi ponctuel —, l'équipe a ajouté un simple champ de méta-données dans l'écran d'édition du CPT `hotel_chambre`, via `add_meta_box()`, où le propriétaire saisit des plages au format texte, une par ligne : `12/04/2025-19/04/2025`. Deux fois par semaine, il met à jour ce champ depuis son ordinateur du bureau, opération qui prend moins de deux minutes par chambre.

## Le rendu du calendrier côté bloc

Le `render.php` du bloc parcourt les jours du mois affiché et compare chaque date aux plages d'indisponibilité enregistrées :

```
$chambre_id = $attributes['chambreId'];
$plages     = get_post_meta( $chambre_id, 'periodes_indispo', true );
$plages     = is_array( $plages ) ? $plages : array();

foreach ( $jours_du_mois as $jour ) {
    $indisponible = false;
    foreach ( $plages as $plage ) {
        if ( $jour >= $plage['debut'] && $jour <= $plage['fin'] ) {
            $indisponible = true;
            break;
        }
    }
    printf(
        '<span class="%s">%s</span>',
        esc_attr( $indisponible ? 'jour-indispo' : 'jour-libre' ),
        esc_html( $jour->format( 'j' ) )
    );
}
```

Le calcul reste volontairement simple : pas de gestion d'heures d'arrivée ou de départ à la demi-journée, pas de tarification dynamique selon la saison. Ces raffinements, un hôtelier avec huit chambres n'en a pas besoin — les ajouter aurait complexifié le bloc sans bénéfice réel pour cet usage.

## Pourquoi ne pas utiliser un plugin de réservation existant

Les moteurs de réservation du commerce couvrent des besoins que ce projet n'avait pas : gestion de canaux de distribution, synchronisation avec des OTA, paiement d'acompte, tarification dynamique. Chacune de ces fonctions se traduit par un coût — abonnement mensuel, commission par réservation, ou complexité de configuration — que l'hôtelier ne voulait pas porter pour un besoin d'affichage aussi simple.

> Un calendrier qui se contente d'afficher fidèlement une donnée saisie à la main vaut mieux qu'un moteur de réservation sous-utilisé à 10 % de ses fonctions, payé en intégralité.

## Limites assumées de cette architecture

- Aucune réservation en ligne : le calendrier informe, il ne transactionne pas.
- La fraîcheur des données dépend de la discipline de saisie du propriétaire, pas d'une synchronisation automatique.
- Pas de gestion de conflit si deux appels téléphoniques simultanés visent la même chambre — un risque que l'hôtelier connaît et gère comme avant, à la voix.

## En résumé

Un calendrier de disponibilité en bloc natif, appuyé sur un simple post meta saisi à la main, répond exactement au besoin d'un hôtel indépendant qui ne veut ni commission ni abonnement mensuel pour un affichage aussi basique. La séparation entre CPT « chambre » et bloc d'affichage garde l'architecture lisible, et laisse la porte ouverte à un moteur de réservation plus complet le jour où le volume le justifiera vraiment.