Réserver un autocar en ligne demande bien plus qu’un formulaire. Le prix dépend du trajet, de sa durée, des péages, du nombre de passagers, du type de voyage et des règles commerciales propres à l’opérateur.
Dawap a fait évoluer Saybus par générations successives entre juillet 2019 et février 2025. Le moteur s’est progressivement enrichi autour de ViaMichelin, de calculateurs spécialisés, de la commande et de Stripe.
Le cœur du projet relève de l’intégration cartographique et géolocalisée : transformer une adresse et un besoin de voyage en offre réservable.
1. Présentation du client
Comprendre le contexte business avant la solution
Saybus propose plusieurs formes de trajet : aller simple, aller-retour, transfert, circuit et voyage en plusieurs étapes. Chacune possède son formulaire, ses règles de validation et son calcul.
Le produit doit enchaîner localisation, interrogation de ViaMichelin, calcul kilométrique, durée, péages, tarification, création de commande puis paiement.
Le code sépare ces responsabilités afin que les règles de prix puissent évoluer sans réécrire les échanges avec les services externes.
2. Méthode projet Dawap
Analyse, priorisation, delivery agile et sécurisation du run
Chaque type de trajet dispose d’un trio collecte, calcul et validation. Le service ViaMichelin fournit la distance routière, le temps de conduite et les péages ; le domaine applique ensuite ses coefficients et règles commerciales.
La commande conserve l’offre choisie et les informations du voyage. Stripe reçoit uniquement ce qui lui est nécessaire pour créer la session de paiement et rattacher la transaction à la commande.
Les versions successives ont consolidé le découpage métier, les parcours client, le back-office, les statistiques et la couverture de tests.
3. Le défi du devis transport
Calculer une prestation qui dépend du trajet réel
Deux adresses ne suffisent pas à déterminer un prix. Il faut connaître la distance routière, la durée, les péages, la capacité demandée et la forme du voyage.
Saybus devait produire ce calcul assez tôt pour présenter une offre, tout en gardant les règles ajustables depuis le produit.
La réponse a été de séparer la donnée d’itinéraire, fournie par l’API, de la tarification décidée par le métier.
4. Quatre générations de produit
Une continuité de 2019 à 2025
Bus Booking a connu quatre générations qui retracent les étapes du produit et l’évolution de ses usages.
La première version démarre en juillet 2019 ; la transformation se poursuit jusqu’en février 2025. Les générations intermédiaires font évoluer l’architecture autant que les écrans.
Cette profondeur raconte un produit maintenu et transformé, pas une démonstration ponctuelle.
5. ViaMichelin dans le parcours
Distance, durée et péages à partir des coordonnées
Le client ViaMichelin construit une requête à partir des coordonnées de départ et d’arrivée. Il lit ensuite la distance de conduite, le temps de parcours et le coût de péage renvoyés par le service.
Pour les voyages en plusieurs étapes, le moteur additionne les kilomètres de chaque segment. Il peut également calculer une heure d’arrivée à partir de la durée obtenue.
Ces données alimentent le domaine sans lui déléguer la décision tarifaire.
6. Des calculateurs par voyage
Aller simple, aller-retour, transfert, circuit et multi-étapes
Des services dédiés prennent en charge chaque forme de voyage. Les parcours partagent une base commune mais conservent leurs paramètres et validations spécifiques.
La collecte rassemble les données utiles, le calcul applique les règles et la validation contrôle que le devis peut être proposé.
Cette structure évite qu’une exception propre à un circuit touristique perturbe un transfert simple.
7. De l’offre à la commande
Conserver le contexte de la réservation
Une fois le calcul accepté, l’offre porte le prix et le descriptif du voyage. La commande lui associe le client, les coordonnées de facturation et les informations opérationnelles.
Les espaces client permettent de retrouver les réservations. Le back-office dispose de vues de suivi et de statistiques sur les offres et commandes.
Le passage au paiement s’effectue donc avec une commande déjà identifiée et explicable.
8. Le paiement Stripe
Créer, rattacher et rembourser une transaction
Le service Stripe crée une session pour la carte ou le prélèvement SEPA. Il transmet le montant TTC, la devise, l’adresse e-mail et l’identifiant de commande dans les métadonnées.
Les URL de succès et d’annulation ramènent l’utilisateur vers le bon parcours Saybus. Un journal d’événements et un subscriber traitent les notifications Stripe.
Le service prévoit également le remboursement d’un paiement Stripe identifié, créant une continuité entre encaissement et service après-vente.
9. Scénario de réservation
Un aller-retour transformé en commande payée
Le voyageur renseigne ses lieux, ses dates et le nombre de passagers. Saybus résout les étapes, interroge ViaMichelin puis récupère distance, durée et péages.
Le calculateur aller-retour applique les règles configurées et produit une offre. Après validation des informations de facturation, l’application crée la commande et ouvre la session Stripe associée.
La notification de paiement rejoint ensuite le journal financier, tandis que le client et l’équipe retrouvent la même réservation dans leurs espaces respectifs.
10. Back-office et exploitation
Piloter prix, commandes et communication
Le produit comprend des réglages de coefficients, des coûts spécifiques aux circuits, des jours indisponibles et des délais minimums de réservation.
Des commandes envoient les rappels avant le voyage. Les services d’e-mail distinguent client, autocariste et équipe Saybus afin d’adresser la bonne information à chaque acteur.
Les statistiques de commandes complètent la chaîne transactionnelle par une lecture opérationnelle du service.
11. Ce que Saybus démontre
Une architecture API au service d’un métier concret
Saybus démontre la capacité de Dawap à articuler une API routière, un moteur de calcul, un tunnel de commande et un prestataire de paiement.
La fiche développement web Saybus présente l’expérience de réservation ; celle-ci documente le moteur et ses intégrations.
Découvrez aussi nos projets d’intégration API pour d’autres architectures métier.
12. Conclusion
Pourquoi ce projet donne envie de travailler avec Dawap
Saybus prouve qu’une intégration API réussie se mesure à la continuité du parcours : une distance devient un prix, le prix une offre, l’offre une commande et la commande un paiement traçable.
Le projet conserve les particularités de chaque source derrière des services dédiés et laisse le domaine décider des règles de réservation.
Dawap mobilise cette expérience sur les projets d’API cartographiques et géolocalisées et d’intégration paiement.
