Modifier un menu sur 100 établissements ne devrait pas prendre une semaine

Chez la plupart des exploitants CHR multi-établissements, le plan de projet pour « mettre à jour le menu de printemps sur l'ensemble du parc » s'étend sur quatre pages et trois semaines.

Semaine un : l'outil d'ingénierie du menu (costing, vérification des allergènes, photos, validation par le chef exécutif). Semaine deux : la coordination du déploiement (e-mails aux directeurs d'établissement, fiches de formation pour les brigades de cuisine, documents de FAQ pour le personnel de salle). Semaine trois : le déploiement technique à proprement parler (exportation du nouveau menu depuis l'outil d'ingénierie du menu, téléversement sur le portail du fournisseur d'EPOS, déploiement sur chaque caisse, mise à jour séparée du CMS du site web, nouvelle synchronisation séparée vers la plateforme de commande en ligne, vérification que les tablettes de room service reçoivent la même version du menu, et enfin, croisement de doigts pour que les écrans de commande par QR code dans les jardins pointent vers le bon fichier de menu).

Pendant le déploiement, différentes caisses au sein d'un même établissement peuvent afficher des versions de menu différentes pendant des heures. Le site web peut afficher des prix qui ne correspondent pas à la caisse. Le canal de commande en ligne peut promouvoir des plats que la cuisine a déjà retirés. La tablette en chambre peut être encore sur le menu de la saison dernière parce que personne ne savait qu'elle devait être mise à jour séparément.

Ce n'est pas une exagération. C'est la réalité opérationnelle de chaque groupe CHR multi-établissements utilisant un écosystème hérité. Le directeur Restauration (F&B) l'a acceptée comme le coût de fonctionnement inévitable. L'équipe informatique a cessé de s'enthousiasmer pour les déploiements de menus. L'équipe du service client dispose de scripts pour gérer les inévitables réclamations du type « mais le site web indiquait £14 ».

Cet article explique pourquoi il n'est pas nécessaire qu'il en soit ainsi, et à quoi ressemble l'architecture lorsqu'il en va autrement.

La raison architecturale de la lenteur des déploiements de menus

Cette lenteur a une cause sous-jacente : dans la plupart des écosystèmes, le menu est dupliqué sur chaque système qui doit en avoir connaissance. L'EPOS a sa copie. Le CMS a sa copie. La plateforme de commande en ligne a sa copie. La tablette en chambre a sa copie. L'écran de commande QR a sa copie. L'outil d'ingénierie du menu a sa copie. Chaque copie réside dans une base de données différente avec un schéma différent, appartenant à un fournisseur différent.

Lorsque le menu change, chaque copie doit être mise à jour. Chaque mise à jour est une opération distincte. Chaque opération a ses propres modes de défaillance. La couche d'intégration censée les maintenir synchronisées n'existe que partiellement, fonctionne selon son propre budget de latence, et échoue silencieusement de manières qui se traduisent par des réclamations clients deux jours plus tard.

La raison d'être de cette architecture est historique. Chaque système a été acheté séparément, à des moments différents, pour des raisons différentes. L'outil d'ingénierie du menu était la dernière acquisition. L'EPOS résultait d'une décision d'achat de 2018. Le CMS était antérieur à cela. Chaque fournisseur a construit son propre modèle de menu parce qu'il le devait. Son produit nécessite une structure de menu pour fonctionner, et aucun d'entre eux ne pouvait compter sur la disponibilité de la structure d'un autre fournisseur.

Ainsi, chaque exploitant utilisant un écosystème fragmenté se retrouve avec cinq ou six « menus » qui décrivent tous les mêmes plats. Et chaque exploitant a mis en place un flux de travail (formalisé ou informel) pour maintenir ces cinq ou six menus synchronisés. Et chaque exploitant a accepté le fait que cette synchronisation échoue parfois.

Ce qui change lorsqu'il existe un menu canonique unique

L'architecture mDOS adopte une position différente. Il n'y a qu'un seul menu. Il est conservé une seule fois pour l'ensemble de l'entreprise, avec ses catégories et ses plats associés. Chaque établissement y est simplement affecté : pas une copie du menu, juste une affectation, avec un ensemble de dérogations (overrides) optionnel pour les différences spécifiques à l'établissement.

Il s'agit d'un modèle de données fondamentalement différent. Il n'y a aucune duplication. Le site web, l'EPOS, la tablette en chambre, l'écran QR et le canal de commande en ligne lisent tous les mêmes enregistrements de plats. Une modification apportée à un plat ne nécessite aucune synchronisation par interface, car il n'existe qu'une seule copie.

