Filivoire

Marketplace numérique conçue pour un client afin de présenter et vendre des créations artisanales et au crochet.

Le client avait besoin d’une véritable marketplace, en conditions réelles, pour ses 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 simple catalogue statique.

Construire une marketplace complète multi-rôles (client, vendeur, livreur, admin) sur un vrai backend, avec authentification, synchronisation des données en temps réel, stockage d’images et une intégration de paiement prête à passer en production.

• •Quatre espaces dédiés (client, vendeur, livreur et admin) répartis sur une quarantaine d’écrans
• •Panier automatiquement réparti en une commande par boutique quand un client achète chez plusieurs vendeurs, chacune avec ses propres frais de livraison
• •Synchronisation des données en temps réel sur tous les appareils connectés
• •Intégration de paiement GeniusPay validée de bout en bout en mode test (paiement → webhook → création de commande), activable en mode réel par l’admin
• •Parcours de vérification vendeur et livreur (pièce d’identité + registre de commerce), validé par l’admin
• •Contrats de partenariat générés automatiquement selon le taux de commission, avec accusé d’acceptation dans l’app

Un seul code React Native/Expo couvre les quatre rôles, avec Postgres (Supabase) comme source de vérité unique. Les policies Row Level Security 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. Supabase Realtime garde chaque écran synchronisé dès qu’une donnée change, sans interrogation périodique.

Démarré sur Firebase, puis migré entièrement vers Supabase en cours de projet (mêmes fonctionnalités, aucune régression) une fois que les nouvelles exigences de facturation de Firebase sont devenues un blocage pour le moyen de paiement du client. L’intégration du paiement en 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.

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.

Faire fonctionner réellement le temps réel : 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. Les colonnes numériques Postgres sont aussi 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 que chaque colonne monétaire n’est pas convertie en type à virgule flottante.

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, pas en inspectant le SQL seul.