Batkari,la marketplace où les annonces naissent et disparaissent en direct sur la carte
Une marketplace mobile géolocalisée pour l’outre-mer, avec des annonces éphémères en temps réel.
En route
Client
Client non cité
Période
mai à juin 2026
Rôle
Conception et livraison au nom de FilouTech, interlocuteur unique du client
Type
Application mobile iOS et Android, API temps réel et back-office web
Statut
En cours de déploiement
Le butin :Une marketplace géolocalisée où les annonces naissent et disparaissent en direct sur la carte, livrée en trois applications en cinq semaines environ.
Un client voulait lancer une marketplace mobile pensée pour les territoires d’outre-mer. FilouTech a pris en charge la conception et la livraison des trois briques du produit : l’application mobile, l’API temps réel et le back-office. J’étais l’interlocuteur unique du client, avec des points d’étape réguliers sur un site d’avancement dédié. Le développement s’est déroulé de mi-mai à mi-juin 2026. La mise en ligne est en cours.
La cible · Le problème
Dans les DOM-TOM, beaucoup de petites ventes se font dans l’instant et à quelques rues de distance. Les sites de petites annonces classiques sont pensés pour l’inverse : des annonces qui restent en ligne des semaines, et une recherche par mots-clés.
Le besoin réel : voir d’un coup d’œil ce qui est disponible autour de soi, maintenant, et contacter le vendeur tout de suite.
Le plan · La solution
L’utilisateur ouvre une carte qui affiche en temps réel les annonces et les vendeurs autour de lui. Il filtre par catégorie, les épingles se regroupent quand on dézoome, et un badge signale les vendeurs professionnels.
Chaque annonce a une durée de vie limitée. À expiration, elle disparaît de la carte toute seule, et le vendeur comme les acheteurs qui l’ont mise en favori sont prévenus 15 minutes avant. On publie avec photos et prix, on marque vendu, on retire ou on republie, et on discute avec le vendeur dans une messagerie intégrée.
Un modèle freemium encadre l’usage. En gratuit, deux annonces actives, une photo et deux heures de visibilité. En Premium, jusqu’à cinq photos et une durée au choix, d’une heure à sept jours. Côté équipe, un back-office web sert à modérer les annonces, gérer les utilisateurs, les catégories et les bons plans, et suivre les statistiques.
Application mobile FlutteriOS et Android, carte en directBack-office webNext.js, React : modération, catégories, statistiquesServeurAPI Node.jsFastify, TypeScript, REST et WebSocketPostgreSQL et PostGISpositions, index spatial, recherches de proximitéTâche planifiéeexpiration et alertesWebSocket, par zoneRESTSQL spatialMessagerieFirestoreAbonnements, publicitéRevenueCat, AdMobPhotosCloudflare R2Notifications pushFirebase Cloud Messagingconversationsachats in-apppushphotosServices tiers
Application mobile FlutteriOS et Android, carte en directBack-office webNext.js, ReactServeurAPI Node.jsFastify, TypeScript, REST et WebSocketPostgreSQL et PostGISrecherches de proximitéTâche planifiéeexpiration et alertesServices tiersMessagerieFirestoreAbonnements, publicitéRevenueCat, AdMobPhotosCloudflare R2Notifications pushFirebase Cloud Messaging
Schéma d’architecture de Batkari en plan cyanotype : application Flutter et back-office reliés à une API Node.js en REST et WebSocket, base PostgreSQL avec PostGIS, tâche d’expiration et services tiers
L’exécution · Ce que FilouTech a livré
Un socle commun : un monorepo pour les trois applications, PostgreSQL avec PostGIS en conteneurs pour le développement.
L’API : Fastify en TypeScript strict, douze modules métier, 47 routes HTTP et une connexion WebSocket pour la carte, validation des entrées, journaux structurés.
La géolocalisation : stockage des positions en coordonnées géographiques avec un index spatial, recherches de proximité en SQL.
La carte en direct : chaque création, modification ou suppression d’annonce est poussée aux seuls utilisateurs dont la zone est concernée.
Le cycle de vie des annonces : publication, vente, retrait, republication, expiration automatique avec alerte préalable.
L’authentification : e-mail et mot de passe, Google, Apple et numéro de téléphone, avec des jetons révocables.
Les notifications push : annonce vendue, bientôt expirée, expirée, nouveau message, dans le respect des préférences de chacun.
La messagerie : conversations sur Firestore avec compteur de messages non lus.
La monétisation : abonnement Premium in-app via RevenueCat, publicités AdMob, limites du forfait gratuit appliquées côté serveur.
L’application Flutter : quinze écrans, de l’onboarding au profil à onglets, avec un cache de la carte qui tient sans réseau et se resynchronise au retour de la connexion.
Le back-office : Next.js 15 et React 19, tableau de bord, utilisateurs, modération, catégories et bons plans.
Le matériel · Stack technique
Mobile : Flutter, Dart, Riverpod, GoRouter, Dio, Google Maps avec regroupement des épingles.
API : Node.js, Fastify 5, TypeScript, WebSockets, Zod.
Données : PostgreSQL 16 et PostGIS via Prisma, Firestore pour la messagerie.
Services : Firebase Cloud Messaging, RevenueCat, AdMob, Cloudflare R2 pour les photos.
Incident n°1 : de la géolocalisation sérieuse avec un ORM qui ne la connaît pas
Imprévu. Prisma ne gère pas les types géographiques de PostGIS. Or toute l’application repose sur des recherches du type « ce qui est à moins de X kilomètres ».
Parade. La colonne de position et son index spatial sont créés par une migration SQL écrite à la main, déclarée comme type non géré dans le schéma Prisma. Les recherches de proximité passent par des requêtes SQL paramétrées (ST_DWithin, ST_Distance).
Ce que j’en retiens. On peut garder le confort d’un ORM et descendre au SQL là où la performance et l’expressivité l’exigent.
Incident n°2 : une carte vivante qui ne noie pas les téléphones
Imprévu. Diffuser chaque nouvelle annonce à tous les utilisateurs connectés aurait saturé les mobiles d’événements inutiles.
Parade. Chaque client WebSocket déclare sa zone (centre, rayon, catégorie). Le serveur ne lui envoie que ce qui le concerne. Les annonces expirées sont retirées en direct grâce à leur dernière position connue.
Ce que j’en retiens. Le filtrage côté serveur rend le temps réel viable sur mobile.
Incident n°3 : des annonces éphémères qui n’échappent jamais à l’alerte
Imprévu. Une tâche périodique fait expirer les annonces toutes les 15 minutes. Selon le moment de publication, certaines risquaient d’expirer sans que le vendeur soit prévenu, ou d’être prévenues deux fois.
Parade. Une fenêtre d’alerte de 15 minutes, alignée exactement sur la cadence de la tâche, et un horodatage de l’alerte pour éviter les doublons.
Ce que j’en retiens. Aligner la fenêtre et la cadence d’une tâche planifiée supprime les cas limites, au lieu de les traiter un par un.
Le bilan · Résultats
Trois applications livrées dans un même dépôt en cinq semaines environ.
47 routes d’API, 15 écrans mobiles, 5 pages de back-office.
Une monétisation complète dès la première version : abonnement, publicité et limites du forfait gratuit.
