Réservation de table pour un restaurant : la structure de données la plus simple

Combien de tables, de créneaux et de statuts faut-il réellement pour gérer les réservations d’un restaurant qui ne dépasse pas une trentaine de couverts par service ? La réponse tient en beaucoup moins de complexité que ce que proposent la plupart des extensions de réservation du marché, souvent pensées pour des chaînes avec plusieurs établissements et des règles de disponibilité élaborées.

Pour un restaurant indépendant qui veut simplement remplacer un cahier papier ou un tableur partagé, un type de contenu personnalisé suffit, à condition de bien choisir ce qui relève d’une métadonnée et ce qui relève du statut du contenu lui-même.

Un CPT reservation plutôt qu’une table personnalisée

La tentation de créer une table personnalisée avec dbDelta() dès qu’une donnée sort du schéma habituel des articles est fréquente, mais elle ajoute une charge de maintenance disproportionnée pour ce volume : quelques dizaines de réservations par jour ne justifient pas de sortir du modèle de contenu natif.

function wpm_enregistrer_cpt_reservation() {
    register_post_type( 'reservation', array(
        'label'        => 'Réservations',
        'public'       => false,
        'show_ui'      => true,
        'show_in_menu' => true,
        'supports'     => array( 'title' ),
        'capability_type' => 'post',
    ) );
}
add_action( 'init', 'wpm_enregistrer_cpt_reservation' );

Le titre du contenu peut simplement contenir le nom du client et la date, ce qui rend l’écran d’administration lisible d’un coup d’œil sans configuration supplémentaire. Les informations structurées, elles, vont dans des métadonnées dédiées.

Ce qui relève d’une métadonnée

• reservation_date : la date et l’heure du créneau, au format ISO pour faciliter les comparaisons
• reservation_couverts : le nombre de personnes attendues
• reservation_telephone : le contact direct du client
• reservation_table : un identifiant de table si l’établissement en assigne à l’avance

Le statut du contenu comme état du cycle de vie

Plutôt que d’ajouter une métadonnée statut séparée, le statut natif du contenu couvre déjà l’essentiel : publish pour une réservation confirmée, draft pour une demande en attente de validation par le restaurateur, et un statut personnalisé pour les annulations.

function wpm_enregistrer_statut_annulee() {
    register_post_status( 'annulee', array(
        'label'                     => 'Annulée',
        'public'                    => false,
        'internal'                  => true,
        'label_count'               => _n_noop( 'Annulée <span class="count">(%s)</span>', 'Annulées <span class="count">(%s)</span>' ),
    ) );
}
add_action( 'init', 'wpm_enregistrer_statut_annulee' );

register_post_status() permet de suivre ce statut directement dans les filtres de l’écran d’administration, sans requête personnalisée supplémentaire, et sans confondre une réservation annulée avec une simple suppression du contenu.

Vérifier la disponibilité d’un créneau

La vérification de disponibilité reste la partie la plus délicate, même dans une architecture simple. Une requête basée sur meta_query permet de compter les couverts déjà réservés sur un créneau donné avant de confirmer une nouvelle demande :

$requete = new WP_Query( array(
    'post_type'      => 'reservation',
    'post_status'    => 'publish',
    'posts_per_page' => -1,
    'fields'         => 'ids',
    'meta_query'     => array(
        array(
            'key'   => 'reservation_date',
            'value' => $creneau_demande,
        ),
    ),
) );

$couverts_deja_reserves = 0;
foreach ( $requete->posts as $id ) {
    $couverts_deja_reserves += (int) get_post_meta( $id, 'reservation_couverts', true );
}

Pourquoi ne pas passer directement par une table personnalisée

Une table personnalisée deviendrait pertinente si le volume de réservations grimpait fortement, si plusieurs établissements devaient partager la même base, ou si des requêtes de reporting complexes s’accumulaient au fil du temps. Pour un seul restaurant avec un service par créneau, le CPT reste plus simple à faire évoluer : l’écran d’administration natif, les capacités, les statuts et les métadonnées sont déjà pris en charge sans code supplémentaire.

Besoin	Solution retenue
Identifier une réservation	Titre du contenu (client + date)
Créneau et couverts	Métadonnées dédiées
Cycle de vie	Statuts natifs et personnalisés
Interface de gestion	Écran d’administration natif

Sur ce type de projet, la question à se poser avant d’écrire la moindre table personnalisée est simple : est-ce que le modèle de contenu natif, avec ses statuts et ses métadonnées, couvre déjà 90 % du besoin ?

Pour aller plus loin

Cette architecture minimale ne couvre volontairement pas le paiement d’un acompte en ligne, qui suppose une intégration à part avec une passerelle de paiement et une gestion des remboursements en cas d’annulation. Elle constitue en revanche un socle solide et rapide à mettre en œuvre pour tout restaurateur qui souhaite d’abord sortir du cahier papier avant d’envisager des fonctionnalités plus avancées.