Une usine, deux marchés : comment une chaîne de boulangerie synchronise ses recettes avec Dynamics 365

Un croissant traverse une frontière chaque matin

Chaque matin, des camionnettes chargées de viennoiseries, de pain de sandwich et de gâteaux quittent une usine de production et traversent une frontière terrestre vers un marché voisin avant que le premier client n’entre dans une boutique. Le groupe derrière ce trajet n’a rien d’exceptionnel : une enseigne régionale de boulangerie-café avec son propre réseau de magasins, selon un modèle courant chez les chaînes nées dans un pays et qui se sont développées dans un pays voisin où le coût du foncier et de la main-d’œuvre rend la production locale plus difficile à mettre à l’échelle. Un pays fabrique ; l’autre vend surtout.

Ce modèle fonctionne commercialement. Sur le plan opérationnel, il crée un problème qui apparaît discrètement, des mois après que le premier camion a franchi la frontière : l’usine fonctionne avec des recettes, et le groupe fonctionne avec Microsoft Dynamics 365. Pendant longtemps, ces deux systèmes ne se sont pas parlé.

Ce que Dynamics 365 sait, et ce qu’il ne sait pas

Dynamics 365 fait exactement ce qu’on attend d’un ERP dans l’industrie alimentaire : commandes d’achat aux fournisseurs de farine et de beurre, bons de réception à quai de l’usine, facturation intersociétés entre l’entité de fabrication et l’entité de vente de l’autre côté de la frontière, valorisation des stocks, consolidation financière au niveau du groupe. Rien de tout cela n’est en cause — l’équipe finance de l’usine gère Dynamics 365 très correctement.

Ce que Dynamics 365 ne sait pas, c’est ce qui se passe dans le pétrin. Il enregistre que l’usine a acheté 800 kilogrammes de beurre à un certain prix. Il ne sait pas combien de beurre entre dans un seul croissant, quel est le rendement après pousse et cuisson, ce que doit indiquer la déclaration allergènes une fois ce beurre associé à la farine de blé et aux œufs, ni comment une modification de formulation pour le marché voisin — un taux de sucre réduit pour atteindre une meilleure note nutritionnelle en face avant d’emballage, par exemple — change le coût par unité. Cet écart entre ce que voit la finance et ce que produit l’usine est précisément l’endroit où deux problèmes apparaissent en même temps : une dérive des coûts que la finance ne remarque qu’en fin de mois, et des étiquettes allergènes ou nutritionnelles qui prennent du retard sur la recette réelle.

Une couche de recettes entre le four et le grand livre

La solution n’est pas de demander à Dynamics 365 de devenir un système de boulangerie — il n’a jamais été conçu pour cela, et le forcer produit exactement le genre de contournement qui érode l’intégrité des données d’un ERP. La solution consiste à donner à l’usine une couche de recettes et de production qui parle le langage de l’usine — formulations, rendements, sous-recettes, tailles de lots — et qui se réconcilie automatiquement avec le langage de Dynamics 365, celui des commandes d’achat et des mouvements de stock.

En pratique, cela signifie que la formulation de référence de chaque produit — la recette maîtresse avec ses ingrédients, ses pourcentages de boulanger et ses étapes de process — vit à un seul endroit, partagé entre les deux marchés. Quand un boulanger de l’usine ajuste une recette (un mélange de matière grasse différent, une garniture reformulée), le système recalcule, dans le même mouvement : la déclaration allergènes, les valeurs nutritionnelles requises pour l’étiquetage dans le marché voisin, et le coût réel par unité à partir des prix d’ingrédients déjà remontés depuis les données d’achat de Dynamics 365. Ce résultat chiffré — le coût standard d’un produit fini — est ce qui remonte ensuite dans Dynamics 365 comme base pour la valorisation des stocks et le prix de transfert intersociétés, au lieu d’une estimation tenue à la main qui se périme silencieusement dès qu’un fournisseur change son prix.

La conformité voyage avec la recette, pas derrière elle

Pour une usine qui expédie vers un second marché, cela compte doublement. Deux marchés voisins partagent rarement des exigences identiques d’étiquetage et de sécurité alimentaire, et une modification de recette faite pour l’un d’eux — réduire le sucre pour améliorer la note nutritionnelle en face avant d’une pâtisserie, par exemple — doit se répercuter partout où la recette est utilisée : l’étiquette imprimée à l’usine, le tableau nutritionnel affiché en point de vente, et l’enregistrement de traçabilité qui relie un lot fini aux lots d’ingrédients précis pour les régulateurs des deux marchés.

Sans une source unique de vérité pour la recette, c’est exactement là que les choses dérivent : l’usine met à jour la formulation, mais le modèle d’étiquette, les données nutritionnelles du point de vente et l’enregistrement de coût de l’ERP se mettent à jour selon trois calendriers différents, quand ils le font. Quand la production, l’étiquetage et le costing lisent la même recette, une seule modification se propage partout où c’est nécessaire, le jour même où elle est faite.

La finance voit l’usine, pas seulement la facture

L’avantage commercial tient moins au logiciel qu’à ce qu’il rend visible. Quand l’équipe finance du groupe peut voir le coût réel et actuel par unité — pas une répartition approximative — pour chaque produit qui traverse la frontière, des questions qui prenaient un mois à obtenir une réponse deviennent immédiates : un produit reste-t-il rentable après une hausse de prix fournisseur ? Le prix de transfert intersociétés entre l’usine et les magasins de l’autre côté de la frontière reflète-t-il toujours le coût de production réel ? Quelle ligne de produit grignote discrètement la marge parce que sa formulation a changé il y a des mois et que personne n’a recalculé le coût standard ?

C’est le même principe qui s’applique à tout groupe qui pilote plusieurs sites depuis une cuisine ou une usine centrale : l’ERP conserve son rôle de système de référence pour l’argent — achats, paiements, consolidation — et un système dédié de recettes et de production devient le système de référence pour ce que l’usine fabrique réellement. Dynamics 365 et la couche de recettes se mettent d’accord entre eux, au lieu que l’un dérive silencieusement de l’autre.

Prêt à connecter votre usine ?

Si votre groupe fabrique dans un marché et vend dans un autre — ou pilote plusieurs usines qui alimentent plusieurs pays — le même schéma s’applique quel que soit l’ERP au centre du dispositif. CalcMenu est conçu pour se placer aux côtés de Dynamics 365 ou de tout autre ERP, jamais à sa place, afin que vos recettes, vos coûts et vos données de conformité restent synchronisés avec le système que votre équipe finance utilise déjà en confiance.

Réservez un appel de 15 minutes avec Marc sur https://calendly.com/marceng/15-min-call-calcmenu-marc pour voir comment une couche de recettes connectée fonctionnerait pour votre usine.