Logiciel de pilotage et gestion des marges pour boulangerie

Le problème

Une pile de factures fournisseurs sur un coin de table, en papier ou en PDF dans une boîte mail qu’on rouvre rarement. Des fiches techniques calées une fois, rarement mises à jour. Et le prix du beurre qui grimpe au printemps sans que le coût matière de la viennoiserie bouge d’un centime dans le fichier Excel. En fin de mois, la question est toujours la même : est-ce qu’on gagne encore de l’argent sur ce produit, ou est-ce qu’on le vend à perte sans le savoir ?

Quand il y a plusieurs boutiques, ça se complique encore. Chaque site a sa mercuriale dans un coin, ses recettes légèrement différentes, et le gérant n’a aucune vue consolidée de ses marges. Un logiciel de pilotage des marges pour boulangerie sert exactement à ça : lire les factures fournisseurs, tenir les fiches techniques à jour et recalculer le coût de revient dès qu’un prix change, sur un site comme sur dix.

L’approche

C’est ce que j’ai construit avec Optimo France, éditeur d’un outil dédié aux boulangeries-pâtisseries. Le produit lit les factures fournisseurs, tient les fiches techniques et les marges à jour, pilote plusieurs boutiques depuis un seul tableau de bord, génère l’étiquetage INCO et la conformité RGPD depuis les données, et se vend par abonnement, avec des devis signés en ligne pour les besoins spécifiques. Voilà comment ça s’est monté, dans l’ordre.

Cadrer un socle resserré plutôt qu’un tout-en-un

Nous avons démarré par un MVP web utilisable au bureau comme au fournil, et placé la mobile dédiée et les modules avancés en phases chiffrées séparément. Un socle validable vite par de vrais boulangers, avant d’élargir.

Poser les règles avant d’écrire le code

Deux règles, écrites avant la première ligne. La première : les prix d’achat et les marges ne descendent jamais sur les appareils des profils terrain, y compris hors connexion. La seconde, sur l’IA : l’extraction des factures propose, l’humain valide. Une virgule mal lue sur une facture et c’est tout le calcul de rentabilité qui ment, donc aucun chiffre qui engage une marge n’est validé sans quelqu’un derrière.

Construire et faire tourner le socle multi-sites

Matières premières, recettes, coûts, marges, tableau de bord. Un client pilote plusieurs boutiques et chaque client est isolé des autres. La saisie terrain (stock, production, ventes) fonctionne sans réseau et se synchronise toute seule quand le wifi revient, sans enregistrer une donnée deux fois.

Étendre vers un produit facturable

Une fois le socle validé, le projet a continué : abonnement automatisé de bout en bout, devis sur mesure signés en ligne, conformité RGPD et étiquetage INCO générés depuis les données au lieu d’être ajoutés après coup.

Stack et choix techniques

Le moteur OCR a été choisi sur des critères écrits avant le premier test, entre avril et mai 2026 : au moins 85 % de lignes reconnues, au moins 95 % des totaux justes, au moins 80 % des adresses, moins de 10 secondes par facture. Les chiffres annoncés par les fournisseurs (92 à 96 % pour Mindee sur des factures structurées, 70 à 85 % brut pour un Tesseract auto-hébergé) n’ont servi qu’à écarter des options. C’est Claude en lecture native du PDF qui a été validé sur de vraies factures contre ces seuils, sans étape intermédiaire de conversion en texte qui abîme les tableaux denses.

Le cloisonnement financier est testé, pas seulement documenté. Les 33 points d’accès aux données financières sont cloisonnés par établissement et par rôle, et ce cloisonnement est couvert par des tests.

Pour la saisie en labo, l’application est une PWA avec une file d’attente locale : ce que tu saisis sans réseau part tout seul au retour de la connexion. Le cache hors-ligne est cloisonné par profil : les routes d’authentification et l’API ne sont jamais mises en cache, ce qui compte quand le labo et la vente se partagent la même tablette.

Le client pilote lui-même sa facturation et sa newsletter depuis son panel d’administration ; côté paiement : Stripe Checkout, Customer Portal et un webhook idempotent, implémentés dans la journée.

Le reste de la stack, pour qui veut vérifier : Next.js 16, Prisma 7, Postgres avec pgvector, Better-Auth, Resend, hébergement en France.

Résultat

La plateforme est en production depuis juin 2026, mise en service après 7 semaines de travail. Pas une maquette : un outil exploité en conditions réelles, sur lequel 965 commits, 56 migrations et 53 modèles de données se sont accumulés, avec plus de 900 tests automatisés et 14 décisions d’architecture écrites.

Sur ce projet, sept semaines ont suffi pour mettre un socle en production. Ce qui a fait la différence, c’est d’avoir commencé petit et livré tôt.

Questions fréquentes

Comment calculer le coût matière d’une recette en boulangerie ?

Tu pars de la fiche technique : chaque ingrédient avec sa quantité, multiplié par son dernier prix d’achat connu, divisé par le nombre de pièces produites. Le calcul est simple, le problème c’est de le tenir à jour. Dès que le prix du beurre change sur une facture, toutes les recettes qui en contiennent doivent être recalculées. C’est ce que fait l’outil : la facture met à jour la mercuriale, la mercuriale met à jour le coût matière, et la marge suit.

Comment automatiser la lecture des factures fournisseurs en boulangerie ?

Tu déposes la facture (PDF ou photo), un modèle de lecture en extrait les lignes, les quantités et les prix, puis quelqu’un vérifie avant que les chiffres entrent dans le calcul. Sur ce projet, ce dernier point n’est pas négociable : l’extraction fait gagner le temps de saisie, pas le temps de contrôle. Et le choix du moteur se juge sur des critères mesurables, pas sur une démo.

Comment gérer plusieurs boulangeries avec un seul logiciel ?

Il faut un outil multi-sites dès la conception, pas un compte par boutique. Dans ce cas, un client voit toutes ses boutiques dans un tableau de bord consolidé, avec des recettes et une mercuriale partagées, et chaque profil ne voit que ce que son rôle autorise : le laboratoire saisit sa production sans jamais accéder aux prix d’achat, même en travaillant hors connexion.

Que doit couvrir un logiciel de gestion des marges pour boulangerie ?

Le minimum, c’est la chaîne complète du prix d’achat à la marge : des factures fournisseurs lues automatiquement plutôt que ressaisies, une mercuriale qui se met à jour à chaque facture, des fiches techniques reliées à cette mercuriale, un coût matière recalculé dès qu’un prix bouge, et des marges lisibles par produit et par site. Il faut aussi des rôles, pour que le labo et la vente travaillent sans voir les chiffres du gérant, et un mode hors-ligne qui tienne au fournil, là où le wifi ne tient pas.

Si tu portes un logiciel métier pour un secteur précis et que tu cherches quelqu’un pour le construire et le faire tenir en production, c’est ce que je fais : un SaaS sur mesure, du périmètre resserré jusqu’à la mise en production.