Marketplace mobile à deux faces : quel MVP financer ?

Réponse courte

Un MVP de marketplace mobile à deux faces doit rendre possible une transaction réelle entre offreur et demandeur, avec des parcours distincts, une recherche utile, des règles de paiement et un minimum de support. Le brief situe cette première version autour de 24 000 à 40 000 € HT. Avec un budget plus serré, mieux vaut une V0 monoface : un seul côté utilise l'app, l'autre est opéré manuellement. Elle peut tester l'usage dans une enveloppe indicative de 10 000 à 15 000 € HT, à condition d'annoncer clairement ce qu'elle ne mesure pas. La première question n'est pas « quelles fonctions copier ? », mais « quelle transaction devons-nous prouver ? »

Deux publics, deux problèmes à résoudre

Une marketplace relie des personnes qui cherchent quelque chose à celles qui le proposent. Chaque côté a ses attentes. Un prestataire veut recevoir des demandes crédibles et savoir quand il sera payé. Un acheteur veut trouver une offre pertinente, comprendre le prix et savoir qui répond en cas de problème. Dessiner deux formulaires d'inscription ne règle pas cette coordination.

Le produit doit être assez utile avant qu'un marché complet existe. Si l'app s'ouvre sur un catalogue vide, les premiers demandeurs repartent. Si les offreurs ne reçoivent jamais de demande, ils cessent de mettre leurs fiches à jour. Un fondateur peut combler temporairement ce manque en recrutant, qualifiant et rapprochant les deux côtés à la main. Le cahier des charges mobile doit décrire cette opération manuelle, pas la cacher.

Je cadrerais donc le lancement sur un lieu, une catégorie et un type de transaction. C'est une décision commerciale autant que technique. Une app nationale avec dix catégories paraît ambitieuse, mais elle disperse l'offre et rend l'apprentissage plus lent. Le cadrage d'un MVP mobile sert à choisir le parcours à prouver avant de chiffrer les écrans.

Ce qu'une V1 à deux faces doit vraiment contenir

Le minimum dépend du marché, mais les deux publics ont besoin d'une identité, d'une fiche ou demande, d'un moyen de se trouver et d'un état clair après contact. Si le paiement fait partie de la promesse, il faut définir qui paie qui, quand, et qui traite un remboursement. Une interface d'administration attachée à l'app peut aider le fondateur à valider des profils, suivre des demandes et résoudre les premiers incidents.

Élément	Question de cadrage
Offre	Qui publie, qui vérifie et quand une fiche expire ?
Demande	Comment l'acheteur trouve une réponse utile sans catalogue massif ?
Mise en relation	Message, demande ou réservation : quel événement compte ?
Paiement	Qui encaisse, qui reçoit et quand un remboursement survient ?
Opérations	Quel litige peut être traité manuellement au départ ?

Une notation publique, un chat instantané et une géolocalisation en direct ne sont pas automatiquement nécessaires. Ils ajoutent aussi modération, notifications et cas limites. Le premier périmètre doit contenir assez de service pour réaliser une transaction, puis mesurer ce qui bloque. Notre guide des prix d'application mobile aide à replacer ces postes dans le budget global.

La V0 monoface : faire une moitié à la main

Dans une V0 orientée offre, les prestataires utilisent l'application pour gérer leur fiche et recevoir des demandes. Le fondateur peut collecter la demande par un canal déjà existant et la répartir manuellement. Inyka ne livre pas de site web autonome pour cela ; le projet mobile doit rester le produit principal. Cette version teste si les prestataires répondent, tiennent leurs informations à jour et acceptent les demandes reçues.

Dans une V0 orientée demande, les acheteurs parcourent une sélection et expriment leur besoin dans l'app. Le fondateur recrute les offreurs et tient le catalogue à jour manuellement. C'est souvent le meilleur choix quand la difficulté est de créer une expérience de recherche crédible. Mais si personne ne paie dans cette version, elle teste l'intérêt et la prise de contact, pas encore la monétisation.

