ÉTUDE DE CAS
Plateforme B2B de distribution alimentaire locale — construite à partir de 45 jours d'opération terrain, jusqu'à la production, en tant que seul product owner.
Un seul produit, trois interfaces en production : application producteur, catalogue restaurant, admin central.
LE PROBLÈME
En Savoie, les producteurs locaux n'avaient aucun canal professionnel pour atteindre directement les cuisines de restaurants. Les restaurants qui voulaient s'approvisionner en local n'avaient ni infrastructure de commande fiable, ni disponibilité en temps réel, ni offre de niveau professionnel. Chaque circuit passait par un intermédiaire-entrepôt qui captait la marge et faisait perdre la fraîcheur. Aucune infrastructure digitale n'existait pour le commerce alimentaire local B2B en direct, à l'échelle.
LE TERRAIN D'ABORD
La phase de discovery s'est appuyée sur des partenaires experts, une recherche terrain des deux côtés de la chaîne d'approvisionnement, un bootcamp en start-up studio et 45 jours d'opération comme grossiste alimentaire — avant d'écrire la moindre spec.
CONSTAT TERRAIN
La justesse des stocks était la douleur opérationnelle critique — les producteurs ne pouvaient pas communiquer leur disponibilité réelle de façon fiable.
DÉCISION D'ARCHITECTURE
La synchronisation des stocks producteurs en temps réel vers la couche e-commerce est devenue l'exigence technique centrale.
CONSTAT TERRAIN
Les erreurs de quantité et de qualité côté producteurs créaient des frictions.
DÉCISION D'ARCHITECTURE
Un workflow de préparation obligatoire avec confirmation de quantité et validation photo pour garantir la qualité.
CONSTAT TERRAIN
Le paiement devait attendre la confirmation du producteur, et non se déclencher à la commande.
DÉCISION D'ARCHITECTURE
Intégration de l'API Shopify Payments, avec libération du paiement liée aux quantités confirmées plutôt qu'à la commande.

System Design — les quatre parcours de parties prenantes cartographiés
Architecture complète conçue à partir du terrain. Quatre acteurs, analyse complète des pain points, décisions de workflow automatisées — documentées avant de construire la plateforme de production.
LA SOLUTION
Trois surfaces interconnectées sur une seule base de données partagée, chacune au service d'un acteur distinct, avec son niveau d'accès et son workflow automatisé.
Tableau de bord producteur — stocks et gestion des produits
Gestion des stocks en temps réel, notifications de commande, workflow de préparation structuré, confirmation quantité et photo.
Boutique restaurants — catalogue et disponibilité en direct
Plus de 1 200 références de 25+ producteurs dans un rayon de 50 km, disponibilité en temps réel, commande par créneau de livraison, Shopify Payments intégré.
Admin centrale — catalogue, producteurs et routage des commandes
Routage automatique des commandes vers les bons producteurs via le lien produit-producteur en base, suivi de la préparation, déclenchement de la logistique. Le partenaire logistique — la quatrième partie prenante — est servi par des emails de tournée automatisés, avec un human-in-the-loop à chaque étape.
UNE BASE DE DONNÉES PARTAGÉE
Chaque écran ci-dessus lit et écrit dans les mêmes enregistrements. Stock producteur, disponibilité restaurant, état de commande, libération du paiement et routage logistique ne forment qu'un seul jeu de données — c'est ce qui fait que l'ensemble se comporte comme un produit unique et non comme quatre outils déconnectés.

