Marketplace et opérations travel

Lokafy

Plateforme marketplace de réservation où la fiabilité, les intégrations et la cohérence du parcours influencent directement la conversion.

Intervention sur une plateforme de réservation servant plus de 10k utilisateurs mensuels, où la cohérence d’état et la fiabilité des partenaires guidaient les choix backend.

Problème

Le parcours de réservation dépendait d’APIs partenaires lentes, incohérentes et hors du contrôle direct de l’équipe, avec un vrai risque d’états contradictoires, d’actions dupliquées côté partenaire et de friction sur un flow sensible à la conversion.

Mon rôle

Conception des transitions d’état et de la validation backend des parcours de réservation

Ownership des intégrations partenaires et des stratégies de reprise

Mise en place de flows async de synchronisation pour protéger le parcours de réservation

Contribution aux changements de delivery sur AWS/GCP et Jenkins

Approche

J’ai traité la réservation comme un workflow explicite, déplacé la synchronisation partenaire fragile vers des jobs récupérables, et resserré la frontière entre état frontend et vérité backend.

Impact

Stabilisation des parcours de réservation face à des APIs partenaires peu fiables.

Réduction des incohérences d’état dans les workflows de réservation multi-étapes.

Transformation des échecs de synchronisation partenaire en flows récupérables plutôt qu’en blocage produit.

Contribution à des sorties plus sûres sur les changements API, intégration et delivery.

Décisions clés

Modélisation de la réservation comme un workflow explicite -> réduction des incohérences sur les parcours multi-étapes.

Encapsulation de la variabilité partenaire derrière des contrats backend -> moins de dérive de logique autour des APIs tierces.

Déplacement de la synchronisation partenaire en jobs récupérables -> parcours utilisateur moins exposé aux lenteurs externes.

Alignement de la validation backend avec les flows frontend critiques -> moins de mismatch entre progression UI et état réel.

Workflow de réservation et frontière partenaire

Montre comment les demandes de réservation traversent la validation, l’intégration partenaire et les parcours asynchrones de reprise.

flowchart LR
    A[User Booking Flow] --> B[Frontend Client]
    B --> C[Booking API]
    C --> D[Validation & Pricing Rules]
    D --> E[(Booking Data)]
    C -. retry jobs .-> F[Background Workers]
    F --> G[Partner API Connectors]
    G --> H[Partner Systems]
    F --> I[Status Sync & Recovery]

Flèches pleines : parcours principalFlèches pointillées : sync partenaire et retriesNœuds arrondis : étapes côté utilisateur

Mon ownership

Conception des transitions d’état et de la validation backend des parcours de réservation

Ownership des intégrations partenaires et des stratégies de reprise

Mise en place de flows async de synchronisation pour protéger le parcours de réservation

Contribution aux changements de delivery sur AWS/GCP et Jenkins

Arbitrages

Acceptation d’une validation backend plus stricte pour éviter la dérive d’état entre clients et partenaires.

Déplacement de davantage d’intégrations vers l’asynchrone, avec un besoin accru de gestion de reprise.

Ce que j’améliorerais

Renforcer les contrôles d’idempotence autour des callbacks et resynchronisations partenaires.

Investir dans une observabilité plus détaillée de l’état de réservation pour opérations et support.

Ajouter davantage de contrôles de contrat automatisés sur les réponses tierces.