Floural est une petite boulangerie-pâtisserie qui a grandi plus vite que son organisation. La propriétaire était à la fois le livre de recettes, la formatrice, l'arbitre des retards et la gardienne des dates de péremption. Nous lui avons construit un POS qui a pris en charge chacun de ces rôles — et quelques autres qu'elle ne savait pas encore vouloir — pour qu'un nouveau boulanger puisse assurer un service seul dès le premier jour.
Chacun de ces problèmes échouait de la même façon : la boulangerie tournait quand la propriétaire était là, et s'arrêtait quand elle partait. La commande était simple — sortir tout ça de sa tête et le mettre dans un système en qui le personnel a confiance.
Des photos WhatsApp, un carnet abîmé, et la mémoire de la propriétaire. Chaque nouveau boulanger imposait de réenseigner le même chiffon depuis le début — et de le rater légèrement à chaque fois.
Le personnel haussait les épaules : « ça a l'air frais. » Les clients ont fini par ne plus l'être. Un mauvais retrait de crème a plombé les avis d'un samedi entier.
Génoise, crème mangue, ganache — fabriqués en lots avec leur propre péremption. L'ancien POS les comptait comme un seul chiffre. Une crème de 6 jours était retirée avant une crème de 2 jours. Le FIFO était une idée, pas une règle.
Le POS était un tableur déguisé. Les catégories n'avaient pas de code couleur, les articles n'avaient pas de codes courts, l'écran n'avait aucun rythme. Les nouvelles recrues apprenaient par l'erreur — aux frais du client.
La propriétaire se souvenait de qui était en retard. Parfois. Les primes se transformaient en négociations. L'équité était ressentie, pas mesurée.
La clôture de journée représentait quatre rapprochements faits à la main. Le P&L par canal était une rumeur, pas un chiffre.
Chaque produit est construit à partir de composants (génoise, crème, ganache), eux-mêmes construits à partir d'ingrédients. Les recettes de la propriétaire vivent dans la base de données — une par composant, une par produit fini — et une tâche de production se résume à « choisir un composant, appuyer sur démarrer ».
Le système indique au boulanger les quantités exactes pour la taille de lot choisie, déduit les ingrédients à la validation au HPP moyen pondéré, et crée un nouveau lot de composant avec sa date de fabrication et sa date de péremption. La recette est la source de vérité. La propriétaire n'est plus le goulot d'étranglement.
MC-260422-A, péremption 25 avr. 2026 21:00, emplacement Réfrigérateur 2.
Chaque produit fini en vitrine a son propre seuil de durée de conservation (gâteaux ≠ viennoiseries ≠ pain). Quand une unité est placée en vitrine, le compteur démarre. L'écran affiche une barre colorée qui passe du vert au jaune au rouge — le personnel et la propriétaire voient la même chose depuis n'importe où dans la salle.
Rouge atteint ? L'unité passe dans le registre de déchets avec un motif catégorisé — jamais juste « jeté » — pour que la propriétaire puisse voir si c'est de la surproduction, une mauvaise manipulation ou une contamination, mois après mois.
Quand un boulanger assemble un gâteau fini, le POS ne demande pas « est-ce qu'il y a de la crème ? » — il choisit le lot de crème dont la date de péremption est la plus proche et qui en contient encore assez, le déduit, et note l'origine du lot sur la ligne de commande.
Si le boulanger contourne le FIFO (rare, parfois justifié), cela est enregistré avec un motif. La perte d'un lot entier apparaît dans le tableau des déchets au HPP, pas au prix de vente — la propriétaire voit le vrai coût.
| Lot | Fabriqué | Péremption | Restant | Empl. | Statut |
|---|---|---|---|---|---|
| MC-260420-B | 20 avr. 06:30 | 23 avr. 06:30 | 340 g | Réfrig. 1 | RETIRER EN 1er |
| MC-260421-A | 21 avr. 14:10 | 24 avr. 14:10 | 1,820 g | Réfrig. 2 | FILE D'ATTENTE |
| MC-260422-A | 22 avr. 09:05 | 25 avr. 09:05 | 2,000 g | Réfrig. 2 | FILE D'ATTENTE |
Chaque produit a un code court de 2 à 4 lettres, une couleur de catégorie, et une position fixe dans la grille définie par la propriétaire. Les nouveaux caissiers apprennent la disposition en une heure parce qu'elle ne change pas. La recherche se fait par code court ou par nom — rapide pour les habitués, indulgente pour les stagiaires.
Le passage en caisse tient en un seul écran : articles, client (facultatif, avec points de fidélité), mode de paiement (espèces, QRIS, virement, GoFood, ShopeeFood, acompte), terminé. Le tiroir-caisse s'ouvre automatiquement en cas de paiement en espèces ; le montant remis et la monnaie sont calculés ; le reçu s'imprime ; l'identifiant de commande est la date plus le numéro de séquence.
Le personnel pointe en selfie au début de son service (Pagi 07:00, Siang 15:00, Malam 21:00). Le système lit l'horodatage, applique la tolérance configurée (5 min), et convertit chaque minute au-delà en « points de retard » au taux fixé par la propriétaire — 1 point par 5 minutes de retard, Rp 3 000 par point.
En fin de mois, prime = base − (points de retard × pénalité). La propriétaire valide une seule fois. Les contestations tombent à zéro parce que le calcul est à l'écran, photos à l'appui.
Chaque canal — sur place, à emporter, GoFood, ShopeeFood, précommande avec acompte — enregistre dans la même table de commandes avec un marqueur de canal. Le rapprochement de fin de journée tient en un seul écran, pas quatre. Le P&L par canal est un filtre, pas un projet.
Et la couche bonus : points de fidélité client (1 par Rp 1 000 dépensés, expiration selon la règle de la propriétaire), registre de déchets catégorisé avec estimation de la perte en Rp, stock d'emballages qui se décrémente automatiquement à chaque vente, et un journal d'audit global pour que chaque chiffre à l'écran soit traçable jusqu'à une personne et un instant.
Nous n'avons pas forké un POS existant. Nous avons passé les trois premiers jours dans la boulangerie à observer. Le modèle de données — trois niveaux, lots, FIFO, durée de conservation — était sur tableau blanc avant qu'une seule ligne de code soit écrite.
Présence dans la boulangerie. Chaque recette — génoise, crème, ganache, chaque produit — saisie dans des schémas structurés de composants et produits. Le modèle de données est devenu le livre de recettes.
Construction de ingredients → components → products → shelf_items avec tables de lots pour les composants et instances en vitrine. HPP moyen pondéré sur chaque réception et chaque tâche de production.
Écran de tâche de production avec la recette sous forme de liste de contrôle. Seuils de durée de conservation par produit (heures vert/jaune/rouge) reliés à des barres colorées en direct. Registre de déchets avec motifs catégorisés.
Grille de tuiles avec codes courts, commandes marquées par canal, passage en caisse en un seul écran, flux acompte + solde pour les précommandes. Caissier formé en 90 minutes avec un script d'une page.
Pointage en selfie, configuration des points de retard, flux brouillon de prime mensuelle → validation. Tiroir-caisse avec rapprochement ouverture / ventes / décaissements / clôture. Journal d'audit sur chaque mutation.
Deux nouveaux boulangers recrutés comme test. Les deux ont assuré un service complet seuls en fin de semaine — recettes depuis l'écran, FIFO depuis l'écran, décisions de vitrine depuis l'écran. La propriétaire est restée chez elle un samedi.
Pas de chiffres fabriqués mois après mois — le système est en phase de démarrage. Voici les processus qui ont quitté les épaules de la propriétaire pour s'installer dans l'écran.
Chaque recette en base de données, versionnée. Les nouveaux boulangers lisent l'écran, pas la propriétaire.
Grille de tuiles + codes courts + passage en caisse en un écran. La nouvelle recrue prend de vraies commandes dans la première heure.
Ingrédients → composants → produits. Lots de composants retirés du plus ancien au plus récent, automatiquement.
Chaque unité en vitrine a une barre colorée en direct. « Ça a l'air frais ? » est remplacé par « c'est vert ? »
Minutes de retard → points de retard → déduction en Rp. Photos et horodatages. La propriétaire valide une fois.
Sur place, GoFood, ShopeeFood, précommande : tout s'enregistre dans la même table de commandes. La clôture de journée tient en un écran.
Installable sur la tablette Android du personnel. Pas de framework — chaque écran est un module JS unique que le neveu de la propriétaire (étudiant en informatique) peut lire. Le service worker maintient le POS en vie quand le wi-fi vacille.
Routage par action (?action=), PDO natif, JWT. Schéma de 25 tables couvrant paramètres, utilisateurs, produits/composants/ingrédients avec recettes, lots, vitrine, présences, primes, emballages, déchets, audit.
Ingrédients (bruts) → composants (semi-finis, en lots, suivi de péremption) → produits (finis, liés à une recette) → unités en vitrine (horodatées à la mise en place). HPP moyen pondéré à chaque niveau.
Pointage en selfie avec détection de service, tolérance + pénalité configurables, brouillons de prime mensuelle. Tiroir-caisse par jour avec rapprochement ouverture / ventes / décaissements / clôture. Chaque mutation dans le journal d'audit associée à un utilisateur + une IP.
Un appel de cadrage gratuit. Nous vous dirons ce qui mérite d'être construit et ce qui ne le mérite pas.