PC, PAK, CS, KG : le chaos des unités fournisseurs qui ruine silencieusement votre coût matière

Une liste de prix fournisseur comporte une ligne : Crème entière 35% — CHF 4.80 — PC. Que signifie « PC » ici ? Une bouteille d’un litre ? Un gobelet individuel de 200 ml ? Un bag-in-box de 5 litres ? L’abréviation ne le dit pas. Et, la plupart du temps, la personne qui la ressaisit dans votre système sous la pression d’un délai ne le sait pas non plus — elle retient la lecture la plus logique, passe à la suite, et la recette qui utilise cette crème affiche désormais un coût soit à peu près juste, soit faux d’un facteur cinq, sans aucun moyen de savoir lequel des deux rien qu’en regardant le chiffre.

Ce n’est pas un cas marginal et rare. C’est, d’après notre expérience de l’intégration de grandes cuisines d’entreprise dans des systèmes de recettes structurés, l’une des plus grandes sources de coût matière silencieusement faux — plus que la dérive des portions, plus qu’un prix obsolète, parce que cela ne produit pas un chiffre légèrement décalé. Cela produit un chiffre faux d’un multiple entier, déguisé en calcul précis.

Chaque fournisseur invente son propre alphabet

Il n’existe aucune norme partagée au moment où la plupart des cuisines passent réellement commande. L’export d’un fournisseur utilise « PC » pour pièce. Un autre utilise « PC » pour pack. Un troisième utilise « STK » (de l’allemand Stück), un quatrième « CT » pour carton, un cinquième « GEB » pour Gebinde — un terme allemand fourre-tout désignant « le contenant dans lequel ceci est expédié, quel qu’il soit ». Ajoutez « CS » pour caisse, « BTL » pour bouteille, « BUC » pour botte, et multipliez cela par le nombre de fournisseurs auprès desquels un groupe de cuisines de taille moyenne commande réellement — typiquement de huit à quinze, chacun avec son propre export de catalogue, souvent dans des langues différentes selon la région.

Ce n’est pas un problème résolu qui attend d’être adopté — c’est un problème difficile. GS1, l’organisme mondial de normalisation à l’origine des codes-barres, maintient une hiérarchie d’emballage formelle spécifiquement pour corriger cela : chaque unité physique — pièce, sous-emballage, caisse, palette — reçoit son propre identifiant unique, de sorte qu’« une caisse » corresponde toujours à une quantité exacte et sans ambiguïté plutôt qu’à une supposition. Cette norme existe précisément parce que le secteur a reconnu que l’ambiguïté des tailles de conditionnement était suffisamment importante pour justifier une solution mondiale. En pratique, la plupart des exports de listes de prix des fournisseurs de restauration de petite et moyenne taille ne la suivent toujours pas — ce qui signifie que l’ambiguïté retombe, non résolue, sur la personne qui saisit le produit dans votre système.

Ce qui dérape vraiment — trois cas concrets

La supposition sur la taille de caisse. Une ligne indique « 1 caisse — CHF 48.00. » S’agit-il d’une caisse de 6 unités ou d’une caisse de 12 ? En cas d’erreur, chaque recette utilisant ce produit est chiffrée à exactement le double ou la moitié de son coût matière réel — pas une erreur d’arrondi, un multiple net, qui survit à chaque calcul en aval en paraissant parfaitement plausible.

Le même ingrédient, trois contenants différents. La crème entière du fournisseur A arrive en bouteilles d’un litre. La même crème chez le fournisseur B est expédiée en bag-in-box de 5 litres. Un troisième fournisseur, format traiteur, vend des gobelets individuels de 200 ml. Si votre système traite la « crème » comme un seul produit interchangeable plutôt que comme trois fiches de conditionnement distinctes, le coût de la recette dépend entièrement de celle qui a été saisie — ou recommandée — le plus récemment, sans aucun signal indiquant que le chiffre a bougé.

L’unité cachée dans une description. Lors de l’intégration, il est fréquent qu’une part significative d’un catalogue de produits existant arrive sans aucun champ d’unité structuré — la taille du conditionnement se trouvant alors en texte libre dans le nom du produit : “Box 6x1kg”, “Carton de 24”. Un champ de description n’est pas une donnée qu’un moteur de calcul de coût peut exploiter. Chacune de ces lignes doit être rouverte manuellement et le chiffre réel extrait avant que le produit puisse être utilisé en toute confiance dans une recette — et tant que cela n’a pas été fait, le coût du produit est soit vide, soit à zéro, soit silencieusement faux.

