MyBabySitt : une marketplace de garde d’enfants lancée en 16 semaines

À retenir

• 16 semaines, 4 personnes : une application iOS et Android, un back-office et une interface web, avec réservation, paiement séquestré, messagerie et vérification d’identité.
• Pile technique : React Native pour les deux applications, Next.js pour l’interface web et l’API, Postgres comme source de vérité, Stripe pour le paiement et la vérification des prestataires, Twilio pour les SMS et les notifications.
• Résultats mesurés à six mois : revenus multipliés par 4,2, taux de réservation en hausse de 78 %, délai moyen entre la demande et la mise en relation de 32 minutes.
• La décision la plus structurante a été de déléguer la vérification d’identité à Stripe plutôt que de la construire. Elle a économisé plusieurs semaines et sorti les pièces d’identité de notre base de données, donc de notre responsabilité.
• Le séquestre n’est pas une fonctionnalité de confort, c’est le modèle économique. L’autorisation est prise à la réservation, la capture à la fin de la garde, la commission retenue au moment du transfert. Sans cette mécanique, les deux parties s’échangent leurs numéros au premier contact.
• Ce qui coûte le plus dans ce type de projet n’est pas le parcours nominal, ce sont les cas limites du paiement : garde annulée, garde écourtée, carte refusée à la capture, prestataire pas encore vérifié au moment du reversement.
• Fourchette d’un projet équivalent aujourd’hui : 60 000 à 100 000 €, le bas de la bande d’une marketplace, parce que le périmètre est resté net. Voir combien coûte une marketplace.

La plupart des applications de mise en relation échouent pour une raison qui n’a rien de technique. Soit elles restent vides, parce que personne n’a amorcé les deux côtés du marché. Soit elles se font contourner : les deux parties se trouvent une fois, échangent leurs numéros, et la plateforme ne revoit jamais la deuxième transaction.

MyBabySitt a traité ces deux risques dans la conception, pas dans le marketing. Voici le détail : le point de départ, ce qui a été écarté au cadrage, l’architecture retenue, le déroulé des seize semaines, et ce que cela a produit.

Le point de départ : un marché où la confiance précède le prix

Confier son enfant à un inconnu n’est pas un acte d’achat ordinaire. Un parent ne compare pas des tarifs, il cherche une raison de dire oui. Toute l’application découle de cette phrase : chaque écran doit retirer un doute, et aucun ne doit en ajouter.

L’appel découverte dure 45 minutes et se tient avec un fondateur, pas avec un commercial. Sur ce projet, il a surtout servi à identifier le vrai point dur, qui n’était ni le design ni la recherche : à quel moment précis l’argent change de main. C’est de cette question que découlent le séquestre, la vérification d’identité et la messagerie à numéros masqués. Les trois répondent au même problème.

Ce que vit un parent	Ce que l’application doit produire	Comment
Il cherche une garde dans l’heure, pas dans la semaine	Des disponibilités réelles à proximité, tout de suite	Index géographique sur les profils, recherche par rayon croissant
Il ne connaît pas la personne qui sonnera à sa porte	Une identité vérifiée, pas un profil déclaratif	Vérification d’identité déléguée au prestataire de paiement
Il ne sait pas si les avis sont sincères	Des avis attachés à une garde réellement payée	Un avis ne peut exister sans réservation terminée en base
Il ne veut pas payer d’avance un service non rendu	Un paiement retenu jusqu’à la fin de la garde	Autorisation à la réservation, capture à la fin
Il ne veut pas donner son numéro de téléphone	Un canal de discussion dans l’application	Messagerie temps réel, numéros jamais exposés

Le même raisonnement vaut de l’autre côté. Une baby-sitter veut être sûre d’être payée et ne veut pas communiquer son numéro à des inconnus. Les deux populations ont le même besoin, exprimé à l’envers, et c’est une bonne nouvelle : une seule mécanique répond aux deux.

Le cadrage : ce qu’on a décidé de ne pas faire

