595 solutions pour construire votre écosystème B2B tourisme.
Distribution, hôtellerie, restauration, activités, mobilité, paiement, data, logiciels, voyages d’affaires et création web : filtrez selon votre besoin et votre métier. Chaque fiche résume l’usage principal de la solution, les profils auxquels elle peut convenir et les points à examiner avant d’aller plus loin.
Répertoire opérationnel
Trouver le bon partenaire selon le produit, le profil et le niveau d’intégration.
Commencez par un seul besoin prioritaire, puis affinez avec votre profil et le mode d’accès souhaité. Une liste courte de trois à cinq acteurs est généralement plus utile qu’une longue sélection impossible à comparer sérieusement.
434solutions correspondantes
Tourisme durabledata
FairMoove Solutions
Services de mesure et d’accompagnement RSE du tourisme, notamment évaluation FairScore et formation.
Pour quel besoin ? Structurer les données et actions d’une démarche de progrès d’un établissement.
Test conseillé : Demander le périmètre d’un score, sa méthode et les justificatifs d’une action suivie.
En savoir plus
Faits, limites et références (1)
Limite : Un score doit être daté et relié à son objet ; il ne prouve pas une conformité juridique générale.
À demander : Comment démontrer ce fonctionnement sur notre scénario et notre périmètre ?
Standard de distribution basé sur les offres et commandes, utile pour accéder à du contenu aérien riche via compagnies, GDS ou agrégateurs.
Pour quel besoin ? Équipe de distribution qui doit comprendre le rôle du standard avant de comparer les accès offerts par une compagnie, un GDS ou un agrégateur.
Test conseillé : Demander au partenaire choisi de jouer recherche, offre, commande, modification et service sur une compagnie et une version de messages précis.
En savoir plus
Autres points à examiner
Point de départ pour comprendre NDC, Offer/Order et les exigences de distribution aérienne.
À combiner avec un agrégateur ou un GDS si l’équipe ne veut pas gérer chaque compagnie une par une.
Faits, limites et références (1)
Documenté : NDC définit un cadre d’échange fondé sur les offres et commandes, accessible aux acteurs de la distribution.
Limite : La spécification ne fournit ni inventaire ni autorisation d’émettre des billets.
À demander : Quelle version est déployée, avec quelles opérations et quels partenaires ?
Portail désormais consacré aux API Enterprise Amadeus. L’annonce officielle indique le retrait du portail Self-Service au 17 juillet 2026 ; les anciens tutoriels ne constituent plus une voie d’accès à cette offre.
Pour quel besoin ? Équipe qui doit examiner un accès Enterprise ou organiser la reprise d’une intégration historique, avec un contrat et un périmètre confirmés.
Test conseillé : Faire confirmer le produit et l’accès actuels, puis tester recherche, réservation, émission et service sur les opérations effectivement autorisées.
En savoir plus
Autres points à examiner
Identifier le produit, la documentation actuelle et le mode d’accès avant de prévoir un prototype.
Faire confirmer l’ouverture du compte, les opérations disponibles et le passage à la production.
Faits, limites et références (1)
Documenté : Le portail présente les API Enterprise, avec demande d’accès et sandbox Enterprise. L’accès aux anciens exemples Self-Service ne démontre pas l’ouverture d’un produit Enterprise à une nouvelle entreprise.
Limite : Portail de gamme et d’accès ; opérations, contenus, contrat et passage en production restent à confirmer pour l’entreprise.
À demander : Quelle preuve relie le prototype autorisé à notre futur parcours d’émission et d’après-vente ?
À réunir : Cas fictif : prototype hôtel H7, projet de vente aérienne A7. Identifier séparément les produits et accès nécessaires ; un essai hôtelier ne couvre pas le besoin aérien.
Environnement
À réunir : Compte, autorisation et documentation du produit retenu. Distinguer environnement de test, contenu de démonstration et service de production accepté.
Engagement
À réunir : Recherche, commande et document d’émission attendus pour A7. Demander une preuve à chaque étape ; un résultat de recherche ne constitue pas un billet.
Relais
À réunir : Dossier ouvert, référence et acteur chargé d’une modification. Vérifier qui reprend le suivi et avec quel accès avant de généraliser le prototype.
Resaneo présente une interface dédiée aux agences, avec vols, rail, services additionnels et contenus de transporteurs accessibles via NDC.
Pour quel besoin ? Agence qui souhaite comparer des itinéraires et garder la réservation et son traitement dans un même environnement professionnel.
Test conseillé : Rechercher un aller-retour avec correspondance, vérifier les règles tarifaires puis simuler une modification et une annulation du dossier.
En savoir plus
Autres points à examiner
Utile pour agences non IATA ou agences qui veulent gagner du temps sur la vente transport.
Met en avant remontée comptable automatisée, cotations groupes, offre rail et transporteurs accessibles via NDC.
Faits, limites et références (1)
Limite : La présence d’un transporteur ou service doit être vérifiée pour le dossier et le compte concernés.
À demander : Qui émet, modifie et assiste le dossier choisi, avec quelles références de suivi ?
Écosystème Sabre pour agences connectées et partenaires développeurs, avec accès au portefeuille d’APIs et à des solutions tierces.
Pour quel besoin ? Éditeur ou agence qui veut relier un outil métier à des services Sabre et identifier les intégrateurs adaptés à son marché.
Test conseillé : Choisir une opération réelle, vérifier accès, documentation, limites et responsabilité du support avant de construire un parcours de réservation complet.
En savoir plus
Autres points à examiner
À regarder si l’agence travaille déjà dans l’environnement Sabre.
Le Partner Hub aide à trouver des partenaires technologiques compatibles.
Faits, limites et références (1)
Documenté : La collection NDC distingue recherche, tarification, création de commande et fulfillment. Elle décrit aussi des parcours d’après-vente, dont revalidation et annulation, selon l’état de la commande.
Limite : Collection NDC citée ; les droits du compte, compagnies et opérations réellement ouverts doivent être établis séparément.
À demander : Comment distinguer une commande créée d’un dossier effectivement émis sur notre compagnie cible ?
À réunir : Cas fictif : O71 créée, sans document d’émission retrouvé. Conserver cet état sans annoncer le billet comme disponible ; rechercher le résultat du fulfillment.
Offre
À réunir : Offre sélectionnée V1 puis tarif relu V2. Comparer prix, bagages et conditions avant l’engagement, même si le montant n’a pas changé.
Après-vente
À réunir : Annulation demandée avant émission, puis cas après émission. Demander le parcours autorisé dans chacun des deux états, avec la réponse et les références obtenues.
Reprise
À réunir : Réponse perdue après une action sur O71. Retrouver la commande et ses documents avant de répéter une opération ou de créer un autre dossier.
Le guide distingue le cache de recherche (12 minutes pour GDS, 34 pour NDC) et la session workbench (30 minutes, avec commit avant expiration). Dans le parcours standard de réservation retenue, commit et émission restent distincts ; les autres parcours ont leurs règles propres.
Pour quel besoin ? Équipe produit qui veut construire un parcours distribuant plusieurs types de contenu tout en gardant la maîtrise de l’interface.
Test conseillé : Sur une compagnie et un hébergement accessibles, rejouer recherche, prix, réservation, modification et annulation en conservant les références de chaque étape.
En savoir plus
Autres points à examiner
Convient aux agences et plateformes qui veulent un socle GDS/NDC structuré.
Les workflows de réservation imposent des délais et états de session à respecter.
Faits, limites et références (2)
Limite : Workflow Flights : ne pas généraliser une procédure d’émission à tous les contenus GDS et NDC.
À demander : Quelle preuve distingue la réservation retenue du titre utilisable ?
Après Search, la lecture autonome vise un seul produit par appel via productIDs. Pour une réservation existante, le guide exige un dossier créé par TripServices avec un tarif et un fare basis valides ; il exclut le split ticketing de ce parcours.
Portée : Périmètre TripServices Air v11 documenté par Travelport, consulté le 22 octobre 2026. Les limites décrites ne valent pas pour tous les produits Travelport ni pour toutes les opérations d’un transporteur. Une règle récupérée ne prouve pas l’exécution d’un échange ou d’un remboursement.
Contrôles proposés pour ce périmètre
Cache Search GDS
À réunir : Le guide publie une fenêtre de 12 minutes pour les requêtes de référence issues de la recherche GDS.. Noter l’heure de recherche ; ne pas utiliser la durée du workbench à la place.
Cache Search NDC
À réunir : La fenêtre publiée pour la recherche NDC est de 34 minutes.. Conserver le type de contenu avec la référence.
Session
À réunir : Identifiant et heure de création. Suivre l’expiration du workbench.
Commit
À réunir : Résultat et locator. Rechercher la réservation après une réponse perdue.
Émission
À réunir : Documents et échéance retournés. Vérifier le parcours applicable au contenu.
Reprise
À réunir : État courant du dossier. Éviter une nouvelle réservation sans rapprochement.
Les bagages inclus dans le billet et ceux achetés en supplément ne figurent pas au même endroit dans la commande. Chaque service est associé à des segment_ids et passenger_ids.
Pour quel besoin ? Plateforme qui souhaite intégrer une offre aérienne dans son propre parcours client.
Test conseillé : Créer une commande, ajouter un bagage puis simuler changement ou annulation en vérifiant les actions possibles selon le transporteur.
En savoir plus
Autres points à examiner
Intéressant pour startups, néobanques, conciergeries et OTAs qui veulent lancer vite.
Peut utiliser son accréditation et son autorité de billetterie selon le montage.
Faits, limites et références (12)
Limite : Disponibilité des bagages additionnels selon compagnie et offre. Le document EMD n’est pas garanti pour chaque réservation.
À demander : Vérifier les voyageurs et les vols couverts avant de présenter le supplément comme valable sur tout le voyage.
expires_at donne l’expiration de l’offre ; une nouvelle lecture ne garantit pas sa disponibilité à la réservation. total_amount inclut les taxes pour les voyageurs, mais exclut les services supplémentaires. Une ventilation tax_breakdown vide ou partielle ne permet pas de reconstituer le total.
Portée : Champs de l’offre et limites de la ventilation des taxes ; les règles de réservation, de services et d’après-vente doivent aussi être contrôlées pour le trajet retenu.
Les jetons de test et de production accèdent à des ressources séparées. Duffel Airways simule les parcours, avec des horaires et prix artificiels ; les sandboxes des compagnies externes ont leurs propres limites.
Portée : Un résultat en simulation ne démontre ni disponibilité commerciale ni couverture après-vente d’une compagnie réelle.
order.airline_initiated_change_detected signale un changement initié par la compagnie. Le contrôle emploie X-Duffel-Signature et un secret ; ce secret n’est montré qu’à la création du webhook. Duffel indique d’utiliser idempotency_key pour l’unicité des événements rejoués.
Portée : Comportement décrit par Duffel, à ne pas généraliser aux webhooks de tous les fournisseurs.
Un siège sans available_services, représenté par une liste vide, est indisponible dans ce parcours. Un même siège peut avoir un service et un prix différents selon le passenger_id. Dans services, chaque siège se transmet avec son id de service et quantity égal à 1. Le paiement inclut le prix de l’offre et des services choisis. La réponse de commande contient les sièges dans services et leur désignation dans seat pour le passager du segment.
Portée : Parcours Duffel documenté, sans extension à toutes les compagnies ni garantie de conservation du siège après changement de vol ou d’appareil.
booking_references contient la référence principale et les références supplémentaires des compagnies du dossier. Chaque entrée réunit booking_reference et carrier, la compagnie ayant émis cette référence. La référence propre au transporteur peut servir à l’enregistrement et au choix de siège auprès de celui-ci. Le champ historique booking_reference reste la référence principale.
Portée : Évolution annoncée le 7 août 2025, vérifiée le 22 octobre 2026. La liste de PNR ne constitue pas une carte d’embarquement.
requires_instant_payment: false indique qu’une offre peut être retenue sans paiement immédiat. price_guarantee_expires_at indique la fin de garantie du prix. Une valeur null signifie que le prix peut changer pendant la retenue. Sans paiement avant payment_required_by, la compagnie libère la place et awaiting_payment passe à false. Relire la commande donne le prix courant ; un montant devenu ancien peut produire l’erreur price_changed.
Portée : Exemple fictif : prix garanti jusqu’à 16 h et paiement exigé avant 18 h, dans le même fuseau. À 17 h, la place peut encore être retenue sans que le prix de 15 h soit garanti. Ces heures illustrent la distinction ; elles ne sont pas des délais Duffel.
Places distingue type: city et type: airport. airports est fourni pour une ville ; city décrit l’aire métropolitaine d’un aéroport lorsqu’IATA l’y rattache. Le schéma illustre iata_code par LHR (aéroport), iata_city_code par LON (ville), icao_code par EGLL et iata_country_code par GB. time_zone utilise un nom de la base tz ; latitude, longitude et time_zone peuvent être null. Le paramètre rad de /places/suggestions est exprimé en mètres.
Portée : Schéma Duffel consulté le 22 octobre 2026. Les exemples de code expliquent les champs ; l’aéroport effectivement réservé doit être retrouvé dans les segments du voyage.
ratelimit-limit donne le plafond de la période et ratelimit-remaining le nombre restant. Le code rate_limit_exceeded demande d’attendre le moment indiqué par ratelimit-reset, exprimé comme une date HTTP. Le tableau Duffel demande de ne pas réessayer les erreurs serveur 500 et 502 et de transmettre le request_id au support.
Portée : Comportement Duffel documenté. Aucune limite de compte ni autorisation de nouvelle réservation ne découle de cet exemple ; une écriture à résultat incertain doit être rapprochée séparément.
Contrôles proposés pour ce périmètre
Périmètre du supplément
À réunir : Chaque service est associé à des segment_ids et passenger_ids.. Vérifier les voyageurs et les vols couverts avant de présenter le supplément comme valable sur tout le voyage.
Après réservation
À réunir : Les bagages supplémentaires réservés figurent dans services, sans être ajoutés à slices[].segments[].passengers[].baggages[].. Réunir les deux informations pour établir la franchise totale du voyageur.
Quantité
À réunir : Le service disponible expose maximum_quantity ; le service réservé expose quantity.. Distinguer plafond proposé et quantité réellement achetée.
Document
À réunir : Certaines compagnies émettent un document EMD ; Duffel le décrit par electronic_miscellaneous_document_associated lorsqu’il est disponible.. Conserver aussi les documents de services, distincts du billet électronique.
La documentation distingue expiration de la garantie de prix, échéance de paiement et statut de paiement. Une commande non payée peut être libérée à son échéance.
Garantie de prix
Conserver price_guarantee_expires_at et le prix relu.
Échéance de paiement
Conserver payment_required_by avec son fuseau.
Preuve d’émission
Rapprocher documents et paiement ; awaiting_payment seul ne suffit pas.
Scénario proposé : Rejouer une commande dont la garantie de prix expire avant le délai de paiement ; comparer la nouvelle offre avant toute décision.
Portée : Fonction de mise en attente variable selon la compagnie ; ce contrôle documentaire n’émet aucun billet.
Contrôles éditoriaux proposés, à rejouer sur votre périmètre ; aucun appel à une API fournisseur ni test de réservation effectué.
AirGateway distingue un sandbox relié aux environnements de test des fournisseurs et une plateforme LIVE accessible après certification.
Pour quel besoin ? OTA, outil de réservation d’entreprise ou consolideur qui souhaite ajouter du contenu aérien direct sans maintenir autant de connexions propres.
Test conseillé : Comparer la même offre via le canal existant et l’API, puis vérifier émission, changement, remboursement et reprise du dossier dans le poste agent.
En savoir plus
Autres points à examiner
Approche utile pour agences IATA, TMC, OBT et consolidateurs.
Passage sandbox puis certification avant production.
Faits, limites et références (1)
Limite : Présentation de l’API ; compagnie, marché, opération et moyen de paiement ouverts en production dépendent du partenariat confirmé.
À demander : La certification confirme-t-elle toutes les compagnies ?
La fonction Reprice de BookingPad compare les données actualisées de la commande avant émission. Le besoin de revalidation manuelle dépend du fournisseur.
Ancienne offre
Archiver prix, tarif et bagages présentés.
Offre réévaluée
Comparer les conditions modifiées, pas seulement le total.
Décision du conseiller
Dater l’acceptation ou le refus du changement.
Scénario proposé : Faire examiner une offre dont les bagages changent lors de la revalidation, même si le prix reste identique.
Portée : Présentation de BookingPad ; ne prouve pas un comportement identique de tous les transporteurs ou de tous les endpoints.
Contrôles éditoriaux proposés, à rejouer sur votre périmètre ; aucun appel à une API fournisseur ni test de réservation effectué.
Travelfusion présente tfFlight API pour recherche, choix, réservation, services complémentaires, paiement et traitement des dossiers aériens dans une plateforme de distribution.
Pour quel besoin ? Distributeur ayant besoin de comparer plusieurs sources aériennes et de garder un traitement cohérent après la vente.
Test conseillé : Tester un tarif avec bagage, un changement puis une annulation sur deux compagnies de modèles différents ; relever réponses, coûts et étapes qui exigent une intervention.
En savoir plus
Autres points à examiner
À regarder pour accès large aux low-cost et compagnies connectées en direct.
Bon candidat pour comparateurs, OTAs et corporate travel.
Faits, limites et références (1)
Limite : La présence d’une opération dans la présentation ne garantit pas sa disponibilité pour chaque compagnie, contenu ou compte. Le périmètre de servicing doit être testé avec les accès réellement accordés.
À demander : Quelles opérations de modification, annulation et remboursement sont disponibles pour chaque contenu retenu, avec quelles références et limites ?
La Smart Selling Platform présente une API normalisant NDC, LCC, GDS et marketplace de consolidateurs, avec gestion des offres et commandes et automatisation après réservation.
Pour quel besoin ? Vendeur de vols qui veut rapprocher des offres issues de circuits de distribution différents dans un même processus.
Test conseillé : Comparer prix final et bagages sur un trajet, puis suivre émission, échange et remboursement avec les mêmes identifiants de dossier.
En savoir plus
Autres points à examiner
Utile si la priorité est la normalisation d’un contenu aérien fragmenté.
Inclut portail agent, API, règles de sourcing et opérations post-booking.
Faits, limites et références (1)
Limite : La normalisation ne prouve pas une égalité de capacités entre sources ; l’après-vente doit être contrôlé par contenu.
À demander : Quelles opérations de modification, séparation de dossier et remboursement sont disponibles pour chaque source retenue ?
L’existence d’une documentation de vols ne prouve pas que votre entreprise peut ouvrir un compte, émettre un billet ou traiter une modification. Comparez d’abord le mode d’accès et les responsabilités après la vente.
Trois API hôtelières peuvent fournir des offres tout en imposant des étapes et conditions d’accès différentes. Le bon comparatif suit une même chambre, une même occupation et le même service après réservation.
Une réservation intégrée peut exister dans un modèle affilié. À l’inverse, un standard ouvert ne donne aucun catalogue commercial : niveau d’accès, lieu de transaction et responsabilité doivent être lus séparément.
Une fiche hôtel fiable relie un établissement identifié, des chambres décrites précisément et des conditions qui restent attachées au tarif choisi. Voici les champs à contrôler avant d’importer ou de publier une offre.
La description d’une activité doit permettre de choisir le bon produit et de rejoindre le bon accueil. Contrôlez ensemble option, horaire, participants, inclusions et document d’accès.
Un itinéraire aérien devient comparable quand horaires, aéroports, voyageurs, bagages et conditions appartiennent à la même offre. Cette fiche aide à vérifier ce que le client accepte réellement avant de payer.
Le répertoire aide à identifier le marché. La décision finale doit rester fondée sur vos cas d’usage, vos responsabilités et vos conditions contractuelles.
Comment choisir une solution B2B pour le tourisme ?
Définissez un besoin prioritaire, filtrez par métier et mode d’accès, puis retenez trois à cinq acteurs. Comparez-les sur un même scénario en intégrant les coûts de mise en place, de paiement, de support, de maintenance et de sortie.
Combien de solutions faut-il présélectionner ?
Une présélection de trois à cinq solutions permet généralement d’organiser des démonstrations approfondies sans diluer la comparaison. Utilisez le même scénario, les mêmes volumes et les mêmes cas d’après-vente pour chaque fournisseur.
La présence dans le répertoire vaut-elle recommandation ?
Non. Le répertoire est un outil de recherche éditorial. La présence d’un acteur ne vaut ni certification ni recommandation commerciale. Les fonctionnalités, tarifs, pays couverts et conditions d’accès doivent être confirmés auprès de la source officielle.
Examiner un produit sur pièces
Des dossiers pour préparer vos essais
Les fonctions documentées sont séparées des contrôles que nous proposons. Chaque dossier conserve ses sources et sa date de consultation.
