Marketplace à deux faces : que construire d’abord (et que simuler)
Un fondateur m’a présenté son idée autour d’un café au printemps dernier. “C’est le Airbnb des cuisines professionnelles”, a-t-il dit. Des restaurants avec une cuisine inoccupée d’un côté, des entrepreneurs de la restauration qui ont besoin d’une cuisine agréée de l’autre. Il avait l’offre déjà engagée, une maquette de designer et un devis d’une software house. Ce qu’il n’avait pas, c’était une réponse à la seule question qui comptait : le jour du lancement, avec zéro cuisine publiée et zéro cuisinier inscrit, que voit-on en ouvrant l’application ?
On lui avait vendu la construction. Personne ne lui avait parlé du problème que la construction ne résout pas.
Une marketplace à deux faces est une plateforme dont la valeur vient de la mise en relation de deux groupes distincts qui ont besoin l’un de l’autre, l’un qui offre quelque chose et l’autre qui le demande, où le travail du produit est précisément de faire le match et de prélever une part de la transaction. Airbnb relie hôtes et voyageurs. Uber relie chauffeurs et passagers. Etsy relie créateurs et acheteurs. Le fondateur ne construit ni l’offre ni la demande. Il construit la machine au milieu et touche une commission chaque fois qu’elle fonctionne.
Cette définition paraît simple, et elle masque les deux choses qui coulent la plupart des fondateurs de marketplace. La première : vous ne construisez pas un seul produit. La seconde : le logiciel est la partie facile.
Ce qu’est, vraiment, une marketplace à deux faces
“Le Uber des X” est un excellent pitch et un très mauvais cahier des charges. Il comprime trois produits distincts dans un mot familier et fait croire au fondateur qu’il construit une application. Il en construit trois.
Il y a le produit côté offre : comment le propriétaire d’une cuisine la publie, fixe ses disponibilités, son prix et se fait payer. Il y a le produit côté demande : comment le cuisinier cherche, compare, réserve et paie. Et il y a le moteur de matching au milieu : la logique qui décide quelles cuisines un cuisinier donné voit, dans quel ordre, filtrées par quoi, classées par quoi. Les deux faces ne partagent presque pas d’écran. L’expérience d’un hôte sur Airbnb et celle d’un voyageur sur Airbnb sont des logiciels presque entièrement différents qui vivent par hasard derrière le même logo.
C’est pourquoi une marketplace coûte plus cher à construire qu’un produit unique et pourquoi c’est la mauvaise forme pour un MVP au sens habituel. Vous ne pouvez pas lancer une demi-marketplace. Un parcours de réservation sans rien à réserver est une démo, pas un produit. Les deux faces doivent exister, au moins en squelette, avant que quiconque puisse se servir de la chose une seule fois.
Le seul problème qui tue vraiment les marketplaces
Voici la partie que sautent à la fois les manuels d’économie et les pages de vente des plateformes. Une marketplace vide ne vaut rien pour personne. Aucun cuisinier ne rejoint une application de location de cuisines sans cuisines. Aucun propriétaire de cuisine ne publie un espace sur une application sans cuisiniers. Chaque face attend l’autre, et le fondateur est planté au milieu avec un produit magnifiquement construit qui ne fait rien.
C’est le problème du cold start, et c’est la cause de mort de marketplace la plus fiable qui soit. Andrew Chen, qui a passé des années à piloter la croissance chez Uber, a écrit un livre entier là-dessus pour une raison : la plupart des marketplaces n’atteignent jamais le point où les deux faces se présentent d’elles-mêmes. La technologie n’a jamais été le goulot d’étranglement. La liquidité l’était, cette condition simple où un acheteur qui arrive trouve de façon fiable un vendeur, et réciproquement.
La règle qui en découle n’est pas intuitive pour qui vient de payer un produit à deux faces : ne lancez pas avec les deux faces. Choisissez la face la plus difficile, en général l’offre, et construisez-la d’abord, à la main s’il le faut, jusqu’à ce qu’il y ait assez de matière pour que l’autre face ait une raison de venir. Les fondateurs d’Airbnb ont photographié les annonces eux-mêmes. DoorDash a démarré comme une page statique avec quelques menus locaux et un numéro de téléphone qui sonnait chez les fondateurs. La marketplace est venue ensuite. Le travail manuel est venu avant.
Si une software house vous chiffre une marketplace sans jamais mentionner la liquidité ni le cold start, elle vous vend la moitié facile et vous laisse découvrir la moitié difficile tout seul.
Des exemples qui enseignent la vraie leçon
Oui, Etsy est une marketplace à deux faces (créateurs et acheteurs). Oui, Zillow en est une, quoique plus brouillonne, puisqu’elle relie acheteurs, vendeurs, agents et ses propres produits de données, ce qui la rapproche d’une plateforme à plusieurs faces. Les exemples utiles ne sont pourtant pas les logos célèbres. Ce sont les lancements.
La leçon de toute marketplace qui a marché, c’est qu’elle a trouvé le moyen d’être utile à une face avant que l’autre n’existe. Certaines avaient un “mode solo” : un outil qui aidait la face offre même avec une demande nulle. OpenTable a donné aux restaurants un logiciel de gestion des réservations qu’ils voulaient de toute façon, puis a transformé cette base installée en face offre d’une marketplace destinée à ceux qui dînent. Le logiciel s’est rentabilisé sur une face d’abord. Le réseau est arrivé en deuxième acte.
Pour un fondateur, la question qui en découle n’est pas “quel est mon Uber des X”. C’est “que puis-je donner à une face qui ait de la valeur même tant que l’autre face est vide”. Si vous ne savez pas y répondre, vous n’avez pas de plan de cold start, et une marketplace sans plan de cold start est une façon très coûteuse d’apprendre ce qu’est la liquidité.
Quel logiciel une marketplace nécessite vraiment
Ôtez le romantisme et une marketplace, ce sont quatre systèmes. Les nommer vous permet de cadrer une construction au lieu de pointer du doigt Uber.
Deux surfaces d’inscription et de publication, une par face. L’offre doit créer et gérer ce qu’elle propose ; la demande doit créer un compte et exprimer ce qu’elle veut. Pour l’essentiel, c’est standard. Beaucoup de marketplaces commencent ici en no-code.
Une couche de découverte et de matching. C’est la recherche, le filtrage, le classement et les règles qui décident qui voit qui. C’est aussi là que vit votre vrai produit. La différence entre une marketplace qui paraît magique et une qui paraît un tableur tient presque entièrement au matching, et c’est la seule partie propre à votre activité.
Une couche de confiance. Avis, vérification, gestion des litiges et tout ce dont votre catégorie a besoin pour qu’un inconnu soit à l’aise de transiger avec un autre inconnu. Dans une application de location de cuisines, cela peut être la vérification de licence et l’assurance. Dans une application de baby-sitting, c’est la vérification des antécédents. La confiance n’est pas une fonctionnalité qu’on ajoute après ; dans bien des catégories, elle est le produit.
Les paiements, et le plus souvent le séquestre. La marketplace encaisse l’argent d’une face, le retient et le reverse à l’autre après la transaction, en prélevant sa part. C’est plus complexe qu’un paiement classique parce que vous déplacez de l’argent entre deux utilisateurs, souvent avec un délai et une fenêtre de litige. Stripe et d’autres fournissent les briques pour cela, mais la politique, qui est payé quand, ce qui se passe en cas d’annulation, c’est à vous de la décider.
Remarquez le schéma : deux des quatre systèmes sont en grande partie génériques, et deux d’entre eux, le matching et la confiance, sont là où vit votre défendabilité. Cela a une conséquence directe sur la décision suivante.
Construire, louer une plateforme ou partir sur du custom
Vous avez trois options honnêtes, et la bonne dépend entièrement du degré de standardisation que requièrent votre matching et votre confiance.
Une plateforme de marketplace comme Sharetribe ou un outil similaire vous livre vite une marketplace à deux faces qui fonctionne, avec annonces, recherche et paiements prêts à l’emploi. C’est l’équivalent, dans le monde des marketplaces, de construire sur un produit white label : excellent pour valider que les deux faces vont réellement se présenter, et limité dès l’instant où votre logique de matching ou de confiance doit sortir du standard. Si votre marketplace est “Airbnb, mais pour une niche” avec recherche classique et avis classiques, une plateforme peut vous mener plus loin que les fondateurs ne l’imaginent.
Une construction en no-code ou low-code se situe au milieu et fonctionne pour la même raison que la plateforme, jusqu’à ce que le moteur de matching dont vous avez vraiment besoin se batte avec l’outil que vous avez choisi.
Une construction custom est le bon choix quand le matching ou la couche de confiance sont votre avantage, quand ce qui rend votre marketplace meilleure que le concurrent évident, c’est précisément la façon dont vous reliez les deux faces ou dont vous les amenez à se faire confiance. On ne part pas sur du custom pour économiser. On part sur du custom pour posséder la seule partie qu’on ne peut pas louer.
L’erreur coûteuse, c’est de partir sur du custom pour les 80 % génériques et de traiter la logique de matching comme un détail. Nous avons vu des fondateurs dépenser leur budget à reconstruire des formulaires d’inscription et des barres de recherche qu’une plateforme offre gratuitement, puis tomber à court d’argent avant d’avoir construit le matching qui devait être tout l’intérêt.
Quoi construire d’abord, et quoi simuler
Commencez par la face que vous allez devoir traîner jusqu’à l’existence, et construisez le minimum de logiciel qui vous permet de la servir à la main. Un fondateur qui valide une marketplace n’a pas besoin d’un moteur de matching automatique le premier jour. Il a besoin d’une première version qui prouve que les deux faces vont transiger, et le matching peut être un humain, souvent le fondateur lui-même, qui lit les deux listes et fait la mise en relation par e-mail.
C’est l’approche concierge, et pour les marketplaces ce n’est pas un raccourci, c’est la bonne première construction. Le matching manuel vous enseigne les règles de matching que vous automatiserez un jour, les règles qu’aucune software house ne peut deviner à votre place. Vous découvrez que les cuisiniers tiennent plus aux mètres carrés qu’à l’emplacement, ou l’inverse, en le faisant à la main cinquante fois. Ensuite vous construisez le moteur qui encode ce que vous avez appris, et vous le construisez en custom, parce qu’à ce stade vous savez que c’est la partie qui vaut la peine d’être possédée. (C’est la même logique de construire ou acheter qui s’applique à toute décision logicielle, proche de celle du micro SaaS, aiguisée par le fait qu’une marketplace a un noyau générique évident et un centre défendable étroit.)
Le fondateur des cuisines professionnelles est retourné voir sa software house et a changé l’ordre. Face offre d’abord, des annonces qu’il a saisies lui-même, un matching qu’il a assuré par WhatsApp les deux premiers mois. La construction custom est venue après, quand il avait déjà trente cuisines et une file d’attente de cuisiniers, quand il a enfin su ce que le moteur de matching devait vraiment faire. L’application avec laquelle il a terminé a coûté moins cher que celle qu’on lui avait chiffrée, et, contrairement à celle-là, elle avait quelque chose à mettre en relation.
Questions fréquentes
Qu’est-ce qu’une marketplace à deux faces ?
Une marketplace à deux faces est une plateforme dont la valeur vient de la mise en relation de deux groupes distincts qui ont besoin l’un de l’autre, l’un qui offre quelque chose et l’autre qui le demande, où le travail du produit est de faire le match et de prélever une part de la transaction. Airbnb relie hôtes et voyageurs, Uber relie chauffeurs et passagers, Etsy relie créateurs et acheteurs. Le fondateur ne construit aucune des faces ; il construit la machine de matching au milieu et touche une commission chaque fois qu’elle fonctionne.
Quel est un exemple de marketplace à deux faces ?
Airbnb (hôtes et voyageurs), Uber (chauffeurs et passagers), Etsy (vendeurs et acheteurs) et DoorDash (restaurants et convives) sont toutes des marketplaces à deux faces. L’instructif n’est pas le logo célèbre, c’est la façon dont chacune a lancé : toutes ont trouvé le moyen d’être utiles à une face avant que l’autre n’existe, en général en construisant l’offre à la main avant l’arrivée de la demande.
Etsy est-elle une marketplace à deux faces ?
Oui. Etsy relie deux groupes distincts, des créateurs indépendants côté offre et des acheteurs en quête de produits faits main ou vintage côté demande, et prélève une part de chaque vente. Comme la plupart des marketplaces, elle a résolu l’offre d’abord, en attirant des vendeurs et leur inventaire avant d’avoir une large base d’acheteurs à leur proposer.
Zillow est-elle une marketplace à deux faces ?
En quelque sorte, et c’est un cas limite utile. Zillow relie acheteurs, vendeurs et agents, et fait tourner ses propres produits de données par-dessus, ce qui la rapproche d’une plateforme à plusieurs faces plutôt que d’une marketplace à deux faces pure. Beaucoup de marketplaces réelles dérivent dans ce sens en grandissant ; le modèle à deux faces est le point de départ mental, pas toujours la forme finale.
Comment construire une marketplace à deux faces ?
Ne lancez pas avec les deux faces. Choisissez la face la plus difficile (en général l’offre), construisez-la d’abord (à la main s’il le faut) jusqu’à ce qu’il y ait assez de matière pour que l’autre face ait une raison de venir, puis seulement activez la demande. Commencez avec le minimum de logiciel qui vous permet de servir une face et de faire le match à la main, apprenez les règles de matching manuellement, puis construisez les couches de matching et de confiance en custom, car c’est là que vit votre défendabilité. Les surfaces de publication et les paiements sont en grande partie génériques ; le matching et la confiance non.
Qu’est-ce que la théorie des marchés à deux faces ?
C’est le concept économique selon lequel certaines plateformes créent de la valeur en servant deux groupes de clients interdépendants à la fois, où la valeur de chaque groupe croît avec la taille de l’autre (un effet de réseau), et où tarifer une face peut subventionner l’autre. C’est un bon arrière-plan, mais c’est le cadre de l’économiste ; le problème du fondateur est le problème pratique de faire venir l’une des faces en premier.