Comme chaque interface lit à partir de cette source unique, toute modification apportée au menu est reflétée dès que le menu est résolu (un chargement de page, la récupération du menu par un terminal). Il n'y a aucune copie à déployer ni à réconcilier entre les différents fournisseurs. Pour la seule modification qui doit s'appliquer en plein service sans attendre une nouvelle récupération (le passage en rupture/« 86 » d'un plat qui vient d'épuiser ses stocks), un canal de diffusion en direct pousse la modification sur chaque interface connectée en temps réel (voir la section sur la rupture / 86 ci-dessous).

Latence mesurée entre le moment où l'exploitant clique sur « Enregistrer » dans le créateur de menu et le moment où la modification est en ligne sur chaque interface connectée de l'ensemble du parc : environ 200 milliseconds au 95e percentile.

Il ne s'agit pas d'un chiffre théorique. Une seule écriture dans la base de données, diffusée via un unique canal WebSocket, permet à chaque caisse de chaque établissement d'afficher le nouvel état en moins d'une demi-seconde. Il n'y a pas de fenêtre de désynchronisation des versions. Il n'y a pas d'étape de téléversement par terminal. Il n'y a aucune attente.

Le système de dérogations qui permet son fonctionnement à l'échelle du parc

Une architecture naïve à « menu unique » forcerait chaque établissement à être identique. L'hôtel de campagne proposant le menu dégustation à £180 et le bar à vin du centre-ville proposant des petites assiettes à £14 devraient utiliser des menus totalement séparés, ce qui annulerait les avantages de la centralisation.

mDOS résout cela grâce au système de dérogations (overrides). Le menu de base est défini une seule fois à l'échelle de l'entreprise. L'affectation de chaque établissement comporte un petit ensemble de dérogations pouvant modifier n'importe quel champ de n'importe quel article : prix, nom, description, disponibilité, allergènes, étiquettes diététiques, calories, image, type de boisson, TAV, disponibilité pour le room service, prix pour le room service, groupes de modificateurs, tarification des options de modificateur, placement par catégorie, disponibilité selon les créneaux horaires ou visibilité complète d'une catégorie.

Le résolveur s'exécute entièrement côté client après le chargement du menu. La cascade de résolution est base → groupe → établissement, la dérogation de l'établissement l'emportant au niveau de chaque champ. L'ensemble de dérogations est généralement inférieur à 1KB par établissement. La latence de résolution est inférieure à la milliseconde.

Ce que cela signifie sur le plan opérationnel : un groupe de 50 établissements peut disposer d'une définition unique de « menu de printemps » assortie de 50 ensembles de surcharges spécifiques à chaque établissement, gérant les prix locaux, le remplacement d'ingrédients régionaux, les plages de disponibilité propres à chaque lieu et les photographies spécifiques. Une modification apportée au menu de base (par exemple, la suppression d'un plat retiré de la carte) se propage instantanément aux 50 établissements. Une modification apportée à la surcharge d'un établissement (par exemple, l'augmentation du prix du steak dans l'établissement de Londres) n'affecte que cet établissement sans toucher à la base.

L'alternative héritée consiste en 50 fichiers de menus distincts, chacun géré manuellement et nécessitant sa propre mise à jour lorsque la base change. Les écarts entre ces fichiers sont inévitables. La charge administrative est considérable. Le risque d'erreur est permanent.

Le verrou de publication Natasha's Law

Au Royaume-Uni, le règlement sur l'information sur les denrées alimentaires (Food Information Regulation, communément appelé Natasha's Law) exige des exploitants du secteur CHR/restauration qu'ils fournissent des informations complètes sur les allergènes pour tout aliment préparé sur place et préemballé pour la vente. Les infractions entraînent d'importantes sanctions réglementaires et, dans des cas extrêmes, une responsabilité pénale.

La plupart des systèmes de gestion de menus du secteur gèrent la conformité aux allergènes au niveau du code applicatif. Le créateur de menu affiche un avertissement si des allergènes sont manquants. Le flux de travail de publication vérifie l'exhaustivité des données. Le matériel de formation rappelle au personnel de vérifier les allergènes avant la publication. Tout cela peut être contourné par un opérateur déterminé ou distrait.

mDOS traite la question directement au niveau de la base de données. Chaque plat du menu comporte un statut d'allergène. Les articles en attente de vérification ne peuvent pas être publiés : une règle de la base de données sur l'opération de publication du menu stoppe le processus si un article non vérifié est inclus. La vérification exige une action explicite : un utilisateur connecté disposant du rôle approprié marque l'article comme vérifié, et la base de données enregistre l'auteur et la date de la vérification pour le journal d'audit.

