Les plateformes de réservation ont un problème que la plupart des logiciels n'ont pas : le produit que vous vendez n'est pas le vôtre. Vous êtes un intermédiaire entre le client et le fournisseur — l'hôtel, le transporteur, le tour-opérateur. Le travail de votre plateforme est de rendre cette intermédiation invisible.
Quand Omraty est venu nous voir, ils voulaient exactement ça : une plateforme de réservation pour les voyages Omra où les clients voient une expérience de recherche unifiée, mais en coulisses, le système tire la disponibilité et les prix de multiples fournisseurs externes, chacun avec ses propres APIs, structures tarifaires et politiques d'annulation.
Six mois et une équipe de trois personnes plus tard, la plateforme était en production.
Le vrai défi n'était pas de construire un système de réservation
Construire un flux de réservation — recherche, sélection, paiement, confirmation — c'est bien compris. La difficulté était tout ce qui se passe derrière.
Plusieurs fournisseurs aux comportements différents. Chaque API fonctionne différemment. L'une renvoie les prix en temps réel. L'autre les cache et les met à jour toutes les heures. L'une supporte la confirmation instantanée. L'autre nécessite une étape manuelle. Notre plateforme devait présenter une expérience cohérente quel que soit le fournisseur.
Trois passerelles de paiement. Stripe pour les cartes internationales. PayPal pour les clients qui le préfèrent. Mada pour les paiements domestiques saoudiens. Chaque passerelle a son propre pattern d'intégration, sa structure de webhooks et son flux de réconciliation.
Des politiques d'annulation qui devaient être transparentes. Chaque fournisseur a des fenêtres d'annulation et des pourcentages de remboursement différents. La plateforme devait les afficher clairement pendant le parcours de réservation, pas les enterrer dans les CGV.
L'architecture
On a construit une couche de services agnostique aux fournisseurs. Le moteur de réservation ne sait pas quel fournisseur traite une réservation — il travaille avec un modèle interne standardisé. Chaque fournisseur a un adaptateur qui traduit entre l'API du fournisseur et notre format interne.
Backend Laravel — gère le moteur de réservation, l'orchestration des paiements, les outils admin et toute la logique métier. Le pattern de couche de services était essentiel : BookingService travaille avec ProviderAdapterInterface, et chaque fournisseur implémente cette interface différemment.
Frontend Next.js — gère la recherche côté client, le flux de réservation et la gestion de compte. Le rendu côté serveur était important pour le SEO des pages de résultats.
La décision clé était de traiter les fournisseurs comme des plugins. Ajouter un nouveau fournisseur = écrire un nouvel adaptateur, pas changer le moteur. Ça a payé quand le client a ajouté un second fournisseur d'hôtels trois mois après le lancement.
Ce qui a rendu l'intégration difficile
Cache des tarifs et de la disponibilité
Impossible d'appeler l'API d'un fournisseur pour chaque recherche — on atteint les limites instantanément. Mais impossible de cacher les prix trop longtemps non plus, sinon les clients voient des tarifs périmés.
On a construit un système de synchronisation en arrière-plan qui tire la disponibilité selon un planning, la cache localement, et marque l'âge du cache pour que le frontend affiche « prix mis à jour il y a X minutes ». Au moment de la réservation, on fait une vérification temps réel. Si le prix a changé, le client le voit avant de confirmer — pas de surprises.
Réconciliation des paiements entre passerelles
Trois passerelles = trois formats de webhooks, trois comportements de timing pour les confirmations, trois approches pour les remboursements. On a tout normalisé via un service de paiement qui traduit les événements de chaque passerelle en états internes : en attente, confirmé, échoué, remboursé. Le moteur de réservation ne connaît que ces états — il ne touche jamais à la logique spécifique d'une passerelle.
Logique d'annulation et de remboursement
L'annulation semble simple jusqu'à ce qu'on prenne en compte les pourcentages de remboursement selon le timing, les annulations partielles, les remboursements sur le moyen de paiement d'origine, et les frais côté fournisseur qui ne correspondent pas à ce qui a été facturé au client.
On a construit un moteur d'annulation qui calcule le remboursement selon la politique du fournisseur, l'applique à la bonne transaction, et gère la comptabilité automatiquement.
Ce qu'on a appris
Cacher la complexité fournisseur derrière des services stables. Le pattern adaptateur n'est pas de l'architecture exotique — c'est de la survie. Quand un fournisseur change son API, on modifie un fichier, pas tout le flux de réservation.
Montrer les détails des politiques tôt dans le parcours client. Les règles d'annulation au moment du paiement ressemblent à des pièges. Les mêmes infos pendant la recherche ressemblent à de la transparence.
Les jobs de réconciliation gardent les finances propres. La réconciliation automatique nocturne entre nos enregistrements et ceux de chaque fournisseur attrape les écarts avant qu'ils deviennent des problèmes.
Les syncs en arrière-plan et le cache réduisent les délais. Des appels API temps réel pour chaque recherche = pages lentes. Cachez agressivement, synchronisez en arrière-plan, vérifiez au moment de l'engagement.
Le résultat
Omraty a été lancé avec une expérience de réservation unifiée, des options tarifaires et des règles d'annulation transparentes, des workflows admin pour la revue, les remboursements et les rapports.
Pour tous les détails, lisez l'étude de cas complète Omraty.
Vous construisez une plateforme avec des intégrations complexes ?
Plateformes multi-fournisseurs, orchestration de paiements et systèmes de réservation partagent le même défi : rendre la complexité invisible pour l'utilisateur final. On a écrit sur combien de temps prennent ces projets, comment on les tarifie, et à quoi ressemble la maintenance après le lancement.
Vous avez une plateforme qui doit s'intégrer avec des fournisseurs externes ? Parlons architecture →