Pumpy Family Life
Une marketplace d’hébergements biface reliant inventaire, disponibilités, réservations, paiements, prestataires et opérations hôte. J’ai conçu les domaines API et le cycle transactionnel du backend au storefront.
Le code source est privé. L’étude de cas se concentre sur les transitions d’état, les règles transactionnelles et les contraintes opérationnelles plutôt que sur l’UI ou les données métier sensibles.
- Modèle produit
- Marketplace biface
- Public
- Voyageurs · hôtes · prestataires
- Période
- 2025
- Mon rôle
- Ingénieur backend & architecte API
- Contexte
- Produit commercial privé
- Périmètre
- Domaines · transactions · intégration frontend
01
Surfaces produit
Surfaces produit
Des surfaces distinctes rendaient visibles les responsabilités école, association et campus avant même de regarder l’architecture.
Parcours de réservation famille
Recherche, réservation et checkout côté utilisateur reliés aux vraies règles de disponibilité et de tarification.
Espace de gestion prestataire
Profil côté offre, statut opérationnel et préparation à la publication avant mise en avant.
États de vérification et de confiance
États d’approbation explicites pour hébergements et prestataires avant publication.
02
Problème et contraintes
Problème et contraintes
Le commerce d’hébergement ne se limite pas aux annonces. Approbation de l’offre, disponibilité, règles tarifaires, devise voyageur, paiement, annulation, remboursements, avis et versement hôte doivent rester cohérents dans le temps.
La confiance avant l’échelle
Hébergements et prestataires ne peuvent pas devenir visibles avant vérification et approbation opérationnelles.
Les états réservation et paiement sont liés, sans être identiques
Les états réservation, paiement, remboursement et versement hôte s’influencent sans se réduire à un seul statut générique.
Inventaire temps réel versus certitude transactionnelle
La disponibilité visible pendant la recherche peut être obsolète au moment de confirmer une réservation.
La visibilité opérationnelle compte
Vérification, snapshots tarifaires, chemins de remboursement et conditions de versement exigent des signaux opérationnels explicites.
03
Mon périmètre exact
Mon périmètre exact
J’ai conçu
- Les frontières métier entre inventaire, prestataires, communauté, réservation et outillage opérationnel.
- Les règles de cycle de vie autour des états approbation, disponibilité, réservation, paiement et remboursement.
- Le modèle transactionnel qui préserve tarification et transitions de paiement indépendamment des écrans de découverte.
J’ai implémenté
- L’API modulaire couvrant utilisateurs, hébergements, prestataires, communauté, dashboard et flux transactionnels.
- Les workflows de réservation, disponibilité, avis et vérification rattachés à des transitions d’état explicites.
- L’intégration du storefront React pour le cache de requêtes, la découverte cartographique et les formulaires transactionnels.
J’ai collaboré sur
- Les politiques opérationnelles autour de l’approbation des prestataires, de la visibilité publique et des contraintes de réservation.
- Le comportement frontend alignant l’UX marketplace avec les règles transactionnelles et de vérification.
03
Objectifs
Objectifs
Inventaire
Modéliser propriétés, hôtels, chambres et calendriers sans dupliquer les règles communes.
Intégrité transactionnelle
Valider la disponibilité et conserver le calcul commercial exact utilisé au checkout.
Cycle financier
Rendre explicites les transitions paiement, remboursement, frais et versement hôte.
Exploitation
Fournir vérification, tableaux de bord, logs et accès média signé aux équipes opérationnelles.
04
Architecture système
Architecture système
React · recherche · cartes · checkout
Django REST · JWT · modules métier
PostgreSQL · Redis · stockage objet
Stripe · cartes · notifications
Les surfaces marketplace sont restées distinctes, tandis qu’un backend métier commun imposait les règles de réservation, paiement, vérification et tarification.
Stack technique
Backend
Django 4.2 · Django REST Framework · PostgreSQL · Django Filters
Frontend
React 18 · TypeScript · TanStack Query · Zustand · Mapbox
Transactions
Stripe · Payment snapshots · Refund lifecycle · Host payouts
Runtime
Redis · Cloudflare R2 · WhiteNoise · Structured logging
05
Modèle d’états
Modèle d’états
L’état du paiement est validé indépendamment de celui de la réservation afin que retries, annulation et remboursements restent explicites et auditables.
En attente
Prix, frais, taux de change et références de réservation sont figés.
En traitement
Le prestataire de paiement confirme ou rejette la transaction.
Terminé
La réservation est payée et le versement hôte suit ensuite son propre cycle.
Transitions alternatives
Échec → attente
Une transaction échouée peut être retentée sans créer de transition invalide.
Remboursement partiel ou total
Seul un paiement terminé peut passer dans un état de remboursement.
Annulé
Un paiement en attente ou en traitement peut se terminer sans versement.
L’état du paiement et celui de la réservation restent explicitement liés sans être fusionnés, ce qui rend retries, remboursements et annulations auditables.
07
Défis d’ingénierie
Défis d’ingénierie
Un prix historique doit le rester
Tarifs, promotions et conversion de devise peuvent changer après checkout.
Figer détail tarifaire par nuit, frais de service, version de facturation et taux EUR dans le paiement.
Davantage de champs financiers et migrations sont nécessaires, mais reporting et remboursements restent reproductibles.
Sans snapshots, remboursements, investigations support et reporting financier dérivent au fur et à mesure que le catalogue change.
Empêcher les transitions financières invalides
Des mises à jour génériques peuvent rembourser une transaction impayée ou terminer une transaction annulée.
Encoder les transitions autorisées dans le modèle et rejeter tout changement hors de ce graphe.
Les corrections exceptionnelles nécessitent un outillage opérationnel explicite plutôt que des modifications directes.
Si les états réservation et paiement dérivent librement, les utilisateurs voient des statuts impossibles et l’exploitation perd confiance dans le ledger.
Disponibilité à la frontière de réservation
Les résultats de recherche peuvent être obsolètes lorsque le voyageur confirme ses dates.
Traiter le calendrier comme donnée de découverte et revalider lors de la création de réservation.
Le checkout peut rejeter une option auparavant visible, mais la double réservation est bloquée à la frontière transactionnelle.
Si la disponibilité de recherche est crue aveuglément, l’inventaire obsolète conduit à la double réservation ou à du nettoyage manuel coûteux.
08
Modes d’échec & mitigation
Modes d’échec & mitigation
Vérification prestataire incomplète
Les états d’approbation de l’offre bloquent la publication tant que les contrôles hôte ou hébergement requis ne sont pas terminés.
Réservation créée alors que le paiement est non résolu
Les transitions de paiement sont validées indépendamment pour qu’une réservation ne soit pas traitée comme financièrement terminée par erreur.
La disponibilité vue en recherche devient obsolète au checkout
La disponibilité est revalidée à la frontière de réservation au lieu de faire confiance aux données de découverte.
Le remboursement ou le versement contredit l’historique de paiement
Des graphes de transition autorisés gardent remboursements et versements hôte liés à des états antérieurs valides.
09
Décisions techniques
Décisions techniques
Les domaines avant les endpoints
Les applications Django séparent inventaire, utilisateurs, prestataires, chat et éditorial, tandis qu’un routeur expose une surface cohérente.
La vérification fait partie de l’offre
Hébergements et prestataires passent par des états d’approbation explicites avant publication.
Un parcours transactionnel unifié
Disponibilité, prix, état de réservation, paiement et éligibilité à l’avis forment un même cycle.
10
Sécurité & exploitation
Sécurité & exploitation
Cycle d’authentification
Rotation JWT, blacklist et logout explicite coexistent avec les sessions pour l’outillage opérationnel.
Limitation des requêtes
Endpoints anonymes, authentifiés et d’authentification disposent de budgets distincts.
Accès objet privé
Le stockage cloud utilise des URLs signées et des clés objet non écrasées.
Diagnostic opérationnel
Request IDs, temps de traitement, signaux de requêtes lentes et headers expurgés facilitent les investigations.
- Rotation JWT et parcours explicites de logout/blacklist.
- Validation des disponibilités à la frontière de réservation.
- Fallback de stockage et configuration par environnement.
11
Résultat livré
Résultat livré
Résultats d’implémentation — aucune métrique commerciale non vérifiée.
Transactions auditables
Les paiements conservent les hypothèses de prix et conversion utilisées à l’achat.
Cycle imposé
Les transitions de paiement invalides sont rejetées par le modèle métier.
Offre gouvernée
Les états d’approbation contrôlent la publication des hébergements et prestataires.
Extension modulaire
Marketplace, prestataires, communauté et éditorial évoluent sans module applicatif monolithique.
Ce que j’en retiens
“La complexité marketplace est surtout celle des cycles de vie : états, responsabilités et transitions doivent être clairs avant les intégrations.”