Le schéma partagé derrière chaque surface.
DÉCISIONS D'ARCHITECTURE CLÉS
QUATRE PARTIES PRENANTES
Une base de données partagée
LE STACK DE PRODUCTION
Lovable
Trois surfaces utilisateurs — build front-end et produit
Supabase
Base de données partagée — source de vérité unique pour tous les acteurs
Shopify Payments
API de paiement via boutique virtuelle mirrorée — traitement carte B2B optimisé en coût
Resend
Notifications email automatisées — commandes, confirmations, tournées logistiques
Notion
Base de connaissance opérationnelle et documentation interne
Claude a joué le rôle d'architecte pendant le build — le système en production, ce sont ces cinq outils.
DÉCISION 1
Une seule base de données partagée pour les trois surfaces.
POURQUOI
La synchronisation temps réel entre stock producteur et disponibilité restaurant exige une source de vérité unique. Trois bases séparées auraient créé des délais de sync qui cassent la promesse produit.
DÉCISION 2
API Shopify Payments via une boutique virtuelle mirrorée en base — pas Stripe.
POURQUOI
Les taux de traitement carte de Stripe étaient nettement plus élevés sur des transactions B2B. Une boutique Shopify virtuelle mirrorée en base donnait accès à l'infrastructure de paiement Shopify à un coût plus bas, tout en gardant le contrôle total de l'UX de commande.
DÉCISION 3
Libération du paiement liée à la confirmation de quantité par le producteur, pas à la commande.
POURQUOI
L'opération terrain a montré que les écarts entre quantité commandée et livrée étaient la première source de litige client. Retenir le paiement jusqu'à la confirmation du producteur protège à la fois le restaurant et la relation producteur.
DÉCISION 4
Human-in-the-loop dans l'admin centrale, pas d'automatisation totale.
POURQUOI
L'approvisionnement alimentaire local comporte une variabilité de qualité. Une automatisation sans point de contrôle propagerait les erreurs — mauvaise quantité, problème qualité — directement jusqu'au restaurant. Le système orchestre ; l'humain garde le contrôle aux points de décision critiques.
DU POC À LA PRODUCTION
PHASE 1
Airtable · Fillout · Make.com
Validation du modèle commercial sur le terrain en opérant comme un grossiste local avec une équipe de 2 personnes : de la découverte clients et producteurs, de l'onboarding et de l'approvisionnement jusqu'à la gestion des commandes, la logistique, la livraison et l'adoption. En 45 jours, 3 clients et 8 producteurs ont généré 10,5 K€ de chiffre d'affaires et plus d'une tonne de produits locaux livrés — validant le modèle avant de construire la plateforme complète.
CE QUE LE TERRAIN A CHANGÉ
Le POC n'avait aucun workflow de préparation pour les producteurs. En pratique, les erreurs de quantité et les problèmes de qualité à la collecte créaient friction et litiges. La plateforme de production a ajouté un workflow de préparation producteur obligatoire, étape par étape — confirmation de quantité, validation photo de la qualité — avant toute libération de paiement. La reconnaissance d'image par IA pour le contrôle qualité automatisé a été intégrée à l'architecture du workflow pour une implémentation future.
PHASE 2
Claude comme architecte · Lovable · Supabase · Shopify Payments · Resend · Notion
Construite immédiatement après le POC, chaque exigence centrale étant traçable jusqu'à une observation terrain.
CE QUE JE FERAIS DIFFÉREMMENT
« Commencer par l'admin centrale. C'est la couche d'orchestration dont tout le reste dépend. En construisant d'abord l'e-commerce et l'application producteurs, j'ai dû rétro-adapter la logique de routage. Partir du milieu — le système de coordination — aurait rendu toute l'architecture plus cohérente dès le premier jour. »
RÉSULTATS
producteurs activés
restaurants onboardés
références produits intégrées
de produits locaux livrés
de rétention client
d'adoption
PLATEFORME
CE QUE ÇA PROUVE
De l'étude de marché et la validation du business model au build solo de la plateforme, jusqu'à l'activation commerciale, l'intégration logistique, la formation des utilisateurs et l'itération continue.
Quatre parties prenantes, cinq outils, une base de données, des workflows automatisés — chaque décision d'architecture répond à une douleur opérationnelle précise identifiée sur le terrain.
100 % d'adoption autonome de la plateforme après formation. Producteurs, restaurants et partenaire logistique utilisent le système en autonomie, sans demande de support. C'est ça, une adoption durable.