Marius
Marketplace multi-producteurs alimentaires / Architecture marketplace bâtie de zéro · Shopify + Odoo + n8n
Création d'une marketplace food multi-producteurs en projet personnel. Architecture complète : Shopify Plus en front, Odoo en back-office (catalogue mutualisé + comptabilité + split paiement), n8n pour l'orchestration des commandes split-producteur, et workflows IA pour le matching produit. Banc d'essai grandeur nature des patterns que je livre en mission.
Le contexte
Marius est un projet personnel — pas une mission client. Une marketplace food multi-producteurs que je construis sur mon temps pour deux raisons :
- Banc d’essai grandeur nature : tester les patterns marketplace (split paiement, split stock, comptabilité multi-producteurs, routage logistique) sur une vraie architecture en charge, avant de les proposer en mission client.
- Vraie marketplace, vrais producteurs : ouverture beta prévue 2026 sur un segment alimentaire premium (circuits courts, épicerie fine, vins, produits régionaux Occitanie).
Le but n’est pas de devenir un acteur marketplace majeur. C’est de garder un terrain de jeu où j’invalide les solutions techniques avant qu’elles arrivent chez un client payant.
Le problème marketplace food
Les marketplaces alimentaires existantes (épicerie, paniers, circuits courts) tournent à 90 % sur des templates Shopify avec un plugin multi-vendor (Shopify Collective, WeBuy, ou apps tierces). Ces plugins ne gèrent pas correctement :
- Séparation comptable par producteur : chaque producteur doit avoir ses propres écritures, sa propre TVA, son propre suivi de règlement
- Split de stock par origine : un même type de produit (du fromage, par exemple) peut venir de 5 producteurs différents avec stocks indépendants
- TVA différenciée : produits alimentaires à 5,5 %, 10 %, 20 % selon la catégorie + cas particuliers (vins, restauration, conserves)
- Routage logistique multi-points-de-départ : une commande à 3 producteurs = 3 expéditions distinctes ou 1 hub de consolidation
- Rapprochement bancaire automatique : qui a touché quoi, quand, et combien le marketplace garde en commission
Résultat : la majorité des marketplaces food vivent dans Excel pour la compta producteur, ressaisissent à la main, et se cassent dès qu’elles passent les 20 producteurs ou 1 K€/jour.
L’architecture testée
Shopify Plus en front (boutique unifiée)
Une seule boutique côté client, catalogue unifié multi-producteurs avec filtres par producteur, origine, certification (bio, AOP, IGP, label Rouge), allergènes. Theme Liquid custom, sections 2.0, optimisation Core Web Vitals.
Odoo 19 en back-office maître
Producteurs gérés comme des partenaires dans Odoo avec ACL différenciées (chaque producteur peut voir uniquement ses propres ventes). Catalogue maître avec mapping produit_marketplace → producteur_partenaire. Stock par producteur en multi-entrepôt Odoo natif. Comptabilité avec un journal des ventes par producteur + journal commission marketplace.
Connecteur Oodify étendu
Oodify (mon connecteur Shopify ↔ Odoo standard) étendu pour gérer la dimension marketplace :
- Mapping produit côté Shopify → producteur Odoo
- Split de commande au paiement : 1 commande Shopify devient N commandes Odoo (1 par producteur)
- Reverse webhook : statut de livraison producteur → statut commande Shopify agrégé
n8n pour l’orchestration
Workflows n8n pour :
- Réception webhook commande Shopify
- Calcul du split par producteur (commission marketplace, prix HT producteur, TVA)
- Création des N commandes Odoo via Odoo API
- Trigger Stripe Connect pour le redirect paiement vers chaque producteur
- Notification producteur (email + tableau de bord)
- Suivi logistique unifié côté client (statut agrégé multi-producteurs)
Stripe Connect pour le split paiement
Stripe Connect en mode Express, chaque producteur a un compte Connect lié au compte plateforme Marius. Au paiement client, Stripe split automatiquement le montant selon le mapping producteur, la commission marketplace est prélevée, les producteurs reçoivent leurs fonds à J+2.
IA pour l’enrichissement produit
Workflows n8n + OpenAI/Claude pour :
- Catégorisation auto des produits soumis par les producteurs (mappés à la taxonomie marketplace)
- Détection des allergènes dans les descriptions
- Traduction FR → EN pour l’ouverture internationale
- Génération de descriptions enrichies à partir des données producteur brutes (avec validation humaine systématique)
Le résultat — phase technique validée
Phase 1 (terminée) :
- Architecture split paiement Stripe Connect : opérationnelle sur compte test
- Sync stock multi-producteurs : sub-5min via Oodify étendu
- Comptabilité Odoo split-producteur : écritures automatiques validées avec un expert-comptable
- Workflows IA matching produit : 92 % de précision sur un échantillon de 200 SKU
- Beta producteurs : 5 onboardés (test interne)
Phase 2 (en cours) :
- Recrutement de 15-20 producteurs supplémentaires en Occitanie
- Stress-test logistique sur des commandes multi-producteurs réelles
- Optimisation des coûts de routage transporteur
- UX checkout pour les commandes split (transparence client sur le délai par producteur)
Phase 3 (prévue 2026) :
- Ouverture beta publique
- Monitoring économique : commission, churn producteur, panier moyen, taux de répétition
Ce que ce projet rapporte à mes clients
Marius est en construction, donc je ne facture rien lié à Marius à mes clients Nareh. Ce que ça leur donne en revanche :
- Les patterns marketplace que je propose en mission ont été pré-validés sur Marius. Le client ne paie pas mon apprentissage.
- Les connecteurs et workflows développés pour Marius (split paiement, sync multi-producteurs, IA enrichissement) sont disponibles en mission, déjà éprouvés.
- Si vous êtes dans une marketplace food, B2B alimentaire, ou réseau de producteurs, je sais où sont les pièges parce que je les ai rencontrés sur Marius en premier.
« Marius est mon laboratoire. Les patterns qui tiennent en production là-bas finissent en livrables client. Les patterns qui cassent restent ici, et coûtent zéro à mes clients. » — Rémy Héran, fondateur Nareh
« Marius est mon laboratoire. Les patterns qui tiennent en production là-bas finissent en livrables client. Les patterns qui cassent restent ici, et coûtent zéro à mes clients. »