Le WordPress d'aujourd'hui, décodé pour les développeurs

Headless & API

Des boulangers indépendants centralisent leurs horaires via une API commune

Comment un réseau de boulangeries artisanales expose horaires et produits du jour via un endpoint commun, consommé par plusieurs vitrines indépendantes.

Par Clément Hadrot • 2 décembre 2024 • 4 min de lecture • Aucun commentaire
Des boulangers indépendants centralisent leurs horaires via une API commune

« Est-ce que le pain aux céréales est encore disponible à 18 heures ? » Cette question, neuf boulangeries indépendantes regroupées sous une même enseigne collective, que nous appellerons Le Fournil des Gones, la recevaient chaque jour par téléphone. Chaque boutique avait son propre site, parfois un simple Google Sites, parfois rien du tout, et aucune ne mettait à jour ses horaires de façon fiable.

Plutôt que de forcer les neuf boutiques à adopter le même site, l’idée a été de centraliser les horaires et la liste des produits du jour dans un unique WordPress, puis d’exposer ces informations via un endpoint REST commun. Chaque boutique garde son site existant, avec son identité propre, mais y intègre un petit script qui interroge l’API centrale.

Modéliser une boutique et ses horaires

Le WordPress central héberge un type de contenu personnalisé boutique, avec des champs personnalisés pour les horaires par jour de semaine et un champ répétable simple pour les produits du jour, stocké en JSON dans une seule métadonnée pour éviter de multiplier les tables. Chaque boutique dispose d’un identifiant stable, utilisé ensuite comme paramètre de filtrage.

Un endpoint filtré par identifiant de boutique

L'essentiel à retenir : Un WordPress central pour les horaires et produits du jour ; Un endpoint REST filtré par identifiant de boutique ; Chaque vitrine garde son propre design

L’endpoint personnalisé accepte un paramètre boutique et retourne uniquement les données de l’établissement demandé, ce qui évite à chaque vitrine de télécharger l’intégralité du réseau à chaque appel :

add_action( 'rest_api_init', function () {
    register_rest_route( 'fournil/v1', '/boutique/(?P<slug>[a-z0-9-]+)', array(
        'methods'  => 'GET',
        'callback' => 'fournil_get_boutique',
        'args'     => array(
            'slug' => array(
                'validate_callback' => function ( $valeur ) {
                    return is_string( $valeur );
                },
            ),
        ),
        'permission_callback' => '__return_true',
    ) );
} );

function fournil_get_boutique( WP_REST_Request $request ) {
    $slug    = $request->get_param( 'slug' );
    $article = get_page_by_path( $slug, OBJECT, 'boutique' );

    if ( ! $article ) {
        return new WP_Error( 'boutique_introuvable', 'Boutique inconnue', array( 'status' => 404 ) );
    }

    return rest_ensure_response( array(
        'nom'      => get_the_title( $article ),
        'horaires' => get_post_meta( $article->ID, 'horaires', true ),
        'produits' => json_decode( get_post_meta( $article->ID, 'produits_du_jour', true ) ),
    ) );
}

Chaque vitrine intègre un petit script JavaScript qui appelle cet endpoint au chargement de la page et affiche les horaires directement dans une zone dédiée du site existant, sans toucher au reste de la mise en page.

Qui met à jour quoi, et comment

La centralisation pose une question organisationnelle autant que technique : qui saisit les produits du jour ? La réponse retenue a été simple, chaque gérant de boutique reçoit un accès à l’éditeur de blocs, limité par un rôle personnalisé qui ne peut modifier que sa propre fiche boutique, grâce à une vérification de capacité ajoutée sur les hooks de sauvegarde.

  • Un rôle gerant_boutique créé avec add_role(), doté uniquement des capacités nécessaires.
  • Un filtre sur map_meta_cap qui restreint l’édition à la fiche associée au compte connecté.
  • Une mise à jour possible depuis un téléphone, en salle de vente, entre deux fournées.

Les limites assumées de cette architecture

Cette solution ne gère pas la commande en ligne ni le paiement, ce qui n’était d’ailleurs pas la demande du réseau : l’objectif se limitait à afficher une information fiable, pas à vendre du pain à distance. Le risque principal reste la disponibilité du WordPress central : si l’hébergement tombe, les neuf vitrines perdent l’affichage des horaires en même temps. Une mise en cache côté navigateur, avec une durée de vie courte de quelques minutes, limite l’impact d’une indisponibilité passagère.

Neuf sites différents peuvent partager une seule source de vérité sans jamais partager le même design : c’est tout l’intérêt d’un endpoint pensé pour être consommé de l’extérieur.

En résumé

Un réseau d’artisans n’a pas besoin d’un site unique pour parler d’une seule voix sur ses horaires : un WordPress central, un endpoint REST filtré par boutique et quelques lignes de JavaScript suffisent à unifier l’information sans uniformiser les vitrines.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi