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 grilleLe 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
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.
