Une recette, des milliers d'étiquettes : garder l'ERP, CalcMenu et les déclarations d'ingrédients synchronisés

Une production pilotée par les commandes, pas par un menu fixe

Un fabricant à façon — une boulangerie qui produit des viennoiseries pour une marque de distributeur, une usine de sandwichs qui approvisionne des comptes retail et restauration collective, un producteur de plats préparés qui travaille pour plusieurs marques propres — ne fonctionne pas à partir d’un menu hebdomadaire fixe comme le ferait un restaurant. La production dépend de ce que les clients ont réellement commandé ce jour-là, et ces commandes arrivent généralement via un ERP — souvent quelque chose comme Oracle — qui détient les bons de commande, les lignes de commande et les quantités. Ce qui sort de la ligne de production demain matin, c’est ce que dit l’ERP avoir été commandé — pas ce qui était planifié le mois dernier.

Cela crée un problème d’intégration spécifique que la plupart des logiciels de recettes destinés à la restauration n’ont jamais à résoudre. Un système de gestion de recettes comme CalcMenu détient l’aliment lui-même — la recette, son coût, sa valeur nutritionnelle, ses allergènes. Un système d’étiquetage comme BlazeIQ Labels détient ce qui s’imprime réellement et part sur l’emballage. Aucun des trois systèmes n’a tort de posséder ce qu’il possède. Le problème, c’est que par défaut, personne ne possède la transmission quotidienne entre eux — et sans elle, quelqu’un finit par ressaisir à la main les quantités de la commande du jour dans le système d’étiquetage, exactement au moment de la journée où une erreur a le plus de chances de se produire et le moins de chances d’être repérée.

Ce qui doit circuler de l’ERP jusqu’à l’étiquette — et pourquoi le QUID est la partie difficile

Le flux mécanique est simple à décrire : une ligne de commande arrive depuis l’ERP, CalcMenu la résout en une recette, et cette recette est mise à l’échelle sur la quantité de lot réellement produite lors de cette production — pas un rendement de référence figé depuis des mois. À partir de là, trois types de données de déclaration doivent atteindre l’étiquette, correctement, à chaque fois :

La liste complète des ingrédients. Pas seulement « ce qu’il y a dedans », mais le QUID — la déclaration quantitative des ingrédients que le droit alimentaire européen et suisse impose pour tout ingrédient nommé ou mis en avant sur l’emballage (le « Poulet (30%) » sur l’étiquette d’un sandwich au poulet est une déclaration QUID). Le QUID n’est pas un chiffre fixe par recette : il doit être recalculé selon les quantités réellement entrées dans ce lot précis, ce qui explique justement pourquoi une étiquette statique préimprimée ne fonctionne pas à des volumes pilotés par la commande — le pourcentage peut réellement varier d’un lot à l’autre, d’une production à l’autre.

Les allergènes. Comme la base de données des recettes est la source unique de vérité sur ce qui compose réellement une formulation, les données d’allergènes n’ont pas besoin d’être ressaisies séparément par référence, par production ou par marché — elles découlent du même enregistrement de recette qui vient de générer le calcul QUID un instant plus tôt.

La langue. Un fabricant à façon qui approvisionne des comptes dans plusieurs marchés a besoin que la même recette produise des étiquettes dans la langue exigée par ce marché — le français une semaine, l’allemand la suivante — sans passe de traduction séparée par étiquette, par référence, par langue. Cela ne fonctionne que si les noms d’ingrédients et les termes d’allergènes existent comme données structurées sur la recette, et non comme du texte libre que quelqu’un saisit à la main dans un gabarit d’étiquette.

Pourquoi cela ne fonctionne que si c’est conçu pour évoluer

Ce type de flux tourne sans surveillance, tôt le matin, sur le volume que l’ERP a transmis ce jour-là — ce qui signifie qu’il doit encaisser une variabilité qu’un export ponctuel n’a jamais à affronter. Les volumes de commande varient d’un jour à l’autre. De nouvelles variantes de recettes s’ajoutent pour de nouveaux comptes. Un produit arrêté doit cesser de générer des étiquettes sans que quelqu’un ait à penser à le désactiver à la main. Les changements d’imprimante ou de format d’étiquette suivent leur propre calendrier, indépendant du côté recette. Une interface conçue comme un script rigide unique casse dès le premier de ces cas ; une interface construite avec une couche de correspondance claire entre les données de commande de l’ERP et les données de recette de CalcMenu absorbe chaque changement comme une mise à jour ciblée plutôt que comme un projet à renégocier.

L’avantage, concrètement

Bien fait, cela supprime un risque précis et récurrent plutôt que d’ajouter une fonctionnalité pour elle-même :

1. Plus de ressaisie des données d’ingrédients ou d’allergènes, par référence, par production ou par marché — elles existent une seule fois, sur la recette, et atteignent l’étiquette automatiquement.
2. Les pourcentages QUID sont recalculés sur le lot réellement produit, et non sur une recette de référence statique qui dérive silencieusement dès que la spécification d’un fournisseur change.
3. Les étiquettes multilingues partent d’un seul enregistrement de recette, sans projet de traduction séparé à chaque nouveau marché.
4. Le flux encaisse les variations quotidiennes de volume et les nouvelles variantes de recette parce qu’il est conçu pour tourner sans surveillance sur ce que l’ERP envoie, et non relancé à la main à chaque changement en amont.

Ce n’est pas un cas hypothétique — c’est la forme d’un flux que nous faisons tourner chaque jour pour un fabricant de sandwichs à façon qui approvisionne des comptes retail et restauration collective.

Ce schéma n’est pas spécifique aux sandwichs — tout fabricant à façon qui produit sur commande pour des comptes retail ou restauration collective rencontre le même risque de fragmentation dès qu’un ERP, un système de recettes et une imprimante d’étiquettes doivent s’accorder chaque jour sur les mêmes faits. C’est un proche cousin du schéma ERP/POS/CalcMenu que nous décrivons pour les opérations hôtelières multi-points de vente — le même problème sous-jacent, avec d’autres systèmes en face. Voir notre page fabricants alimentaires pour voir comment cela s’applique plus largement à la production pilotée par recette, et BlazeIQ Labels pour le volet étiquetage du dispositif lui-même.

---

Vous produisez face à un flux quotidien de commandes ERP, et vous êtes fatigué des listes d’ingrédients qui ne correspondent pas tout à fait à ce qui sort réellement de la ligne aujourd’hui ? Réservez un appel de 15 minutes : Planifier ici.

Découvrez le logiciel de gestion des recettes CalcMenu pour fabricants alimentaires et voyez comment il s'applique à votre cuisine.