Il ne s'agit pas d'un choix d'ergonomie (UX), mais d'un choix d'architecture. La base de données refuse de publier des articles non vérifiés, quelle que soit l'interface qui tente la publication, quel que soit l'utilisateur qui l'effectue et quoi que le code applicatif juge acceptable. Le verrou de conformité ne peut pas être contourné car il est appliqué à la couche inférieure à l'application.

Pour les exploitants multi-sites, cela prend tout son sens lors des audits. Il est possible de présenter aux contrôleurs réglementaires ce verrou directement au niveau de la base de données. Non pas un document de politique interne, non pas un certificat de formation, mais la règle littérale de la base de données qui empêche toute publication non conforme. La posture de conformité passe ainsi du domaine procédural au domaine architectural.

Passage en rupture en temps réel (86'ing) : le moment de vérité opérationnel

Le lancement de menus est le scénario planifié. Le scénario non planifié (et celui qui compte le plus sur le plan opérationnel) est le passage en rupture (86'ing) en cours de service. La cuisine vient à manquer d'un ingrédient. Le plat doit être retiré du menu à l'instant même. Chaque point de vente ou support doit cesser de le vendre immédiatement.

Dans une architecture fragmentée, il s'agit d'un processus manuel. Le chef prévient le responsable de salle. Ce dernier se déplace vers chaque caisse et la met à jour. Le site web continue d'afficher le plat le temps que quelqu'un pense à le modifier. Le canal de commande en ligne continue d'accepter des commandes que la cuisine ne peut pas honorer. Les écrans QR en terrasse continuent de l'afficher.

mDOS gère la mise en rupture d'un simple bouton à bascule. Le responsable de salle appuie sur « Indisponible » pour le plat concerné dans l'interface de gestion du menu. La mise à jour marque le plat comme indisponible avec un horodatage, et un canal de diffusion en direct propre à votre entreprise pousse le changement vers chaque support connecté de façon quasi instantanée : chaque caisse cesse d'afficher le plat, chaque écran QR le grise, chaque interface de commande en ligne le marque comme épuisé et chaque tablette en chambre le masque.

La cuisine ne reçoit plus jamais la moindre commande pour le plat épuisé. Le chef n'a pas à présenter ses excuses à la table suivante. Le serveur n'a pas à effectuer un aller-retour embarrassé vers la cuisine. Le client ne subit jamais la déception de commander un plat qui ne peut pas lui être servi.

Pour les établissements à fort volume (vendredis soir très chargés, services complets, pics d'affluence dans une destination touristique), l'enjeu est colossal. Chaque minute de latence entre « déclaré épuisé » et « réellement épuisé partout » est une minute de problèmes qui s'accumulent. mDOS réduit cette latence à une demi-seconde.

Ce que cela signifie pour le directeur F&B

Pour le directeur Restauration (Food and Beverage) d'un groupe multi-sites, la gestion des menus a longtemps été l'une des contraintes les plus frustrantes au quotidien. La réalité technique a bridé ses capacités d'action. Le renouvellement saisonnier de la carte est un événement trimestriel nécessitant trois semaines de déploiement. Les ajustements en milieu de saison sont complexes sur le plan organisationnel. Ils exigent une coordination avec l'informatique, l'exploitation, le marketing et l'équipe marque. Le temps que l'ajustement soit déployé, l'opportunité est déjà passée.

Dans une architecture unifiée, le directeur F&B peut déployer les modifications de menus comme il l'entend vraiment. La carte de printemps est lancée le lundi matin dans les 200 établissements simultanément. Un ajustement en milieu de semaine basé sur les premières données de ventes est déployé le mercredi après-midi. Une promotion à durée limitée démarre le vendredi avec des surcharges au niveau de chaque établissement pour la tarification régionale. La technologie cesse d'être le frein bridant la fonction F&B.

Pour les acquéreurs évaluant mDOS en tant que propriété intellectuelle, la solidité architecturale du sous-système de gestion des menus constitue un signal révélateur. La plupart des SaaS du secteur CHR traitent la gestion des menus comme une fonctionnalité périphérique : un écran d'édition basique reposant sur la table de menus d'un fournisseur, avec une logique de propagation limitée. mDOS la traite comme un sous-système central avec la même rigueur que le moteur de paiement : modèle de données canonique à source unique, opérations atomiques, diffusion en direct des ruptures (86), verrous de conformité au niveau de la base de données. La profondeur d'ingénierie démontrée ici préfigure celle de l'ensemble de la plateforme.

---

Le sous-système de gestion des menus prend en charge la résolution base + surcharges, la diffusion en direct des ruptures (86) et le verrou de vérification des allergènes selon Natasha's Law. Documentation technique disponible sous accord de confidentialité (NDA) mutuel.