Une recette, trois systèmes : garder un ERP, une caisse et CalcMenu synchronisés

Trois systèmes, un seul jeu de faits

Un grand établissement de restauration multi-points de vente — un resort avec plusieurs restaurants et bars, un stade avec des stands de restauration, une compagnie de croisière avec une dizaine de lieux de restauration à bord — fonctionne généralement sur trois systèmes distincts qui doivent tous s’accorder sur les mêmes données de base. Un ERP (souvent un système comme JD Edwards) pilote les achats : codes articles, unités de mesure et tarifs pour tout ce qui est acheté auprès des fournisseurs. Une plateforme POS (souvent un système comme Oracle Simphony) pilote la caisse : ce qui est vendu, à quel prix, dans quel point de vente. Et un système de gestion de recettes comme CalcMenu pilote la partie alimentaire à proprement parler : recettes, coûts, valeurs nutritionnelles et allergènes.

Aucun de ces trois systèmes n’a tort d’être la source de vérité pour ce qu’il gère. Le problème apparaît lorsque personne ne pilote la relation entre eux, et que quelqu’un finit par ressaisir manuellement le même article de marchandise dans deux ou trois endroits différents — avec la dérive inévitable qui s’ensuit.

Ce que l’interface doit réellement faire

Il est tentant d’imaginer « une interface ERP » comme un tuyau unique. En pratique, elle doit résoudre deux problèmes distincts, dans deux directions différentes :

Faire entrer les données d’achat. L’ERP est l’endroit où vivent les articles achetés : codes articles, unités et tarifs. Une interface qui lit cet export et le rapproche des fiches articles de CalcMenu évite qu’une équipe de cuisine ne ressaisisse des données d’achat qui existent déjà ailleurs ; elles circulent une seule fois et alimentent le coût, les valeurs nutritionnelles et les allergènes de chaque recette qui les utilise. Une difficulté fréquente : les ERP suivent souvent une unité de base (kilogrammes, litres) séparément d’une unité d’achat (pièce, carton, plateau) qui a son propre tarif — l’interface doit porter les deux, ainsi que le ratio entre elles, faute de quoi une recette valorisée au poids ne peut pas être réconciliée avec un stock acheté au carton.

Faire sortir le coût des recettes. Côté POS, ce dont la caisse a réellement besoin, ce n’est pas la recette telle que CalcMenu la voit — c’est le coût par portion effectivement vendue, rattaché à un point de vente précis. C’est un chiffre différent du coût par rendement de recette dès qu’interviennent des recettes de production en lot ; la logique d’export doit donc être construite pour la définition de la portion propre au POS, et non pour celle de CalcMenu.

Pour les établissements dotés de plusieurs points de vente reliés, partageant une même cuisine ou un même entrepôt, un troisième volet s’ajoute souvent : maintenir la liste des produits transférables de l’ERP alignée sur ce qui est réellement encore actif dans le système de recettes, afin qu’un article arrêté ne subsiste pas comme option valide pour déplacer du stock entre sites.

Pourquoi elle doit être conçue pour évoluer

Ce type d’interface n’est jamais vraiment « terminé ». Les conventions d’unités de mesure finissent par être normalisées après coup. La logique d’export vers le POS est corrigée le jour où quelqu’un remarque qu’elle remontait la mauvaise base de coût. Les produits arrêtés nécessitent leur propre traitement pour cesser d’apparaître là où ils ne devraient plus figurer. Et le système de recettes lui-même finit par migrer vers une nouvelle plateforme, ce qui suppose que l’interface migre avec lui plutôt que d’être reconstruite de zéro. Une interface conçue comme un tuyau rigide et unique casse au premier de ces changements ; une interface dotée d’une couche de correspondance claire entre systèmes absorbe chaque évolution sous forme de mise à jour ciblée et limitée.

L’avantage, concrètement

Bien conçue, ce type d’intégration supprime un coût récurrent précis, plutôt que d’ajouter une fonctionnalité pour la forme :

1. Aucune double saisie des données de marchandise. Codes articles, unités et tarifs n’existent qu’une seule fois, dans l’ERP, et alimentent automatiquement le calcul des coûts de recettes.
2. Le POS reflète le coût matière réel, pas une estimation périmée. Le menu engineering et l’analyse de rentabilité s’appuient sur des chiffres de coût par portion à jour, plutôt que sur un tableur mis à jour le trimestre précédent.
3. Les transferts entre points de vente ne dépendent plus de la mémoire de quelqu’un pour mettre à jour l’ERP à la main.
4. L’intégration survit au changement au lieu d’en subir les conséquences — les refontes d’unités de mesure, les corrections de l’export POS et les migrations de plateforme côté gestion des recettes deviennent toutes des mises à jour incrémentales plutôt que des projets à renégocier.

Ce schéma se retrouve partout où un établissement multi-points de vente exploite un service de restauration au-dessus d’un back-office d’entreprise : resorts, compagnies de croisière, restauration aérienne et groupes hôteliers multi-marques y sont tous confrontés dès qu’ils dépassent quelques points de vente. Consultez notre page Intégrations POS pour voir comment la couche d’intégration de CalcMenu applique le même principe à différentes plateformes ERP et POS.

---

Vous exploitez un service de restauration sur plusieurs points de vente au-dessus d’un parc ERP et POS, et vous en avez assez de ressaisir deux fois les mêmes données de marchandise ? Réservez un appel de 15 minutes : Prendre rendez-vous.