Nehos Groupe

Marketplace multivendeur sur mesure — Next.js + Medusa.js + Payload

Onboarding vendeurs self-service, aucune licence SaaS récurrente. Stack headless open source, split paiements Stripe Connect, calcul TVA OSS automatique.

Nos clients types

Scale-up
PME
ETI
Grand Groupe

L'essentiel sur le développement d'une marketplace multivendeur sur mesure

Créer une marketplace multivendeur sur mesure devient accessible aux PME et ETI avec les stacks open source actuelles. Medusa.js 2 (headless commerce) + Next.js 15 (frontend) + Payload CMS (backoffice vendeurs) évite une licence SaaS récurrente de type Mirakl, avec un MVP opérationnel rapidement. Budget : à partir de 50 000 € HT pour une plateforme B2B complexe de ce type, chiffré sur devis après audit.

Le nerf de la guerre sur une marketplace : l'onboarding vendeurs non-techniciens, le split paiements automatique conforme, et la gestion TVA intracommunautaire (régimes OSS, micro-TVA, artisans mixtes). Ces trois points sont résolus en natif dans la stack Nehos : Stripe Connect Express pour les paiements, calcul OSS automatique, import catalogue CSV pour les vendeurs sans compétence technique.

Ce qu'on mesure : le nombre de vendeurs actifs rapporté au nombre de vendeurs cibles, la part d'onboarding réalisée en self-service, le TTFB du catalogue (Algolia + ISR Next.js) en production. Frais de licence SaaS récurrents : aucun avec cette stack open source.

Modèles économiques configurables sans dev supplémentaire : commission pourcentage, abonnement mensuel vendeur, freemium avec upgrade. Chaque paramètre est modifiable par l'admin sans intervention technique.

Problématique

Les entreprises qui veulent créer une marketplace multivendeur se heurtent systématiquement aux mêmes obstacles. D'un côté, les solutions SaaS enterprise comme Mirakl ou CS-Cart : Mirakl Enterprise facture une licence récurrente, hors intégrations et développements spécifiques — un coût difficile à justifier pour une PME ou une ETI. CS-Cart Marketplace est plus accessible en prix mais impose une architecture monolithique PHP qui atteint ses limites quand le nombre de vendeurs et de références grandit. De l'autre côté, les solutions open source historiques (Sharetribe, Sylius Market) présentent un autre problème : architecture legacy, scalabilité limitée quand les vendeurs actifs se multiplient, et surtout absence de gestion native des règles métier complexes — TVA intracommunautaire, régimes fiscaux mixtes, split paiements automatisés conformes PSD2. Trois points de friction expliquent souvent les projets marketplace avortés ou abandonnés en cours de route. Premier point : la gestion multi-devise et TVA intracommunautaire. Les règles OSS (One Stop Shop) UE 2021 imposent un calcul de TVA basé sur le pays de livraison de l'acheteur, pas du vendeur. Sur une marketplace avec de nombreux vendeurs dans plusieurs pays, cela représente des dizaines de taux de TVA différents à gérer en temps réel, des rapports trimestriels OSS à produire, et une conformité NF203 pour la facturation. Peu de SaaS du marché gèrent cela nativement pour des règles aussi granulaires que les artisans en micro-TVA côtoyant des TPE au régime réel. Deuxième point : l'onboarding vendeurs. Un vendeur artisan ou TPE non-technicien ne peut pas gérer un back-office aussi complexe que celui de Mirakl ou d'un Prestashop multishop. Le KYC manuel — vérification d'identité, IBAN, Kbis — prend du temps par vendeur sur les solutions standard, ce qui rend difficile l'onboarding de centaines de vendeurs en quelques semaines. Sans automatisation KYC et import catalogue CSV, les coûts opérationnels d'onboarding explosent. Troisième point : la performance technique. Une marketplace construite sur Magento ou WooCommerce avec le plugin WCFM ou Dokan voit son TTFB se dégrader quand les vendeurs et les produits se multiplient. Une recherche produit lente fait chuter le taux de conversion. Les temps de réponse de ces architectures monolithiques sont incompatibles avec les exigences Core Web Vitals actuelles (LCP < 2.5s, INP < 200ms).

