LeCoinDine
Une marketplace C2C en production couvrant annonces, messagerie, paiements carte et wallet, livraison transporteur, remboursements et versement vendeur. J’ai construit les workflows transactionnels et d’intégration du backend derrière le produit mobile.
Le code source est privé. L’étude de cas se concentre sur le flux transactionnel, la cohérence des états de commande et le comportement des intégrations paiement ou transport plutôt que sur les données commerciales internes.
- Modèle produit
- Marketplace pair-à-pair
- Canaux
- iOS · Android · opérations web
- Période
- 2024
- Mon rôle
- Ingénieur backend
- Contexte
- Produit commercial privé
- Périmètre
- Commandes · paiements · livraison · opérations
01
Surfaces produit
Surfaces produit
Des surfaces distinctes rendaient visibles les responsabilités école, association et campus avant même de regarder l’architecture.
Découverte marketplace
Découverte côté client, sélection d’annonces et état produit avant checkout.
Création de commande et checkout
Parcours d’achat carte ou wallet convergeant vers un cycle de commande commun.
Opérations vendeur et commande
Traitement opérationnel des états de commande, livraison et versement après achat.
02
Problème et contraintes
Problème et contraintes
Une vente marketplace traverse des systèmes détenus par différents acteurs : Firebase porte produits et utilisateurs, Stripe déplace l’argent, les transporteurs créent et suivent les colis, et les apps mobiles attendent un statut cohérent. Une mise à jour partielle peut republier un produit vendu, perdre le contexte financier ou mal informer les deux parties.
Les vues client et vendeur doivent rester cohérentes
Une mise à jour transactionnelle partielle peut republier un article vendu ou laisser chaque partie voir une réalité différente.
Deux parcours de paiement, un seul contrat produit
Les achats carte enregistrée et solde wallet doivent converger vers une sémantique de commande identique.
Le comportement varie selon le transporteur
Recherche de relais, formats d’adresse et création d’expédition diffèrent selon le transporteur.
La reprise opérationnelle ne peut pas dépendre de l’app cliente
Les états de livraison ou de versement non synchronisés doivent être réconciliés hors des requêtes utilisateur.
03
Mon périmètre exact
Mon périmètre exact
J’ai conçu
- Le cycle de commande partagé utilisé à la fois par les paiements carte enregistrée et solde wallet.
- La séparation entre le flux de commande côté client, le traitement côté vendeur et les intégrations de service.
- Les frontières de service autour du paiement, des transporteurs, de la recherche de relais et de la résolution de localisation.
J’ai implémenté
- Les routes et services backend pour comptes, annonces, commandes, wallets, messagerie et paiements.
- Les parcours de paiement carte et solde avec transferts Stripe Connect vers les vendeurs.
- Les workflows de livraison sur Mondial Relay, Relais Colis et les services de géocodage.
J’ai collaboré sur
- Le reporting opérationnel, les workflows d’administration et le comportement des statuts client dans le produit mobile.
- L’alignement entre l’UX marketplace et les contraintes des états transactionnels.
03
Objectifs
Objectifs
Cohérence commande
Aligner acheteur, vendeur, produit, paiement et livraison durant toute la vente.
Convergence paiement
Normaliser carte et wallet dans un modèle de transaction et calcul de frais communs.
Abstraction transporteur
Exposer un parcours livraison unique tout en conservant des adaptateurs par fournisseur.
Reprise opérationnelle
Réconcilier commandes non confirmées, non expédiées et non livrées hors des requêtes utilisateur.
04
Architecture système
Architecture système
Flutter · web · parcours acheteur et vendeur
Flask · middleware auth · routes métier
Firebase · annonces · commandes · wallets
Stripe Connect · transporteurs · cartes · email
Apps clientes, état transactionnel backend et services transport ou paiement restent séparés afin que la sémantique de commande ne fuie pas dans chaque intégration.
Stack technique
API
Flask · Firebase Admin · Gunicorn · APScheduler
Commerce
Stripe Connect · Wallet ledger · Invoices · Refunds
Livraison
Mondial Relay · Relais Colis · Google Maps
Clients & opérations
Flutter · Firebase Messaging · Email · Papertrail
05
Modèle d’états
Modèle d’états
Le cycle de commande coordonne disponibilité de l’annonce, mouvement d’argent, expédition et versement vendeur pour deux sources de paiement.
En vente
Le produit est visible et reste rattaché au vendeur.
Checkout démarré
Acheteur, transporteur, point relais, frais et source de paiement sont résolus.
Commande confirmée
Le paiement réussit, la commande est enregistrée et l’annonce quitte le catalogue.
Livrée
La confirmation de réception clôt le parcours acheteur et permet le versement.
Transitions alternatives
Échec de paiement
Aucune commande confirmée n’est créée et l’annonce reste disponible.
Annulation ou litige
Le traitement opérationnel interrompt le parcours standard de livraison et de versement.
Le cycle de commande visible coordonne disponibilité produit, confirmation de paiement, expédition et versement vendeur au lieu de les traiter comme des événements sans lien.
07
Défis d’ingénierie
Défis d’ingénierie
Coordonner une vente entre systèmes
Aucune transaction ne couvre Stripe, collections Firebase, APIs transporteur et notifications.
Utiliser un cycle de commande explicite, des IDs déterministes, des batches Firebase pour le catalogue et une réconciliation planifiée des états incomplets.
Le workflow reste éventuellement cohérent et nécessite des reprises opérationnelles, mais chaque sous-système possède un état source défini.
Si chaque sous-système se met à jour indépendamment sans cycle commun, des articles vendus réapparaissent et le support perd confiance dans la vérité de la commande.
Parité carte et wallet
Les sources de paiement ont des mécaniques différentes sans devoir créer des comportements produit différents.
Calculer montant, livraison et frais une fois, puis faire converger les deux parcours vers les mêmes opérations transaction, expédition et catalogue.
Les identifiants fournisseur doivent toujours être stockés et les remboursements restent branchés par source.
Si chaque parcours de paiement développe sa propre logique de commande, remboursements, versements et statuts utilisateur se désalignent.
Normaliser les contraintes transporteur
Les transporteurs acceptent des formats d’adresse et paramètres d’expédition différents.
Normaliser et tronquer les données utilisateur avant l’envoi vers les adaptateurs propres à chaque transporteur.
Certains comportements restent conditionnels, mais les routes restent indépendantes des protocoles transporteur.
Si les protocoles transporteur fuient dans la logique des routes, les bugs de livraison se multiplient et l’évolution devient risquée.
08
Modes d’échec & mitigation
Modes d’échec & mitigation
Le paiement réussit mais la confirmation de commande tarde
Des IDs transactionnels déterministes et une logique commune de création réduisent le risque d’un mouvement d’argent sans état de commande traçable.
Soumission checkout en double
Le cycle de commande et la logique de déplacement catalogue empêchent une même annonce d’être vendue deux fois après répétition côté client.
Échec transporteur ou dépendance livraison
Les intégrations transporteur restent derrière des services afin que la gestion de commande puisse exposer l’échec explicitement et se récupérer opérationnellement.
La commande reste incomplète après la fin de la requête
Des jobs planifiés clôturent les commandes obsolètes, rafraîchissent les états de livraison et restaurent la visibilité opérationnelle.
09
Décisions techniques
Décisions techniques
Un cycle de commande
Retrait de l’annonce, état du paiement, données de livraison, dossiers acheteur et vendeur et statut de conversation évoluent dans le même parcours d’achat.
Deux sources de paiement
Les achats par carte enregistrée et par solde convergent vers le même modèle de commande, le même calcul de frais et le même versement vendeur.
La livraison derrière des services
Les intégrations transporteur et géocodage restent hors des routes afin que recherche de relais et création d’expédition puissent évoluer séparément.
10
Sécurité & exploitation
Sécurité & exploitation
Vérification des tokens révoqués
Les opérations protégées valident les ID tokens Firebase avec contrôle de révocation.
Frontière de rôle
Les routes administratives ajoutent un contrôle d’appartenance admin mis en cache après authentification.
Planification opérationnelle
Une instance unique exécute réconciliation des commandes, suivi livraison et maintenance avec des logs dédiés.
Échecs traçables
Contexte de requête et événements scheduler fournissent le contexte transactionnel nécessaire aux investigations support.
- Middleware d’authentification sur les opérations compte, commande, paiement et wallet.
- Logs de requêtes et d’erreurs avec contexte transactionnel pour le suivi opérationnel.
- Une seule instance du planificateur imposée entre les workers de production par verrou fichier.
11
Résultat livré
Résultat livré
Résultats d’implémentation — aucune métrique commerciale non vérifiée.
Une sémantique de commande
Carte, wallet et achats multi-articles partagent les mêmes concepts transaction et livraison.
Cycle récupérable
Des jobs planifiés clôturent les commandes obsolètes et actualisent les livraisons hors requête.
Isolation fournisseur
Paiements et transporteurs peuvent évoluer derrière des frontières de service.
Visibilité opérationnelle
Événements commande, scheduler et requête facilitent les investigations client et transaction.
Ce que j’en retiens
“Dans une marketplace C2C, paiement et livraison forment un même cycle opérationnel : chaque changement d’état affecte acheteur, vendeur, annonce et solde plateforme.”