Le cadrage, la maquette cliquable et le devis ligne par ligne sont livrés sous 48 heures et offerts. Sur un projet de mise en relation, ce document sert surtout à poser ce qui ne sera pas construit, car c’est ce qui tient le délai.

Écarté au cadrage	Pourquoi	Quand le reconsidérer
Plusieurs devises et paiement à l’international	Le marché est local par nature : on garde une garde d’enfants dans sa ville	Jamais, sur ce produit
Un système de litiges complet	Il n’y a pas de litige avant qu’il y ait du volume. On a gardé le remboursement, pas l’arbitrage outillé	Au-delà de quelques centaines de gardes par mois
Un moteur de recherche dédié	Postgres suffit largement au volume d’une place de marché locale, et c’est un système de moins à synchroniser	Si la recherche devient sémantique ou multi-critères complexe
Un abonnement pour les prestataires	Deux modèles économiques à valider en même temps, c’est aucun des deux validé	Une fois la commission prouvée
Un back-office complet dès le départ	On a livré les quatre écrans d’administration réellement utilisés chaque jour, pas les vingt imaginés	À mesure que les demandes de support se répètent

Cette dernière ligne mérite une remarque générale. Le back-office est le poste le plus souvent surdimensionné d’une plateforme : on dessine vingt écrans d’administration dont trois serviront. La bonne méthode consiste à livrer le strict nécessaire, puis à ajouter un écran chaque fois qu’une opération revient trois fois à la main.

L’architecture, brique par brique

Quatre personnes, seize semaines, deux plateformes mobiles : la pile a été choisie pour que ce ratio soit tenable, pas pour la démonstration technique.

Une seule base de code pour iOS et Android

React Native était la condition pour tenir le délai à quatre personnes. Le produit n’a besoin ni de réalité augmentée, ni de capteurs, ni d’audio temps réel, c’est-à-dire d’aucun des cas où le natif reste indispensable. Le comparatif complet est dans React Native, Flutter ou natif. En face, deux bases de code natives auraient demandé soit deux fois plus de monde, soit deux fois plus de temps, pour le même produit.

Le back et l’interface web tournent sur Next.js, avec Postgres comme source de vérité unique. Un seul schéma de données pour les deux applications et le back-office, ce qui évite la dérive la plus courante d’un projet mobile : deux représentations du même objet qui divergent lentement.

La recherche de proximité

Trouver les baby-sitters disponibles autour d’un parent n’est pas un problème de distance, c’est un problème de croisement. Il faut intersecter trois choses : la position, le créneau demandé, et les critères du parent. Chacune prise seule est triviale, les trois ensemble deviennent une requête qui doit répondre en quelques dizaines de millisecondes sur un téléphone en 4G.

La réponse retenue tient en trois décisions. Un index géographique dans Postgres, parce qu’au volume d’une place de marché locale il n’y a aucune raison d’ajouter un moteur de recherche séparé. Une recherche par rayon croissant plutôt que par rayon fixe : on élargit jusqu’à obtenir assez de résultats, ce qui évite l’écran vide en zone peu dense. Et le calcul des disponibilités fait en base, pas dans l’application, pour que les deux plateformes mobiles n’aient pas à répliquer la même logique.

Le paiement et le séquestre : le vrai morceau

C’est ici que passe l’essentiel de la charge, et c’est ce que les devis bon marché omettent. Encaisser pour soi est simple. Encaisser pour le compte d’un tiers, retenir une part, reverser le reste à la bonne date, et savoir revenir en arrière, ne l’est pas.

Le fonctionnement retenu suit le cycle de la garde, pas celui de la commande :

• À la réservation, une autorisation est prise sur la carte du parent. L’argent n’est pas encaissé, il est réservé. Le parent voit son plafond diminuer, pas son compte débité.
• À la fin de la garde, la capture est déclenchée. C’est ce décalage, et lui seul, qui constitue le séquestre du point de vue du produit.
• Au transfert, la commission de la plateforme est retenue et le solde part vers le compte connecté de la baby-sitter. La commission n’est jamais une facture séparée que quelqu’un pourrait ne pas payer.
• En cas d’annulation, l’autorisation est relâchée si la capture n’a pas eu lieu, remboursée sinon. Les deux chemins sont différents dans le code et doivent être testés séparément.

