Deux statuts, une seule différence à gérer, et pourtant une confusion fréquente : afficher le numéro de chambre attribué dès la création de la réservation, avant même que le paiement ne soit validé. Sur un espace personnel accessible par lien, cette information reste techniquement consultable par n’importe qui disposant du lien, y compris avant confirmation.
Le risque n’est pas seulement une question de confidentialité anecdotique. Une réservation en attente peut encore être annulée, refusée pour cause de carte bancaire invalide, ou réattribuée à une autre chambre en cas de surbooking géré manuellement par la réception. Afficher un numéro figé trop tôt crée une attente qui peut être déçue.
Où vit cette donnée
Dans une configuration où les réservations sont gérées comme un type de contenu personnalisé reservation, le numéro de chambre est en général stocké dans un champ personnalisé, par exemple numero_chambre, tandis que le statut de paiement vit dans un autre champ ou dans le statut natif du post lorsque les réservations utilisent des statuts personnalisés déclarés via register_post_status().
Centraliser la condition d’affichage
Comme pour tout affichage sensible au statut, la bonne pratique consiste à écrire une seule fonction qui décide si le numéro peut être révélé, plutôt que de disperser des conditions dans chaque template :
function wpm_reservation_est_confirmee( $post_id ) {
$statut_paiement = get_post_meta( $post_id, 'statut_paiement', true );
return 'confirme' === $statut_paiement;
}
function wpm_afficher_numero_chambre( $post_id ) {
if ( ! wpm_reservation_est_confirmee( $post_id ) ) {
return 'En cours d\'attribution';
}
$numero = get_post_meta( $post_id, 'numero_chambre', true );
return $numero ? esc_html( $numero ) : 'À confirmer';
}Dans l’espace personnel du client
Sur la page où le client consulte le détail de sa réservation, l’appel devient simplement :
echo '<p>Chambre : ' . wpm_afficher_numero_chambre( get_the_ID() ) . '</p>';Le client voit alors un message d’attente cohérent plutôt qu’un numéro susceptible de changer, ce qui évite les appels à la réception pour signaler une incohérence après une réattribution de chambre.
Protéger aussi l’export et l’email de confirmation
Il ne suffit pas de masquer le numéro dans le template principal si un email automatique déclenché à la création de la réservation continue de l’inclure avant confirmation. La même fonction de vérification doit être appelée dans le gabarit de l’email :
- Retarder l’envoi de l’email contenant le numéro jusqu’au passage en statut confirmé, via un hook déclenché sur le changement de statut.
- Envoyer un premier email d’accusé de réception sans numéro, puis un second une fois le paiement validé.
- Vérifier également les exports PDF générés à la demande depuis l’espace d’administration.
Variante : masquer aussi côté équipe pour certains rôles
Dans certains établissements, seule la réception a besoin de voir le numéro avant confirmation, par exemple pour préparer la chambre en amont. La fonction peut alors accepter un second paramètre lié au rôle courant :
function wpm_afficher_numero_chambre( $post_id, $forcer_affichage = false ) {
if ( ! $forcer_affichage && ! wpm_reservation_est_confirmee( $post_id ) ) {
return 'En cours d\'attribution';
}
return esc_html( get_post_meta( $post_id, 'numero_chambre', true ) );
}Le paramètre $forcer_affichage peut être défini à true uniquement dans l’interface d’administration réservée aux comptes disposant de la capacité adéquate, vérifiée au préalable avec current_user_can().
Conseil maison : ne masquez jamais une donnée sensible uniquement en CSS. Le numéro de chambre doit rester absent du HTML généré tant que la condition n’est pas remplie, sans quoi il reste consultable via le code source de la page.
Ce que cette technique ne traite pas
Cette approche ne gère pas le moteur de réservation lui-même, ni la logique d’attribution automatique des chambres selon la disponibilité. Elle suppose que le numéro de chambre est déjà déterminé quelque part dans le système et se concentre uniquement sur le moment où cette information devient visible pour le client.
En résumé
Deux statuts, une fonction de vérification centralisée, et une donnée sensible qui ne s’affiche jamais avant le bon moment, que ce soit dans l’espace client, dans un email ou dans un export. Cette discipline simple évite des situations gênantes lors d’un surbooking ou d’un paiement refusé après une réservation initiale.
