Sept bières en carte, un menu du jour qui change presque quotidiennement, et un shortcode [carte_bieres] écrit en 2019 qui affichait une liste HTML statique construite à partir d’une simple option WordPress mise à jour à la main chaque matin. C’est le point de départ d’une brasserie artisanale qui souhaitait installer une borne tactile en salle de dégustation, capable d’afficher la carte en temps réel sans repasser par l’écran d’administration de WordPress à chaque changement.
Le shortcode existant restait fonctionnel pour la page web classique du site vitrine, mais il ne convenait pas du tout à une borne tactile : celle-ci avait besoin d’interroger une source de données à intervalle régulier, sans recharger une page HTML complète ni dépendre du thème visuel du site.
Le diagnostic du shortcode existant
Le code du shortcode récupérait une option sérialisée via get_option( 'carte_bieres_actuelle' ), contenant un tableau associatif de bières avec leur nom, leur degré d’alcool et leur prix. Cette structure fonctionnait bien pour un affichage HTML classique, mais poser une borne tactile en salle imposait une contrainte supplémentaire : la disponibilité en temps réel de chaque bière, qui pouvait changer en cours de service lorsqu’un fût était vidé.
Plutôt que de réécrire tout le système de stockage, l’équipe a choisi de conserver l’option existante comme source de vérité, et d’y ajouter un champ de disponibilité, avant d’exposer le tout via une route REST personnalisée.
Construire la route REST dédiée
add_action( 'rest_api_init', function() {
register_rest_route( 'brasserie/v1', '/carte', array(
'methods' => 'GET',
'callback' => 'brasserie_recuperer_carte',
'permission_callback' => '__return_true',
) );
} );
function brasserie_recuperer_carte() {
$carte = get_option( 'carte_bieres_actuelle', array() );
$reponse = array_map( function( $biere ) {
return array(
'nom' => $biere['nom'],
'prix' => (float) $biere['prix'],
'disponible' => (bool) $biere['disponible'],
);
}, $carte );
return rest_ensure_response( $reponse );
}
Trois champs seulement composent la réponse : le nom, le prix, et un booléen de disponibilité. Ce choix minimaliste a été délibéré, l’équipe ayant constaté qu’ajouter le degré d’alcool ou la description marketing de chaque bière n’apportait rien à l’affichage de la borne, pensé pour être lisible en quelques secondes par un client debout au comptoir.

Côté borne : une interrogation toutes les deux minutes
La borne, un simple navigateur en mode kiosque affichant une page HTML légère, interroge la route toutes les deux minutes via une requête fetch() classique, sans nécessiter d’authentification puisque la carte des bières ne constitue pas une donnée sensible. Ce choix d’un intervalle de deux minutes, plutôt qu’un rafraîchissement instantané par websocket, a été retenu pour sa simplicité : la disponibilité d’un fût ne change pas assez souvent pour justifier une infrastructure temps réel plus complexe.
async function rafraichirCarte() {
const reponse = await fetch('/wp-json/brasserie/v1/carte');
const carte = await reponse.json();
afficherCarte(carte);
}
setInterval(rafraichirCarte, 120000);
rafraichirCarte();
Ce que le shortcode conserve, ce que la route change
Le shortcode [carte_bieres] reste actif sur la page web classique du site vitrine, inchangé, car il répond toujours au même besoin d’affichage HTML simple. La nouveauté tient uniquement à l’ajout d’une seconde façon de consommer la même donnée source, sans dupliquer la logique de mise à jour de la carte : l’équipe en salle continue de modifier l’option depuis l’administration WordPress habituelle, et cette même modification alimente désormais aussi bien la page web que la borne.
- Aucune migration de données lourde : l’option existante a simplement gagné un champ booléen.
- Aucun nouveau type de contenu personnalisé créé, la carte restant une liste courte gérée comme un tout.
- Une seule route REST, sans authentification, car aucune donnée sensible n’y transite.
Notre verdict
Ce projet illustre qu’un shortcode ancien n’a pas besoin d’être jeté pour ouvrir une donnée existante à un nouveau canal de consommation. Ajouter une route REST minimale à côté d’un mécanisme d’affichage déjà en place coûte souvent moins cher, en temps de développement, qu’une refonte complète vers un type de contenu personnalisé, surtout lorsque le volume de données reste aussi modeste qu’une carte de sept bières mise à jour à la main chaque matin.