Aucun de ces cas n’est un problème de formation. C’est ce qui se produit, de façon prévisible, au volume auquel fonctionne un vrai catalogue fournisseur — des centaines ou des milliers de lignes, plusieurs formats par fournisseur, ressaisies sous la pression du temps, sans aucune barrière structurelle empêchant une unité ambiguë d’atteindre une recette.

Pourquoi cela abîme le chiffrage plus que presque tout le reste

Les éditeurs de logiciels de chiffrage de recettes arrivent à la même conclusion depuis l’autre bout du problème : la taille du conditionnement et l’unité de mesure sont « les champs les plus responsables des écarts de coût matière » — avant la dérive des prix, avant la taille des portions. La raison est proportionnelle. Un prix obsolète peut être faux de 5 à 10 %. Une conversion d’unité erronée est fausse du multiple de conditionnement réel — 2x, 6x, 12x — et elle corrompt silencieusement chaque plat utilisant ce produit, jusqu’à ce que quelqu’un finisse par auditer cette ligne précise.

Et cela s’accumule. Marge de contribution, ingénierie de la carte, écart entre théorique et réel — tout ce qui figure dans la série Rentabilité suppose que le coût des ingrédients qui l’alimente est réel. Un facteur de conversion erroné ne biaise pas seulement un chiffre ; il empoisonne chaque calcul construit par-dessus, exactement comme le fait une portion non définie — voir pourquoi « une portion » ne veut rien dire sans un chiffre pour la version côté dressage de ce même problème.

Comment gérer cela concrètement

La solution n’est pas une saisie de données plus soigneuse — des humains qui ressaisissent des milliers d’abréviations ambiguës sous la pression d’un délai produiront toujours un certain pourcentage d’erreurs. La solution est structurelle :

1. L’unité d’achat et l’unité de recette sont deux champs distincts, reliés par un chiffre explicite. Ne laissez jamais « la façon dont c’est acheté » et « la façon dont c’est utilisé » partager un seul champ, et ne laissez jamais la conversion entre les deux vivre dans une description en texte libre. « 1 caisse = 12 × 1 kg » est un chiffre, pas une phrase.
2. Une fiche produit par format de conditionnement réel. Si un fournisseur — ou trois fournisseurs différents — vendent le même ingrédient dans des tailles de contenant différentes, cela donne plusieurs fiches produit avec leurs propres facteurs de conversion, et non une seule fiche avec une valeur par défaut supposée juste la plupart du temps.
3. Pas de facteur de conversion, pas d’utilisation en recette. Un produit sans conversion achat-recette confirmée ne devrait tout simplement pas pouvoir être utilisé dans le chiffrage — mieux vaut un manque évident signalé, à combler par quelqu’un, qu’un chiffre faux d’apparence plausible que personne ne remet en question.
4. Auditez les unités avant de toucher aux prix. Lors de la mise en service d’un nouveau site ou d’un nouveau catalogue fournisseur, le champ unité est ce qu’il faut vérifier en premier — un prix correct associé à un facteur de conversion erroné donne toujours un coût faux. Corriger les prix avant les unités, c’est résoudre le plus petit problème en premier.
5. Revérifiez la conversion à chaque changement de format de conditionnement. Les fournisseurs changent bel et bien de taille de conditionnement — une boîte de 5 litres devient une boîte de 3 litres, une caisse de 6 devient une caisse de 4 — généralement sans prévenir. Si rien n’impose une révision du facteur de conversion à ce moment-là, l’ancien multiple continue de s’appliquer indéfiniment à la nouvelle réalité.

Rien de tout cela ne supprime le besoin d’une balance et d’un œil exercé, pas plus que la discipline des portions ne le fait. Ce que cela supprime, c’est la version silencieuse de l’erreur — celle qui ressemble à un chiffre réel, qui survit à chaque rapport, et qui ne refait surface que des mois plus tard sous la forme d’une marge qui s’est érodée en silence et que personne ne peut expliquer.

À lire également

• Le premier article de la série Rentabilité — les fondamentaux du calcul du coût matière réel d’un plat.
• Pourquoi « une portion » comme consigne orale produit trois assiettes différentes selon trois cuisiniers — et ce qu’il faut écrire à la place.

---

Vous migrez un catalogue fournisseur et vous n’êtes pas sûr de savoir quelles conversions sont réellement fiables ? Réservez un appel gratuit de 15 minutes avec notre équipe — sans engagement : Planifier un appel.

Sources et lectures complémentaires

• GS1 Package and Product Measurement Standard
• GS1 GTIN Allocation Rules for Foodservice
• Bad unit conversions poison your costs silently — Recipe Cost Calculator
• Recipe Costing Best Practices for Restaurants — meez
• Restaurant plate and menu costing 101 — MarginEdge