Les cas limites sont l’essentiel du travail, et ils ne se voient sur aucune maquette : une garde écourtée qu’il faut facturer au prorata, une carte refusée au moment de la capture alors que la garde a bien eu lieu, une baby-sitter dont la vérification d’identité n’est pas terminée quand arrive l’heure du reversement, une autorisation qui expire parce que la réservation était très en avance. Chacun exige une décision produit avant d’exiger une ligne de code.

La vérification d’identité, déléguée plutôt que construite

C’est la décision la plus structurante du projet, et elle est contre-intuitive : nous n’avons pas construit la collecte des pièces d’identité. Le prestataire de paiement l’exige de toute façon avant d’autoriser un reversement, il sait le faire, et il l’opère dans tous les pays où il opère.

Deux conséquences. D’abord plusieurs semaines économisées sur un périmètre de seize, ce qui n’est pas une optimisation mais une condition de faisabilité. Ensuite, et c’est le point important, les pièces d’identité ne transitent jamais par notre base. Une donnée que l’on n’héberge pas est une donnée que l’on ne peut pas perdre. Sur la répartition des responsabilités entre un service et son sous-traitant, voir l’article 28 du RGPD.

La messagerie et les numéros masqués

La messagerie temps réel sert deux objectifs qui n’en font qu’un. Permettre au parent et à la baby-sitter de caler les détails avant la garde, et empêcher que cet échange sorte de la plateforme. Les numéros ne sont jamais exposés. Les notifications hors application passent par SMS, sans révéler le numéro de l’autre partie.

C’est un arbitrage produit, pas une contrainte technique : rendre l’échange assez confortable dans l’application pour que personne n’ait envie d’en sortir. Une messagerie médiocre pousse les utilisateurs vers les leurs, et c’est le début du contournement.

Les avis vérifiés

Un avis ne peut pas exister sans une réservation payée et terminée qui lui corresponde en base. La contrainte est posée au niveau des données, pas au niveau de l’interface, donc elle ne se contourne pas. C’est une règle d’une ligne qui vaut mille mots de modération : il n’y a pas de faux avis à filtrer s’il est impossible d’en déposer un.

Le déroulé des seize semaines

Sprints de deux semaines, démo le vendredi, URL de préview mise à jour à chaque poussée, accès au dépôt dès le premier jour. Le découpage suit la valeur livrée, pas les couches techniques : on ne livre pas « la base de données » puis « les écrans », on livre un parcours qui fonctionne de bout en bout, puis le suivant.

Période	Ce qui est livré	Ce qui est validé
Semaines 1 à 5	Comptes, profils, recherche de proximité, premier écran de résultats	Un parent trouve une baby-sitter et voit son profil
Semaines 5 à 9	Réservation, paiement, séquestre, annulations et remboursements	Une garde peut être réservée, payée et annulée sans intervention
Semaines 9 à 12	Messagerie temps réel, notifications, SMS	Les deux parties échangent sans quitter l’application
Semaines 11 à 14	Vérification d’identité des prestataires, avis vérifiés, back-office	Un prestataire est payé, un avis est déposé, le support peut intervenir
Semaines 14 à 16	Recette de bout en bout, audit de sécurité et de performance, publication	L’application passe la revue des boutiques et sort

Deux semaines se recouvrent volontairement, aux semaines 11 à 14. Ce n’est pas un hasard de planning : la vérification d’identité dépend d’un prestataire externe dont les délais de validation ne se contrôlent pas. On la lance donc pendant que la messagerie se termine, pour que l’attente soit absorbée au lieu d’être subie.