Notre solution

La stack retenue par Nehos pour les projets marketplace multivendeur sur mesure repose sur trois composants open source headless : Next.js 15 en frontend, Medusa.js 2 comme backend headless commerce, et Payload CMS pour le backoffice vendeurs. Cette architecture sépare clairement les responsabilités et évite les couplages qui tuent la performance et la maintenabilité sur le long terme. Medusa.js 2 est le coeur du dispositif. C'est un headless commerce Node.js conçu dès la version 2 pour les cas d'usage marketplace : gestion multi-vendeurs native, APIs REST et GraphQL, système de modules remplaçables (paiements, catalogue, commandes, expédition). Contrairement à WooCommerce ou Prestashop, Medusa.js ne génère pas de pages côté serveur — il expose uniquement des APIs que Next.js 15 consomme. Résultat : aucun couplage entre la couche UI et la logique métier, chaque partie est scalable indépendamment. L'onboarding vendeurs est géré par Payload CMS, configuré en backoffice dédié par type de profil vendeur. Les vendeurs non-techniciens accèdent à une interface simplifiée : saisie catalogue produits, upload photos, gestion commandes reçues, suivi virement. Le KYC est automatisé via Stripe Connect ou Mangopay selon le volume de transactions attendu. Stripe Connect Express gère la vérification d'identité (pièce d'identité + IBAN), le scoring réglementaire et la conformité PSD2 sans intervention manuelle côté plateforme. Pour les vendeurs volumineux, Mangopay offre des contrôles KYC avancés et des fonctionnalités wallet dédiées. L'import catalogue CSV / Excel permet à un vendeur de mettre ses références en ligne sans formation préalable. Le split paiements est géré nativement par Stripe Connect Express. Lorsqu'un acheteur passe une commande impliquant plusieurs vendeurs, Stripe calcule automatiquement la commission plateforme (paramétrable par admin : % fixe, % variable selon catégorie, abonnement mensuel, freemium), prélève sa part, et déclenche le virement vendeur à J+2 ou J+7 selon le paramétrage. Zéro trésorerie avancée côté plateforme, zéro risque de double paiement, conformité PSD2 native. La gestion TVA OSS est implémentée côté Medusa.js avec un module de calcul dynamique : au moment du checkout, le système identifie le pays de livraison de l'acheteur, applique le taux de TVA correspondant (base de données taux UE maintenue en temps réel), génère la facture conforme NF203, et alimente automatiquement les rapports trimestriels OSS. Les régimes fiscaux vendeurs (micro-TVA, réel simplifié, franchise en base) sont configurables par vendeur dans Payload CMS. La performance est adressée par trois leviers combinés. Premièrement, Next.js 15 avec SSG (Static Site Generation) pour les pages catalogue et ISR (Incremental Static Regeneration) pour les pages produit — les pages les plus consultées sont servies depuis le CDN OVHcloud sans aucun calcul serveur. Deuxièmement, Redis cache côté Medusa.js pour les requêtes catalogue fréquentes (catégories, filtres, prix). Troisièmement, Algolia InstantSearch intégré pour la recherche produit : latence de recherche très faible quel que soit le volume de références, faceting natif (prix, localisation vendeur, notation), personnalisation par profil acheteur. Le système de notifications est géré via Brevo (ex-Sendinblue) : emails transactionnels vendeur (nouvelle commande reçue, litige ouvert, virement effectué) et emails acheteur (confirmation commande, tracking livraison, SAV). Les templates sont éditables par l'admin sans intervention technique. Les modèles économiques supportés sont configurables par admin sans nouveau développement : commission pourcentage fixe ou variable par catégorie, abonnement mensuel vendeur (mensuel, annuel), modèle freemium avec fonctionnalités premium en upgrade.

Medusa.js 2

backend headless commerce open source conçu pour la marketplace, sans licence SaaS récurrente

Stripe Connect

KYC automatisé des vendeurs et split des paiements sans trésorerie avancée

TVA OSS

calcul au pays de livraison de l'acheteur, facture NF203, rapport trimestriel

Import CSV

les vendeurs mettent leur catalogue en ligne avec un modèle Excel préformaté, sans formation

Cas concret

Le nombre de vendeurs actifs par rapport aux vendeurs cibles, la part d'onboarding en self-service, les incidents de split des paiements ou de conformité TVA, le TTFB du catalogue en production. On mesure ces points après le lancement, sans résultat promis à l'avance.

#Le problème : pourquoi marketplace multivendeur sur mesure est un enjeu critique

Les entreprises qui veulent créer une marketplace multivendeur se heurtent systématiquement aux mêmes obstacles. D'un côté, les solutions SaaS enterprise comme Mirakl ou CS-Cart : Mirakl Enterprise facture une licence récurrente, hors intégrations et développements spécifiques — un coût difficile à justifier pour une PME ou une ETI.

CS-Cart Marketplace est plus accessible en prix mais impose une architecture monolithique PHP qui atteint ses limites quand le nombre de vendeurs et de références grandit. De l'autre côté, les solutions open source historiques (Sharetribe, Sylius Market) présentent un autre problème : architecture legacy, scalabilité limitée quand les vendeurs actifs se multiplient, et surtout absence de gestion native des règles métier complexes — TVA intracommunautaire, régimes fiscaux mixtes, split paiements automatisés conformes PSD2.

Trois points de friction expliquent souvent les projets marketplace avortés ou abandonnés en cours de route. Premier point : la gestion multi-devise et TVA intracommunautaire. Les règles OSS (One Stop Shop) UE 2021 imposent un calcul de TVA basé sur le pays de livraison de l'acheteur, pas du vendeur.

Sur une marketplace avec de nombreux vendeurs dans plusieurs pays, cela représente des dizaines de taux de TVA différents à gérer en temps réel, des rapports trimestriels OSS à produire, et une conformité NF203 pour la facturation. Peu de SaaS du marché gèrent cela nativement pour des règles aussi granulaires que les artisans en micro-TVA côtoyant des TPE au régime réel.

Deuxième point : l'onboarding vendeurs. Un vendeur artisan ou TPE non-technicien ne peut pas gérer un back-office aussi complexe que celui de Mirakl ou d'un Prestashop multishop. Le KYC manuel — vérification d'identité, IBAN, Kbis — prend du temps par vendeur sur les solutions standard, ce qui rend difficile l'onboarding de centaines de vendeurs en quelques semaines. Sans automatisation KYC et import catalogue CSV, les coûts opérationnels d'onboarding explosent.

Troisième point : la performance technique. Une marketplace construite sur Magento ou WooCommerce avec le plugin WCFM ou Dokan voit son TTFB se dégrader quand les vendeurs et les produits se multiplient. Une recherche produit lente fait chuter le taux de conversion. Les temps de réponse de ces architectures monolithiques sont incompatibles avec les exigences Core Web Vitals actuelles (LCP < 2.5s, INP < 200ms).

#Notre approche en 4 phases

#Phase 1 : Audit fonctionnel et choix de stack (S1)

Cartographier les règles métier : modèle de commission, flux KYC vendeurs, règles TVA (OSS, micro-TVA, régimes mixtes), intégrations logistiques. Choisir Medusa.js 2 vs alternatives selon volume et budget.

Voir notre expertise : Medusa.js marketplace headless.

#Phase 2 : Setup infrastructure et onboarding vendeurs (S2-S3)

Déployer Next.js 15 + Medusa.js 2 chez un hébergeur français (par exemple OVHcloud), configurer Stripe Connect Express pour split paiements automatiques, implémenter tableau de bord vendeur Payload CMS avec import catalogue CSV.

Voir notre expertise : PIM Akeneo vendeurs.

#Phase 3 : Catalogue, recherche et TVA (S3-S4)

Intégrer Algolia InstantSearch pour une recherche produit rapide, configurer calcul TVA OSS automatique, déployer Redis cache catalogue, CDN images OVHcloud.

Voir notre expertise : conformité NF203 marketplace.

#Phase 4 : Tests, notifications et go-live (S5-S6)

Tests de charge avec de nombreux vendeurs simultanés, configuration emails transactionnels Brevo (commande, tracking, litige), go-live avec monitoring temps réel, onboarding premiers vendeurs pilotes.

Voir notre expertise : Payload CMS backoffice.

#Repères

RepèreCe que c'est
Medusa.js 2backend headless commerce open source conçu pour la marketplace, sans licence SaaS récurrente
Stripe ConnectKYC automatisé des vendeurs et split des paiements sans trésorerie avancée
TVA OSScalcul au pays de livraison de l'acheteur, facture NF203, rapport trimestriel
Import CSVles vendeurs mettent leur catalogue en ligne avec un modèle Excel préformaté, sans formation

#Exemple de situation

#Contexte

Une fédération professionnelle de l'artisanat alimentaire qui veut créer une marketplace B2B entre artisans-producteurs et restaurateurs. Les vendeurs potentiels sont des membres non-techniciens (boulangerie, charcuterie, fromagerie, conserverie), et il n'y a aucun budget pour une licence SaaS récurrente.

#Défi

Onboarder des centaines de vendeurs non-techniciens sans équipe technique côté fédération, gérer la coexistence de régimes de TVA différents (franchise en base, micro-TVA, réel simplifié) sur la même plateforme, et assurer un split des paiements sans portage de trésorerie.

#Approche

Medusa.js 2 pour le backend marketplace, Next.js 15 pour le frontend acheteur, Payload CMS pour les backoffices vendeurs simplifiés. Stripe Connect Express pour le KYC automatisé et le split des paiements. Import catalogue CSV avec un modèle standardisé. Calcul TVA OSS par régime fiscal du vendeur. Hébergement chez un hébergeur français. Notifications email vendeurs et acheteurs via Brevo.

#Ce qu'on mesure

Le nombre de vendeurs actifs par rapport aux vendeurs cibles, la part d'onboarding en self-service, les incidents de split des paiements ou de conformité TVA, le TTFB du catalogue en production. On mesure ces points après le lancement, sans résultat promis à l'avance.

#Pourquoi Nehos pour marketplace multivendeur sur mesure

Nehos Groupe n'est pas un intégrateur généraliste qui adapte une solution standard à votre contexte. On conçoit des architectures sur mesure, calibrées sur vos contraintes métier, réglementaires et techniques. Chaque projet démarre par un audit de faisabilité qui pose les limites avant les promesses — si le ROI ne tient pas, on le dit avant de signer quoi que ce soit.

Notre méthode ROI-First impose un cadrage chiffré dès la phase d'audit : coût actuel documenté, gains projetés avec hypothèses conservatrices, critères de go/no-go factuels. En production, on mesure les résultats réels et on les compare aux projections — transparence totale, y compris quand les chiffres sont en dessous des attentes.

Nos expertises connexes : conformité NF203 marketplace, Payload CMS backoffice, agent IA SAV marketplace.

Côté hébergement, nous pouvons déployer chez un hébergeur français (par exemple OVHcloud, datacenters en France) et recourir à des modèles open source (Mistral) quand la performance le permet. Le choix se fait avec vous, selon vos contraintes de souveraineté.

#Pour aller plus loin

Cas d'usage connexes :

Questions & réponses

Questions fréquentes sur le développement d'une marketplace multivendeur sur mesure

Mirakl est une solution SaaS enterprise avec une équipe dédiée, un SLA contractuel, et une roadmap produit imposée. Elle s'accompagne d'une licence récurrente. En contrepartie, vous avez un produit mature, une couverture fonctionnelle large et un support 24/7. Medusa.js est open source, zéro licence, mais vous portez la responsabilité du dev, des mises à jour et de l'hébergement. Sharetribe est entre les deux — SaaS abordable mais architecture monolithique qui montre ses limites avec beaucoup de vendeurs ou des règles métier spécifiques. Pour une PME ou ETI avec un budget projet adapté et des règles métier spécifiques (TVA complexe, modèles commission non standard, intégration ERP), la stack Medusa.js sur mesure est plus pertinente. Pour un grand groupe qui veut déléguer la maintenance produit, Mirakl se justifie.

Un MVP complet sans intégration ERP ou SI tiers couvre : onboarding vendeurs self-service, catalogue live, paiements split Stripe Connect, calcul TVA, emails transactionnels. Une intégration ERP (Sage, SAP, Odoo) ou un connecteur logisticien tiers (Colissimo, DHL API, entrepôt 3PL) allonge le calendrier, confirmé à l'audit. Les points qui rallongent le délai : règles TVA hors standard (régimes fiscaux exotiques), paiements différés avec escrow (nécessite agrément PSP), ou catalogue complexe avec configurateur produit.

Le module TVA de Medusa.js est configuré pour appliquer le régime OSS UE 2021 : taux de TVA calculé sur le pays de livraison de l'acheteur, pas du vendeur. La base de données des taux de TVA par pays UE est maintenue en temps réel. Côté vendeurs, chaque profil vendeur dans Payload CMS porte son régime fiscal (franchise en base, micro-TVA, réel simplifié, réel normal). La facture générée à chaque commande intègre ces paramètres et est conforme NF203. En fin de trimestre, le module génère automatiquement le rapport OSS consolidé. Pour les cas hors standard (vendeurs non-UE, produits soumis à accises, régimes agricoles spéciaux), un paramétrage spécifique est nécessaire — à qualifier en phase d'audit.

L'onboarding est entièrement self-service. Le vendeur s'inscrit via un formulaire en ligne, Stripe Connect prend en charge le KYC automatiquement (photo pièce d'identité + IBAN + validation PSD2) sans intervention manuelle côté plateforme — la validation est rapide. Une fois validé, le vendeur accède à un backoffice Payload CMS simplifié avec seulement les fonctions utiles à son profil. Pour importer son catalogue, il télécharge un template Excel préformaté, le complète (nom produit, description, prix HT, stock, photos), et l'upload — les références sont disponibles sur la marketplace. Aucune compétence technique requise.

Oui, sous réserve d'un dimensionnement infrastructure adapté. Medusa.js 2 est conçu pour la scalabilité horizontale : chaque microservice (catalogue, commandes, paiements, notifications) scale indépendamment. Chez un hébergeur comme OVHcloud, le passage à l'échelle nécessite principalement de dimensionner le cluster Redis, d'augmenter les workers Medusa.js (scale horizontal), et de vérifier la capacité Algolia (selon le plan choisi). Un catalogue de plusieurs dizaines de milliers de produits actifs se gère bien avec ISR Next.js : seules les pages modifiées depuis la dernière indexation sont reconstruites, pas la totalité du catalogue. Pour de très gros volumes de vendeurs actifs, une architecture multi-tenant dédiée par région géographique peut être recommandée.

Une marketplace qui collecte des données bancaires et gère des paiements est soumise à plusieurs réglementations cumulatives. RGPD : données personnelles vendeurs (identité, IBAN, CA) avec durée de conservation réglementée (données comptables, données KYC après fin de relation). PSD2 : obligation de passer par un PSP agréé (Stripe, Mangopay) pour tout split paiement — la marketplace ne doit jamais détenir des fonds propres entre le paiement acheteur et le virement vendeur au-delà d'un délai contractuel. DSP2 / SCA : authentification forte obligatoire sur les transactions au-delà d'un seuil réglementaire. La stack Nehos délègue la conformité PSD2 et SCA à Stripe Connect ou Mangopay, ce qui couvre ces obligations nativement. Pour les marketplaces traitant des données de santé ou des produits réglementés, des obligations sectorielles supplémentaires s'appliquent — à qualifier en phase d'audit.

Prendre rendez-vous