La stack marketplace
Pour une marketplace de services ou de produits : Frontend : WeWeb (web) + FlutterFlow (mobile, si nécessaire) Base de données : Supabase (PostgreSQL avec RLS) API : Xano (logique de réservation, disponibilité, recherche, notifications) Paiements : Stripe Connect (versements marketplace) Recherche : recherche full-text Supabase ou Algolia Automatisation : Make (emails de confirmation, notifications, workflows de litiges)
Pour une marketplace de produits, remplacez Xano par des APIs Supabase + Stripe directes si la logique est simple. Pour le marché français, vérifiez les obligations légales d'enregistrement auprès de la DGCCRF pour les marketplaces qui mettent en relation des particuliers, et les obligations de facturation électronique pour les transactions B2B.
La raison pour laquelle nous privilégions cette stack à une solution tout-en-un comme Sharetribe ou Comet est le contrôle. Avec WeWeb + Supabase + Xano, vous possédez entièrement le modèle de données. Vous pouvez construire n'importe quelle fonctionnalité qu'offre une plateforme marketplace financée par du capital-risque, structures de commission personnalisées, multi-devises, vérification vendeur à plusieurs niveaux, sans attendre qu'un éditeur la livre. Le compromis, c'est le temps de construction : comptez 3 à 4 semaines de plus que pour une solution basée sur des templates. Pour la plupart des activités marketplace sérieuses, ce compromis en vaut la peine.
Le schéma de base de données
Les tables principales pour une marketplace de services : CREATE TABLE listings ( id bigserial PRIMARY KEY, seller_id uuid REFERENCES auth.users(id), title text, description text, category text, price_cents integer, currency text DEFAULT 'eur', images jsonb, location text, is_active boolean DEFAULT true, created_at timestamptz DEFAULT now() );
CREATE TABLE bookings ( id bigserial PRIMARY KEY, listing_id bigint REFERENCES listings(id), buyer_id uuid, seller_id uuid, status text DEFAULT 'pending', amount_cents integer, stripe_payment_intent_id text, created_at timestamptz DEFAULT now() );
CREATE TABLE reviews ( id bigserial PRIMARY KEY, booking_id bigint REFERENCES bookings(id), reviewer_id uuid, rating integer, body text, created_at timestamptz DEFAULT now() );
Notez que currency est défini par défaut sur 'eur' pour les marketplaces françaises. Stockez les montants en centimes (price_cents) pour éviter les erreurs d'arrondi liées aux décimales, une bonne pratique indispensable pour les transactions en euros.
La Row Level Security n'est pas négociable sur aucune table. Les acheteurs ne doivent voir que leurs propres réservations. Les vendeurs ne doivent voir que leurs propres annonces et les réservations entrantes. Les admins reçoivent une clé service-role qui contourne RLS. Mettez en place ces politiques avant de construire le frontend, ajouter RLS après coup sur une application déjà fonctionnelle prend deux fois plus de temps et introduit des bugs.
Recherche et découverte
Pour la plupart des marketplaces, la recherche full-text de Supabase est suffisante au lancement. Dans Xano :
GET /api/listings/search Paramètres : query (texte), category, min_price, max_price, location Logique : utilisez to_tsvector() de Supabase pour la recherche full-text sur title + description, combiné avec des filtres de catégorie et de prix.
Pour des catalogues plus importants (10 000+ annonces) ou la recherche géographique (trouver des prestataires près de chez moi), ajoutez Algolia. Le plugin WeWeb Algolia rend cette connexion simple. Pour les marketplaces françaises avec une dimension géographique forte, intégrez également le référentiel géographique officiel de l'INSEE pour la normalisation des codes postaux et des noms de communes.
La qualité de la recherche est un moteur direct du GMV de la marketplace : les acheteurs qui trouvent ce qu'ils cherchent convertissent, ceux qui ne trouvent pas, partent. Investissez dans le réglage de la pertinence avant le lancement : ajoutez des listes de synonymes, boostez les annonces récentes, et faites remonter les vendeurs les mieux notés pour les requêtes ambiguës. L'extension pg_trgm intégrée à Supabase gère le matching approximatif pour les fautes de frappe, ce qui est particulièrement important pour les utilisateurs mobiles qui tapent souvent des termes de recherche avec des erreurs.
Stripe Connect pour les paiements marketplace
Les paiements marketplace utilisent Stripe Connect, les vendeurs ont des comptes Stripe, les acheteurs paient via votre plateforme, et Stripe gère le partage.
Flux : 1. Onboarding vendeur : redirection vers l'onboarding Stripe Connect Express. Stocker leur stripe_account_id dans votre base de données. 2. Paiement acheteur : créer un Stripe PaymentIntent avec application_fee_amount (votre commission). Le paiement va sur le compte Stripe du vendeur moins vos frais. 3. Versement : Stripe verse automatiquement sur le compte bancaire du vendeur selon un calendrier régulier.
Pour les marketplaces françaises, notez que Stripe Connect Express gère automatiquement la TVA et les obligations de déclaration fiscale pour les vendeurs professionnels. Vérifiez avec un expert-comptable les obligations spécifiques de la directive DAC7 (déclaration des revenus des vendeurs plateformes) qui s'applique aux marketplaces européennes depuis 2023.
Structure des frais de plateforme : la plupart des marketplaces prélèvent 10 à 20 % de la valeur de la transaction comme commission de plateforme. Stripe déduit ce montant automatiquement avant de reverser les fonds au vendeur. Vous recevez la commission sur votre solde Stripe. Pour les secteurs réglementés (services financiers, santé), consultez un avocat spécialisé en paiements avant de fixer votre structure de frais, certaines juridictions exigent une licence d'établissement de paiement si vous détenez des fonds pendant plus de 24 heures.
Dynamiques d'une marketplace two-sided
Chaque marketplace fait face au problème du cold-start : les vendeurs ne rejoignent pas sans acheteurs, et les acheteurs ne viennent pas sans vendeurs. La solution la plus fiable est d'amorcer un côté manuellement avant d'ouvrir l'autre. Chez App Studio, nous avons livré quatre marketplaces et le pattern qui fonctionne est supply-first : recrutez directement 20 à 30 vendeurs, offrez-leur un accès gratuit ou à frais réduits pendant les 3 premiers mois, et mettez les annonces en ligne avant tout marketing orienté acheteur.
Le seuil de liquidité, le point où la marketplace devient utilisable pour les acheteurs, varie selon la catégorie. Pour une marketplace de services locaux (femmes de ménage, professeurs particuliers, hommes toutes mains), vous avez besoin d'au moins 15 à 20 annonces actives dans chaque catégorie principale avant que l'expérience de recherche ne paraisse complète. Pour une marketplace de logiciels B2B, 30 à 40 outils SaaS avec des profils complets sont le minimum. En dessous de ce seuil, les acheteurs atterrissent sur des résultats de recherche pauvres et partent sans convertir, ce qui pollue vos premières données.
La rétention sur les deux côtés demande une attention séparée. Les vendeurs partent quand les réservations se tarissent, les acheteurs partent quand ils ne trouvent pas ce dont ils ont besoin. Suivez le GMV par vendeur et par semaine comme indicateur avancé : un vendeur qui passe 3 semaines ou plus sans réservation présente un risque de départ élevé et mérite un contact personnel de votre équipe. Des relances automatisées "boostez votre annonce" dans Make peuvent réengager les vendeurs dormants avant qu'ils n'annulent.
Architecture d'escrow de paiement et Stripe Connect
L'escrow complet, qui retient les fonds de l'acheteur jusqu'après la livraison du service, est un moteur de confiance majeur pour les transactions à forte valeur ou de première fois. Stripe Connect le supporte nativement via le paramètre capture_method: manual sur les PaymentIntents. La carte de l'acheteur est autorisée au moment de la réservation, et vous ne capturez les fonds qu'après que les deux parties confirment la réalisation. Cela vous donne 7 jours pour résoudre les litiges avant que l'argent ne bouge.
Le workflow Xano pour l'escrow : POST /api/bookings/{id}/complete déclenche une capture de PaymentIntent Stripe. POST /api/bookings/{id}/dispute passe la réservation à un statut de litige et suspend la capture. Votre tableau de bord admin gère ensuite la résolution manuellement. L'API de litiges de Stripe permet de rembourser l'acheteur ou de libérer les fonds vers le vendeur, construisez les deux endpoints dans Xano et affichez-les dans votre interface admin.
Pour les marketplaces avec des services récurrents (ménage mensuel, cours particuliers hebdomadaires), implémentez des Stripe Subscriptions avec un calendrier de transfert Connect plutôt que des PaymentIntents par réservation. L'abonnement facture l'acheteur mensuellement, une automatisation Make planifiée déclenche un endpoint Xano pour diviser et transférer la part du vendeur. Cela réduit le nombre d'appels API par transaction et rend votre trésorerie plus prévisible.
Fonctionnalités de confiance et de sécurité
Une marketplace sans infrastructure de confiance échouera même si le produit est techniquement excellent. Les fonctionnalités de confiance se répartissent en trois catégories : vérification d'identité, résolution de litiges et modération communautaire. Aucune n'est optionnelle une fois que vous atteignez un volume de transactions significatif, typiquement autour de 100 réservations par mois.
La vérification d'identité signifie au minimum un email et un numéro de téléphone vérifiés pour tous les utilisateurs. Pour les catégories à plus haute exigence de confiance (garde d'enfants, accès au domicile, services financiers), ajoutez une vérification de documents via un prestataire comme Stripe Identity ou Onfido. Ces services renvoient un statut de vérification que vous stockez sur la table users et affichez comme un badge "Vérifié" sur les profils vendeurs. Dans les données de nos clients, les acheteurs préfèrent systématiquement les vendeurs vérifiés, 2 à 3 fois plus souvent.
Pour la résolution de litiges, construisez un simple système de tickets connecté à votre table bookings. Chaque ticket de litige a un statut (open, under_review, resolved_buyer, resolved_seller), un fil de messages entre acheteur et vendeur, et un champ de dérogation admin. Routez les litiges au-dessus d'un montant seuil (disons 100 €) vers une file de revue humaine. En dessous de ce seuil, implémentez une politique de remboursement automatique, le coût opérationnel de la revue manuelle des petits litiges dépasse la perte liée aux remboursements automatiques. Cette politique devrait être clairement documentée dans les conditions de votre marketplace.
SEO pour marketplace
Le SEO d'une marketplace est avant tout un défi de contenu programmatique. Votre meilleur trafic organique vient des pages de catégorie ("professeurs de yoga à Berlin"), des pages d'annonce ("Cours de yoga privés avec Anna K.") et des pages de localisation ("services près de Prenzlauer Berg"). Chacune a besoin d'une URL unique et indexable, et d'assez de contenu unique pour passer le seuil de contenu utile de Google.
Pour les pages de catégorie et de localisation, générez-les de façon programmatique à partir de vos données Supabase. Un template de page WeWeb avec une route dynamique (/category/[slug]/[city]) récupère les données d'annonces en direct depuis Xano et les affiche en réponse HTML cacheable statiquement. Ajoutez le schema LocalBusiness sur les pages de localisation, le schema ItemList sur les pages de catégorie, et le schema Product sur les annonces individuelles. Ces types de schema permettent directement des rich snippets dans Google : notes en étoiles, fourchettes de prix et disponibilité dans le résultat de recherche.
Les pages d'annonce avec des avis se classent nettement mieux que celles sans avis. Intégrez une demande d'avis automatisée post-réservation dans votre workflow Make : 24 heures après qu'une réservation est marquée comme terminée, envoyez à l'acheteur un email avec un lien d'avis en un clic. Même un taux de complétion d'avis de 20 % s'accumule rapidement : une marketplace avec 500 réservations complétées par mois aura 1 200 nouveaux avis par an, qui viennent tous enrichir la profondeur de contenu des pages d'annonce individuelles.
Croissance après le lancement
Les 90 premiers jours après le lancement sont la période à plus fort effet de levier pour une marketplace. Votre objectif est d'atteindre la liquidité, le point où la marketplace fonctionne de manière fiable pour les acheteurs sans intervention manuelle de votre équipe. Trois leviers pilotent cela : la qualité de l'offre, l'acquisition d'acheteurs et l'usage répété.
La qualité de l'offre signifie curer le côté vendeur sans complaisance dans les premiers temps. Rejetez les annonces incomplètes. Contactez les vendeurs qui n'ont pas répondu à une réservation dans les 24 heures. Mettez en avant vos meilleurs vendeurs sur la page d'accueil. Les premiers acheteurs se forgent leur impression de votre marketplace à partir des 3 à 5 premiers résultats qu'ils voient, si ces résultats sont médiocres, ils ne reviendront pas.
L'acquisition d'acheteurs pour une marketplace démarre presque toujours par le SEO et la recherche payante, pas les réseaux sociaux. Le trafic à intention (des personnes qui cherchent exactement ce que vous offrez) convertit 5 à 10 fois mieux que le trafic social. Lancez des Google Ads sur vos termes de catégorie à plus forte intention dès le premier jour et suivez le coût par première réservation, pas le coût par inscription. L'usage répété est piloté par votre expérience post-réservation : email de confirmation, rappel avant le service, demande d'avis après le service, et un email de relance "Réservez à nouveau" 30 jours plus tard. Construisez toute cette séquence dans Make avant le lancement, c'est la différence entre une plateforme de transaction ponctuelle et une activité marketplace pérenne.
Onboarding et tableau de bord vendeur
Expérience vendeur : 1. Inscription → compléter l'onboarding Stripe Connect 2. Créer des annonces (titre, description, images, prix, disponibilité) 3. Gérer les réservations (accepter/refuser les demandes, voir le calendrier de réservations) 4. Suivre les revenus (total versé, versements en attente, historique des réservations) 5. Gérer les avis
Tout cela est construit dans WeWeb connecté aux endpoints API Xano. Le tableau de bord vendeur ajoute typiquement 2 à 3 semaines à la portée d'un MVP. Pour les vendeurs professionnels français, ajoutez une section de gestion des documents légaux (SIRET, attestation d'assurance, certificats de qualification), les marketplaces B2B françaises en ont généralement besoin pour la conformité.
Le tableau de bord vendeur est l'endroit où la rétention de la marketplace se gagne ou se perd. Les vendeurs qui peuvent clairement voir leurs revenus, réservations à venir et notes d'avis restent engagés. Les vendeurs qui contemplent un tableau de bord vide après une semaine creuse désactivent discrètement leurs annonces. Construisez la section des revenus en premier, c'est la métrique la plus importante émotionnellement pour les vendeurs et la plus facile à rendre visuellement convaincante. Un simple graphique en barres des revenus hebdomadaires dans WeWeb, utilisant un composant de graphique connecté à un endpoint d'agrégation Xano, prend une demi-journée à construire et rapporte en rétention vendeur.
Checklist de lancement
Avant de lancer une marketplace : ☑ Politiques RLS sur toutes les tables (les acheteurs ne peuvent pas voir les données privées des autres acheteurs, les vendeurs ne peuvent pas voir le stripe_account_id des uns des autres) ☑ Gestionnaire de webhooks Stripe pour les événements de paiement (confirmation, litiges, remboursements) ☑ Notifications par email pour tous les changements d'état de réservation (automatisation Make) ☑ Tableau de bord admin pour la résolution des litiges ☑ CGU et politiques de la marketplace (conformes au droit français de la consommation) ☑ Politique de confidentialité conforme au RGPD et consentement cookies ☑ Test de charge avec 100 utilisateurs simultanés avant le lancement
Une erreur courante : lancer sans le tableau de bord admin. Dans la première semaine d'une marketplace live, vous aurez besoin de résoudre manuellement un litige de réservation. Construisez les outils admin avant de mettre en ligne.
Par ailleurs : testez le cycle complet acheteur-vers-versement avec une vraie transaction avant le lancement, débitez une vraie carte, complétez la réservation, déclenchez un versement vers un compte Stripe Connect de test, et vérifiez que les fonds arrivent. Le mode sandbox de Stripe est excellent mais il ne peut pas détecter tous les cas limites de votre logique Xano. Une transaction test de 1 € a détecté un bug de timing de webhook sur l'un de nos lancements de marketplace qui aurait causé un double débit à grande échelle. Ce test de 10 minutes a évité un incident catastrophique en production.