Un délai est systématiquement sous-estimé sur ce type de projet : la publication sur les boutiques d’applications. La revue d’Apple se compte en jours et peut demander un second passage, en particulier sur une application qui manipule des paiements et des mineurs. Elle se budgète dans le planning, pas dans l’espoir.

Les résultats, six mois après

Indicateur	Résultat	Ce qu’il dit
Revenus mensuels	× 4,2 en 6 mois	Les deux côtés du marché se sont alimentés l’un l’autre
Taux de réservation	+ 78 %	Les demandes aboutissent, le catalogue n’est pas décoratif
Délai moyen de mise en relation	32 minutes	La promesse d’immédiateté est tenue, pas seulement affichée

Le troisième chiffre est le plus parlant pour qui construit une plateforme de mise en relation. Un délai moyen de 32 minutes signifie que l’offre est suffisamment dense là où la demande se trouve. C’est la seule mesure qui dit si l’amorçage a réussi, et aucune ligne de code ne la produit toute seule : elle se gagne en recrutant des prestataires dans les quartiers où les parents cherchent, un par un, pendant que l’application se construit.

« Les parents recommandent l’app à leurs amis dès la première garde », résume Mike, le fondateur. C’est la formulation d’un marché qui a pris : l’acquisition cesse d’être une ligne de budget et devient une conséquence du produit.

Ce qu’on referait pareil, et ce qu’on regarderait autrement

Pareil : déléguer la vérification d’identité, construire le séquestre dans le premier périmètre, livrer un back-office minimal, et refuser l’international. Ces quatre décisions ont rendu les seize semaines possibles.

Autrement : sur un projet de ce type, nous instrumentons désormais le délai de mise en relation dès la première semaine de production, et non une fois les premiers chiffres d’affaires lisibles. C’est l’indicateur qui alerte le plus tôt quand un côté du marché décroche, et il ne coûte presque rien à poser. Nous aurions aussi outillé plus tôt le remboursement partiel, qui est arrivé comme une évidence dès les premières gardes écourtées.

Combien coûterait un projet équivalent aujourd’hui ?

Entre 60 000 et 100 000 € pour une première version qui encaisse, soit le bas de la bande d’une marketplace, précisément parce que le périmètre est resté net : deux rôles, une transaction, une messagerie. Au-delà de 100 000 €, on entre dans l’arbitrage de litiges, les avis modérés, les devises multiples et les tableaux de bord prestataire.

S’y ajoutent deux coûts d’exploitation absents des devis. Les frais de paiement, 1,5 % plus 0,25 € par transaction par carte européenne standard chez Stripe (tarifs publics), à déduire de votre commission. Et les obligations d’un opérateur de plateforme : le dispositif DPI-DAC7 (impots.gouv.fr) impose de remettre chaque année à chaque prestataire un récapitulatif de ses opérations et de le transmettre à l’administration avant le 31 janvier.

Questions fréquentes

Combien de temps faut-il pour sortir une application de mise en relation ?

Seize semaines ici, pour iOS, Android, une interface web et un back-office. Ce délai tient à un périmètre tenu : deux rôles, une transaction, une messagerie. Chaque rôle supplémentaire ou chaque mode de paiement additionnel déplace l’échéance de plusieurs semaines, pas de quelques jours, parce qu’il multiplie les cas de test croisés.

Pourquoi déléguer la vérification d’identité plutôt que la construire ?

Pour trois raisons qui vont dans le même sens. Le prestataire de paiement l’exige de toute façon avant tout reversement, donc la construire reviendrait à la faire deux fois. Il la fait mieux, parce que c’est son métier et qu’il l’opère dans chaque pays. Et surtout, les pièces d’identité ne touchent jamais votre base : c’est une responsabilité de moins et un risque de moins.

Pourquoi autoriser à la réservation et capturer à la fin ?

Parce que c’est ce qui fait le séquestre du point de vue du parent : il ne paie réellement que si la garde a eu lieu. Du point de vue de la plateforme, c’est aussi ce qui garde la transaction dans le produit, donc la commission. Attention cependant : une autorisation a une durée de vie limitée, ce qui impose de la renouveler sur les réservations prises très en avance.

