Construire une marketplace pour un client réel

Filivoire devait être une véritable marketplace, en conditions réelles, pour des créations au crochet et faites main : de vrais comptes, un inventaire synchronisé entre appareils, et un circuit de paiement capable à terme de traiter de vraies transactions. Pas un catalogue statique de plus.

Une marketplace, quatre rôles

React Native (Expo) + TypeScript, avec Supabase comme backend (Postgres, Auth, Storage, Realtime). Un seul code couvre quatre espaces dédiés, client, vendeur, livreur et admin, répartis sur une quarantaine d'écrans. Les Row Level Security policies de Postgres déterminent qui peut lire ou écrire chaque table : une boutique ne voit que ses propres documents de vérification, un livreur ne voit que les commandes de sa zone.

Quelques choix qui comptent dans ce genre de projet :

• Le panier se répartit automatiquement en une commande par boutique quand un client achète chez plusieurs vendeurs, chacune avec ses propres frais de livraison.
• L'intégration de paiement (GeniusPay) est validée de bout en bout en mode test : paiement, webhook, création de commande, et activable en mode réel par un simple interrupteur admin.
• Le parcours de vérification vendeur/livreur (pièce d'identité + registre de commerce) est validé manuellement par l'admin, avec génération automatique des contrats de partenariat selon le taux de commission.

Démarré sur Firebase, migré vers Supabase

Le projet a commencé sur Firebase, puis a été entièrement migré vers Supabase en cours de route, mêmes fonctionnalités, aucune régression, le jour où les nouvelles exigences de facturation de Firebase sont devenues un blocage pour le moyen de paiement du client. L'intégration du paiement elle-même est passée par plusieurs prestataires avant de se stabiliser sur celui dont le palier de vérification correspondait à la situation du client.

Les vrais défis

Faire fonctionner réellement le temps réel a été le point le plus retors : Supabase Realtime doit être activé explicitement table par table, et échoue silencieusement si on l'oublie. Le chargement initial fonctionne, mais les mises à jour en direct n'arrivent jamais. Autre piège : les colonnes numériques Postgres sont sérialisées en chaîne de caractères par défaut via l'API, ce qui casse discrètement les calculs sur les totaux et les notes tant qu'on ne convertit pas chaque colonne monétaire en type à virgule flottante.

Une leçon qui dépasse ce projet : tester les règles de permission avec un second vrai compte, pas seulement en relisant le code de la policy. Un bug subtil et auto-référentiel dans une politique de contrôle d'accès précoce ne s'est révélé qu'en testant avec un véritable second compte, jamais en inspectant le SQL seul.

Le résultat

Un parcours de commande complet et fonctionnel, navigation, panier réparti par boutique, paiement, préparation par le vendeur, livraison par le livreur, supervision par l'admin, tournant sur un vrai backend et testé avec le client via un lien d'application partagé. Le paiement en argent réel reste volontairement verrouillé derrière un interrupteur admin le temps que le client finalise son inscription chez le prestataire de paiement.