Le travail manuel n'est pas un échec du produit. Il révèle les exceptions que l'automatisation aurait masquées : offre indisponible, devis à préciser, demande trop vague, annulation. Note le temps consacré à chaque transaction. Si le modèle ne tient pas avec une petite base et une opération attentive, ajouter du code risque seulement d'accélérer un mauvais processus.

Le paiement doit suivre le modèle réel

Une inscription, un clic ou un message montrent de l'intérêt. Un paiement donne un signal plus fort sur la volonté de payer, mais il ajoute des obligations opérationnelles. Selon le modèle, il faut gérer l'identité des vendeurs, les remboursements, les commissions et les fonds en transit. Ne baptise pas tout cela « escrow » sans vérifier le service effectivement fourni par le prestataire de paiement.

En France, l'ACPR décrit l'encaissement de fonds pour compte de tiers comme une activité encadrée. Un montage marketplace se cadre avec un prestataire de paiement adapté et un conseil compétent si les flux l'exigent. Inyka peut intégrer un outil tel que Stripe Connect, mais ne devient pas un prestataire de services de paiement. Le calendrier dépend alors de l'onboarding et des vérifications demandées par ce partenaire.

Si la V0 ne prend pas de paiement, écris explicitement que le test ne valide pas la disposition à payer. Tu peux chercher ce signal par une vente opérée hors app, sous réserve de choisir un parcours conforme au produit et aux règles des stores. Le devis technique doit refléter le modèle retenu, pas un bouton « payer » posé sur une maquette.

Les fonctions que je repousserais

Le chat en temps réel est séduisant, mais un échange asynchrone peut suffire pour les premiers services. La géolocalisation permanente des prestataires suppose des permissions, une consommation de batterie et un suivi que le modèle ne justifie peut-être pas. Les scores de réputation sont fragiles quand il y a peu de transactions : quelques avis peuvent déformer tout le classement.

Je repousserais aussi les commissions complexes et le traitement automatisé des litiges. Au départ, une règle écrite et un traitement manuel documenté donnent souvent de meilleures informations. En revanche, il faut prévoir la suppression des comptes et les moyens de contact nécessaires à la publication ; Apple demande que les apps avec création de compte proposent l'initiation de sa suppression dans l'app.

Le brief place une V0 monoface autour de 10 000 à 15 000 € HT et une V1 à deux faces autour de 24 000 à 40 000 € HT. Ce sont des ordres de grandeur de cadrage, pas des prix universels. Chez Inyka, une marketplace à deux faces relève au minimum d'un périmètre Scale, affiché à partir de 24 000 € HT. Notre offre React Native précise le type d'application que nous développons.

Les pièges qui vident une marketplace avant le lancement

Ouvrir trop de catégories. Un catalogue dispersé donne l'impression d'une offre importante, mais chaque recherche précise revient vide. Concentre le lancement sur une catégorie et un territoire où l'équipe peut réellement vérifier la disponibilité.

Compter les inscrits au lieu des transactions. Deux listes d'attente peuvent grossir sans qu'une seule demande trouve une réponse. Suis les demandes qualifiées, les réponses reçues et les transactions terminées.

Laisser les offreurs publier sans règle de qualité. Des prix incomplets, des photos absentes ou des disponibilités fausses déplacent le travail vers le support. Définis le minimum d'une fiche et contrôle les premières publications à la main.

Ajouter un chat pour réparer un parcours flou. Si l'acheteur doit poser les mêmes questions à chaque offreur, la fiche ou le formulaire de demande manque d'informations. Corrige ce point avant de financer une conversation en temps réel.

Découvrir les remboursements après le premier litige. Un paiement réussi n'est pas une transaction terminée. Écris les règles d'annulation, le responsable de la décision et la marche à suivre avec le prestataire de paiement.

Ce qu'Inyka refuse sur ce périmètre