Comment empêcher les utilisateurs de se contacter en dehors de l’application ?

On ne l’empêche pas, on retire l’intérêt de le faire. Numéros masqués, messagerie assez bonne pour qu’elle suffise, paiement qui protège les deux parties, avis qui ne comptent que dans l’application. Un utilisateur qui sort perd sa protection et son historique. Une plateforme qui ne lui offre rien de tout cela est contournée dès le deuxième échange.

Quel indicateur suivre les premières semaines ?

Le délai moyen entre une demande et une mise en relation acceptée. Il dit si l’offre est assez dense là où la demande se trouve, bien avant que le chiffre d’affaires ne soit lisible. S’il s’allonge, le problème est l’amorçage d’un des deux côtés, jamais le produit.

Peut-on commencer sans application mobile ?

Oui, et c’est souvent plus sage. Un site, un formulaire et une mise en relation faite à la main valident le marché pour une fraction du budget. L’application devient justifiée quand le volume rend la mise en relation manuelle intenable, ou quand l’immédiateté fait partie de la promesse, ce qui était le cas ici : on ne cherche pas une garde par courriel.

Qui possède le code à la fin ?

Le client, et dès le premier jour : l’accès au dépôt est versé à J+1, pas à la livraison. Ce n’est pas une faveur, c’est la seule configuration dans laquelle un projet reste reprenable par une autre équipe. Les clauses qui le garantissent sont détaillées dans notre article sur la propriété du code source.

Glossaire

• Mise en relation : plateforme qui rapproche deux populations et prélève une part sur la transaction. Son produit est la rencontre, pas le bien vendu.
• Séquestre : le paiement est autorisé à la réservation puis capturé à la fin du service, avant d’être reversé au prestataire moins la commission.
• Autorisation et capture : deux étapes distinctes d’un paiement par carte. L’autorisation réserve la somme, la capture la prélève. C’est le décalage entre les deux qui crée le séquestre.
• Compte connecté : compte ouvert chez le prestataire de paiement au nom du prestataire de service, qui permet de lui reverser directement sa part.
• Amorçage : le problème de la poule et de l’œuf. Il faut de l’offre pour attirer la demande et de la demande pour attirer l’offre.
• Avis vérifié : avis rattaché à une transaction réellement payée sur la plateforme. C’est ce qui le distingue d’un commentaire libre.
• Délai de mise en relation : temps écoulé entre une demande et son acceptation. Le meilleur indicateur précoce de la santé d’une place de marché.

Sources

• Fiche projet MyBabySitt · périmètre, durée, équipe, pile technique et résultats publiés · TikupMedia
• Notre méthode en quatre phases · le cadre de travail décrit ici · TikupMedia
• Tarifs Stripe en France · frais par transaction et paiement pour compte de tiers · Stripe
• Dispositifs DPI-DAC7 · obligations déclaratives d’un opérateur de plateforme · impots.gouv.fr
• Règlement général sur la protection des données, article 28 · responsabilités entre un service et son sous-traitant · CNIL
• Les TIC et le commerce électronique dans les entreprises en 2024 · INSEE

À lire aussi sur le blog

• Combien coûte une marketplace sur mesure · les fourchettes et les postes que ce projet illustre
• Combien coûte une application mobile · pour situer un projet de cette taille
• React Native, Flutter ou natif · le choix technique retenu ici, et quand il ne convient pas
• MVP ou produit fini · pourquoi le séquestre ne pouvait pas attendre la version 2
• Cahier des charges d’une application mobile · pour tenir un périmètre en seize semaines

Aller plus loin avec nous

• Applications mobiles sur mesure · iOS et Android, MVP en 6 à 10 semaines, à partir de 15 000 €
• SaaS et plateformes · plateformes multi-rôles, à partir de 25 000 €
• Les neuf dossiers complets · chaque projet documenté avec ses chiffres
• Un premier échange sous 48 h · on regarde quel côté du marché vous tenez déjà