• Une V1 présentée comme une marketplace complète si un côté est encore géré manuellement. La V0 monoface est valable, mais son périmètre doit être nommé honnêtement.
• Un « escrow » promis sans vérifier que le prestataire de paiement fournit réellement la fonction et que le montage correspond au flux commercial.
• Un système bancaire, d'assurance ou de détention directe des fonds. Inyka développe une application mobile et intègre un prestataire adapté, sans offrir de service financier agréé.
• Deux apps et un back-office sur mesure dès le départ lorsque la première transaction peut être opérée avec une seule app et un outil d'administration limité attaché à elle.

Scénario : une V0 qui mesure quelque chose

Imagine une marketplace de prestations locales avec des offreurs difficiles à recruter. Le fondateur choisit une seule zone et obtient un premier catalogue vérifié avant de publier l'app demandeur. La V0 permet de rechercher, envoyer une demande et recevoir un état de suivi. Le fondateur contacte les offreurs par ses canaux existants, choisit celui qui répond et enregistre le résultat. Le brief situe ce périmètre monoface autour de 10 000 à 15 000 € HT, sous réserve de cadrage.

Pendant cette phase, trois mesures comptent davantage que les installations : part de demandes auxquelles un offreur répond, temps nécessaire pour trouver une offre pertinente et part des mises en relation qui aboutissent. Une demande sans réponse apprend quelque chose sur le recrutement des offreurs, pas forcément sur l'interface. Si l'équipe doit passer beaucoup de temps à préciser chaque besoin, le formulaire est peut-être trop vague.

Après plusieurs cycles, le fondateur peut chiffrer l'automatisation du côté offre. Il sait quelles données demander, quels statuts afficher et quelles exceptions restent humaines. La V1 à deux faces du brief, autour de 24 000 à 40 000 € HT, devient alors un investissement sur un processus observé. Si la V0 n'a pas traité de paiements, le devis V1 doit conserver un poste distinct pour le flux de facturation et les tests de remboursement. Ajouter un bouton ne suffit pas à valider ce modèle.

FAQ

Une marketplace peut-elle démarrer sans paiement intégré ? Oui, si le but du premier test est de vérifier la mise en relation. Elle ne prouve alors pas encore que les utilisateurs paieront au prix envisagé.

Faut-il deux applications distinctes ? Non. Une seule app peut servir les deux rôles avec des parcours différents. Deux apps augmentent le travail de publication, de support et de maintenance.

Peut-on tester l'idée avec un outil no-code ? Le fondateur peut choisir ses propres outils pour explorer une idée. Inyka développe la version mobile en React Native et Expo, et ne livre pas de produit no-code.

Qui règle les litiges au lancement ? Définis une personne responsable, une règle visible et un suivi des cas. Une interface automatisée n'enlève pas la décision commerciale derrière un remboursement.

Quand automatiser le second côté ? Quand les transactions répétées montrent quelles opérations manuelles se ressemblent et combien de temps elles prennent. Automatiser plus tôt fige des hypothèses encore fragiles.

Faut-il vérifier chaque offreur avant publication ? Le niveau de contrôle dépend du service vendu et des risques pour les utilisateurs. Au lancement, une validation manuelle de l'identité commerciale et de la fiche peut limiter les offres incomplètes.

Comment mesurer la qualité de la recherche avec peu d'offres ? Suis les recherches sans résultat et les demandes abandonnées. Ces signaux aident à décider où recruter de nouveaux offreurs avant d'ajouter des filtres.

Une note publique est-elle nécessaire au départ ? Pas toujours. Avec peu de transactions, quelques avis peuvent peser excessivement. Un suivi privé des incidents peut suffire jusqu'à ce que le volume rende la note utile.

Cadrer la première transaction

Avant de commander deux parcours complets, cadre le MVP de ta marketplace avec Inyka. Apporte une catégorie, une zone de lancement et le déroulé d'une transaction réelle : c'est assez pour choisir entre V0 monoface et V1 à deux faces.

Réserver un appel découverte de 30 minutes pour mettre à plat l'offre, la demande et le paiement du premier cas d'usage.