La distribution aérienne relie les offres des compagnies aux agences et plateformes de réservation. Un standard NDC, un GDS et un agrégateur ne remplissent pas le même rôle : le premier définit un cadre d’échange, les autres donnent accès à des contenus et à des services. Cette sélection rassemble les acteurs et outils à examiner selon votre mode de vente.
Aller à une section (14)
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.
41solutions correspondantes
Air / APIAPI
Kiwi.com Tequila
Plateforme de partenariat de Kiwi.com autour de la recherche et de la distribution de trajets. Les modalités actuelles d’accès aux services B2B doivent être confirmées directement auprès de Kiwi.com.
Pour quel besoin ? Projet aérien qui veut étudier des combinaisons d’itinéraires et dispose d’un cas d’usage précis à présenter au partenaire.
Test conseillé : Demander les conditions actuelles d’éligibilité, les opérations réellement accessibles et le responsable des changements ou annulations.
En savoir plus
Faits, limites et références (1)
Documenté : L’annonce du 30 mai 2024 réserve les nouveaux partenariats Tequila à une invitation. Elle indique la poursuite des services B2B pour les partenaires existants sélectionnés.
Limite : Annonce de politique partenaire ; ni invitation ni fonctions d’un compte précis ne sont établies par sa lecture.
À demander : Votre organisation dispose-t-elle d’une invitation et d’un périmètre confirmé par écrit ?
PKFARE distingue une Flight API et un portail de réservation, avec contenu issu de GDS, interfaces directes et autres sources et opérations après émission.
Pour quel besoin ? Distributeur qui cherche à comparer plusieurs sources de prix sans développer chaque connexion séparément.
Test conseillé : Comparer un même itinéraire sur prix final, bagages, disponibilité et traitement d’un changement après réservation.
En savoir plus
Faits, limites et références (1)
Limite : Une présentation de servicing ne démontre pas les opérations ouvertes sur chaque compagnie de votre compte.
À demander : Quels contenus, marchés et changements après émission sont réellement activés pour notre contrat ?
Verteil Direct Connect est présenté comme un portail B2B pour rechercher, réserver et modifier des contenus aériens. Une API unifiée est proposée séparément pour les intégrations agences.
Pour quel besoin ? Agence qui veut comparer des contenus NDC sans intégrer séparément chaque transporteur.
Test conseillé : Chercher un itinéraire, ajouter siège et bagage, puis faire modifier et réémettre le dossier dans le canal choisi.
En savoir plus
Faits, limites et références (1)
Limite : Les nombres de compagnies affichés diffèrent entre certaines sections de la page ; demandez la liste activée et les capacités par compagnie.
À demander : Quelles compagnies, opérations d’après-vente et modalités de paiement sont actives pour notre compte ?
Une publication ATPCO décrit la mise à disposition, sur demande, de la technologie et du code source NDC Exchange pour les acteurs de la distribution.
Pour quel besoin ? Équipe aérienne qui évalue une connexion NDC mutualisée plutôt que des intégrations bilatérales isolées.
Test conseillé : Lister les compagnies, versions et opérations après-vente accessibles dans le montage envisagé.
En savoir plus
Faits, limites et références (1)
Limite : Ce document historique ne confirme pas un service commercial actuellement ouvert ni des connexions activées ; il doit être distingué d’une offre de production actuelle.
À demander : Quelle technologie, quel opérateur et quelles capacités de production sont encore proposés pour notre projet ?
New Skies est présenté comme un système de réservation, de vente et de distribution pour transporteurs. La page cite canaux directs, API, NDC, GDS, interligne et partage de codes.
Pour quel besoin ? Compagnie qui examine le remplacement ou l’évolution de son système de réservation et de ses canaux de vente.
Test conseillé : Suivre une modification de vol de la recherche au remboursement, y compris sièges et services complémentaires.
En savoir plus
Faits, limites et références (1)
Limite : Présentation d’un système de compagnie ; elle ne vaut ni ouverture automatique d’un compte agence ni disponibilité identique de chaque canal.
À demander : Quel rôle et quels canaux sont réellement prévus pour notre organisation dans le déploiement ?
À réunir : Cas fictif : une compagnie C1 et un distributeur D1. Décrire les droits de chacun ; ne pas assimiler le système de compagnie à un agrégateur ouvert à D1.
Canal
À réunir : Même offre présentée sur le site et dans un canal partenaire. Rapprocher références, prix et services inclus dans les deux parcours autorisés.
Services
À réunir : Bagage ajouté après la commande sur un seul passager. Demander la trace du service et son effet sur les documents, sans modifier les autres passagers.
Exploitation
À réunir : Changement de vol nécessitant un relais le jour du départ. Identifier l’équipe et les références utilisables à ce stade, au-delà du parcours de vente initial.
Le communiqué Sabre sur Avelo présente Radixx comme un système passagers soutenant réservation, vente et besoins opérationnels de la compagnie, avec un accord distinct pour SabreMosaic Ancillary IQ.
Pour quel besoin ? Compagnie qui évalue un système passagers capable de suivre l’offre jusqu’aux opérations après réservation.
Test conseillé : Jouer une modification d’horaire avec siège, bagage, paiement et réémission du document voyageur.
En savoir plus
Faits, limites et références (1)
Limite : Le cas Avelo ne définit pas tous les modules et accords ouverts à une autre compagnie ; PSS et optimisation des services annexes restent des périmètres à qualifier.
À demander : Quel socle et quels modules font partie du projet, et comment les opérations passagers restent-elles reliées aux ventes ?
Lecture automatique refusée (HTTP 403) · contrôle du 31/10/2026 · Portée du contrôle
Air / opérationslogiciel
IBS Software
IBS présente iFly RES pour retailing aérien, réservations, servicing et traitement des passagers, avec gestion des offres et commandes et interfaces NDC et propriétaires.
Pour quel besoin ? Transporteur qui cherche à relier commerce, exploitation et données sans confondre les produits de la gamme.
Test conseillé : Faire détailler les modules réellement retenus et suivre un changement de vol à travers leurs interfaces.
En savoir plus
Faits, limites et références (1)
Limite : Un PSS destiné à une compagnie n’est pas automatiquement un catalogue accessible à une agence ; produit, rôle et droits doivent être précisés.
À demander : Intervenons-nous sur les opérations de la compagnie ou sur la distribution, et quelles interfaces nous sont autorisées ?
Lecture automatique interrompue · contrôle du 31/10/2026 · Portée du contrôle
Air / infrastructurelogiciel
SITA
SITA distingue traitement des passagers, opérations aéroportuaires, gestion des bagages, identité et communications et échanges de données parmi ses familles de solutions.
Pour quel besoin ? Projet qui doit coordonner plusieurs acteurs d’un parcours aéroportuaire et partager un état opérationnel fiable.
Test conseillé : Simuler un incident bagage ou un changement de porte et tracer qui reçoit quelle information, à quel moment.
En savoir plus
Faits, limites et références (1)
Limite : Ces fonctions opérationnelles ne constituent pas en elles-mêmes un catalogue de billets distribuable par une agence.
À demander : Quelle étape du parcours, quels acteurs et quels identifiants notre intégration doit-elle relier ?
Offer Marketing distingue les pages airTRFX, les modules airModules reliés au moteur de réservation et les interfaces airWire destinées à afficher des offres dans les canaux numériques.
Pour quel besoin ? Équipe revenue qui veut comparer des scénarios de prix et mesurer leur effet sur conversion et marge.
Test conseillé : Comparer prix proposé, prix effectivement réservé et revenu obtenu sur un segment et une période définis.
En savoir plus
Faits, limites et références (1)
Limite : Présentation des produits marketing ; l’affichage d’une offre ne démontre pas une réservation ou une émission de billet.
À demander : Quel moteur reprend l’offre affichée, avec quelles dates, voyageurs et conditions ?
Sabre présente SabreMosaic comme une plateforme ouverte et modulaire de retailing aérien fondée sur les offres et les commandes ; le communiqué de lancement décrit une évolution des systèmes centrés sur le PNR.
Pour quel besoin ? Compagnie qui compare une trajectoire de modernisation du retailing et de la distribution.
Test conseillé : Demander une démonstration de création d’offre, commande, service associé et traitement d’une exception.
En savoir plus
Faits, limites et références (1)
Limite : Le communiqué de lancement ne définit pas le périmètre de chaque module aujourd’hui commercialisé ni son déploiement chez une compagnie. Distinguer technologie de compagnie et accès distributeur.
À demander : Quels modules, interfaces et opérations après-vente concernent notre rôle de compagnie ou de distributeur ?
La FAQ distingue les codes de réservation H1 et X1 du document de billet HR-169. Elle demande à l’agence d’indiquer le transporteur qui opère réellement le vol.
Pour quel besoin ? Agence qui doit émettre un transporteur via son environnement de distribution et connaître le rôle de l’intermédiaire.
Test conseillé : Vérifier disponibilité locale du billet, conditions du transporteur et interlocuteur pour échange ou remboursement.
En savoir plus
Faits, limites et références (1)
Limite : Le code de distribution ne désigne pas nécessairement la compagnie opérante ; les possibilités d’émission se contrôlent par marché et combinaison.
À demander : Quel transporteur opère chaque segment et le résultat Quick Check autorise-t-il cette émission dans notre marché ?
APG distingue représentation de compagnies, interline e-ticketing, services liés aux circuits de règlement et solutions de distribution NDC dans son catalogue de services.
Pour quel besoin ? Agence qui étudie l’accès à une compagnie hors de ses canaux habituels et le suivi des opérations associées.
Test conseillé : Vérifier pour un marché donné les compagnies accessibles, les règles de billetterie, le règlement et le service après vente.
En savoir plus
Faits, limites et références (1)
Limite : Les services ne constituent pas un accès uniforme à tous les transporteurs ; produit, marché, accords et responsabilités d’émission doivent être identifiés.
À demander : Quel programme et quels accords permettent notre distribution, et qui traite billet, changement et règlement ?
Trawex présente des moteurs de réservation, des API voyage et des services de développement destinés aux agences, distributeurs et entreprises travel tech.
Pour quel besoin ? Projet qui veut réunir recherche, réservation et administration dans un environnement configurable.
Test conseillé : Construire un voyage à deux prestations et vérifier prix final, documents et reprise du dossier en back-office.
En savoir plus
Faits, limites et références (1)
Limite : Le catalogue de services ne décrit pas les droits accordés sur chaque fournisseur ni les fonctions de votre réalisation. Séparez contrat logiciel, accès au contenu et travail spécifique.
À demander : Quelles opérations et sources seraient livrées dans le premier lot, avec quelles preuves de réservation et responsabilités après la vente ?
Mystifly décrit Smart Selling Platform comme une couche réunissant des contenus NDC, compagnies à bas coûts, GDS et marché de consolidation, utilisable par API ou portail agent.
Pour quel besoin ? Distributeur qui veut normaliser GDS, NDC et compagnies à bas coûts sans perdre la capacité de servir le billet.
Test conseillé : Faire démontrer recherche, vente avec service additionnel, réémission et rapprochement sur le même dossier.
En savoir plus
Faits, limites et références (1)
Limite : La normalisation des offres ne rend pas les règles et capacités après-vente identiques entre compagnies ou circuits. Un portail et une connexion API demandent aussi des recettes distinctes.
À demander : Quels contenus, documents, modifications et remboursements peut traiter notre compte sur les compagnies retenues pour le pilote ?
GO7 Orchestrated Virtual Interlining (ex-Air Black Box)
GO7 présente une orchestration de parcours multi-compagnies vendus par la compagnie, avec choix de partenaires, règles de vente, paiements et règlements. La page associe aussi des dispositifs de bagages et de protection des correspondances.
Pour quel besoin ? Compagnie ou distributeur qui souhaite proposer des correspondances construites entre réseaux distincts.
Test conseillé : Simuler un premier vol retardé et documenter protection de la correspondance, bagages et interlocuteur du voyageur.
En savoir plus
Faits, limites et références (1)
Limite : Les promesses de parcours et de bagages doivent être qualifiées pour les partenaires, itinéraires et contrats activés ; elles ne décrivent pas automatiquement chaque combinaison de vols.
À demander : Quelles correspondances et quelles perturbations sont couvertes, qui intervient et quel document explique les limites au voyageur ?
InteRES présente des intégrations GDS, NDC et connexions directes, ainsi que des solutions de transactions et de gestion d’offres et commandes aériennes.
Pour quel besoin ? Distributeur qui doit réunir plusieurs sources de contenu aérien dans un parcours cohérent.
Test conseillé : Comparer une offre aller-retour avec services additionnels depuis la recherche jusqu’au changement après réservation.
En savoir plus
Faits, limites et références (1)
Limite : Les produits répondent à des rôles différents ; une normalisation de contenu ne suffit pas à établir le traitement de chaque service annexe ou changement.
À demander : Quel produit unifie les références et états dont nous avons besoin entre recherche, réservation et après-vente ?
La matrice Iris distingue fournisseurs NDC, LCC et GDS, statut Live ou Coming soon, paiement, sièges, services annexes, après-vente et notifications OCN.
Pour quel besoin ? Vendeur de vols qui veut comparer accès au contenu, richesse des offres et opérations après vente.
Test conseillé : Tester billet, bagage, échange et annulation sur deux compagnies ; documenter chaque écart de service.
En savoir plus
Faits, limites et références (1)
Limite : Une intégration annoncée ou à venir n’est pas une fonction disponible ; les cases doivent être lues pour la compagnie et le parcours retenus.
À demander : Pouvez-vous rejouer un échange et une notification de changement avec les capacités activées sur notre connexion ?
DRCT présente une plateforme d’orchestration et distribution d’offres de compagnies vers agences, TMC, OTA et autres canaux, avec contenus NDC et directs et intégration dans des workflows agents.
Pour quel besoin ? Agence ou plateforme qui cherche un accès opérationnel à des offres NDC sans maintenir chaque connexion en direct.
Test conseillé : Demander la liste actuelle des compagnies, puis essayer émission, modification et remboursement sur un même dossier.
En savoir plus
Faits, limites et références (1)
Limite : Le périmètre dépend des contenus et opérations activés ; la présentation ne garantit pas chaque compagnie ou opération de servicing sur un compte.
À demander : Quels canaux, offres et opérations après émission sont ouverts, et où l’agent retrouve-t-il le dossier final ?
Page reçue, contenu non confirmé · contrôle du 31/10/2026 · Portée du contrôle
Air / réservationlogiciel
GO7 AeroCRS
GO7 décrit AeroCRS comme un PSS pour les compagnies, avec gestion des réservations et des passagers, contrôle des départs et connexions à des services de revenue management et de prestations annexes.
Pour quel besoin ? Transporteur qui cherche à administrer inventaire, ventes et distribution depuis une plateforme métier.
Test conseillé : Suivre une modification de vol dans l’inventaire, le canal de vente et le dossier d’un passager déjà réservé.
En savoir plus
Faits, limites et références (1)
Limite : L’offre vise l’exploitation d’une compagnie ; elle ne constitue pas à elle seule un contrat d’agence ou un agrégateur de toutes les compagnies. Le périmètre des connexions doit être confirmé.
À demander : Quels systèmes restent maîtres de l’inventaire, de l’émission, des passagers et de l’embarquement dans notre architecture ?
FLYR présente Marketplace comme une plateforme permettant aux compagnies aériennes de composer et commercialiser des offres comprenant des contenus tiers, au-delà du billet d’avion.
Pour quel besoin ? Compagnie qui souhaite élargir les produits proposés autour du trajet principal.
Test conseillé : Vérifier la présentation du prix, le responsable de l’encaissement et le service après-vente d’un produit tiers.
En savoir plus
Faits, limites et références (1)
Limite : Le nom Marketplace ne désigne pas ici une place de marché ouverte aux agences. Le périmètre décrit est celui d’une compagnie et de ses offres ; l’accès des partenaires et les opérations doivent être qualifiés.
À demander : Qui porte l’offre combinée, quels contenus sont contractés et quelles opérations de modification restent disponibles pour chaque composant ?
Réponse HTTP non concluante (520) · contrôle du 31/10/2026 · Portée du contrôle
Air / e-commercelogiciel
OpenJaw Technologies
OpenJaw présente des solutions de retailing pour compagnies couvrant offres, commandes, règlement et livraison des produits de voyage.
Pour quel besoin ? Transporteur qui cherche à présenter transport et services complémentaires dans un parcours de vente cohérent.
Test conseillé : Construire une offre avec plusieurs composants, modifier une commande puis contrôler prix, documents et service.
En savoir plus
Faits, limites et références (1)
Limite : Les modules et opérations sont à qualifier dans le projet ; une plateforme de compagnie n’est pas automatiquement un accès de distribution ouvert à une agence.
À demander : Quels produits, objets et responsabilités sont retenus pour notre organisation et notre parcours après réservation ?
FLYR présente une architecture Offer & Order modulaire, compatible avec un PSS existant, comprenant panier, offres dynamiques, services après réservation et contenus partenaires.
Pour quel besoin ? Compagnie qui veut rapprocher prévision, tarification et distribution dans ses décisions commerciales.
Test conseillé : Comparer un scénario tarifaire avant et après changement de demande, puis contrôler la traçabilité des décisions.
En savoir plus
Faits, limites et références (1)
Limite : La présentation concerne l’architecture d’une compagnie ; elle ne démontre pas un accès de distribution ouvert à une agence.
À demander : Quels modules, interfaces avec notre PSS et scénarios de reprise sont compris dans le périmètre proposé ?
Réponse HTTP non concluante (520) · contrôle du 31/10/2026 · Portée du contrôle
Air / digitallogiciel
DataLex
Datalex présente Stellex comme un système de gestion des offres et commandes et décrit une offre de retailing et de commerce électronique pour compagnies aériennes.
Pour quel besoin ? Transporteur modernisant son parcours de vente directe et les services associés à la réservation.
Test conseillé : Créer une offre avec options, confirmer la commande et traiter une modification sans perdre le détail du prix.
En savoir plus
Faits, limites et références (1)
Limite : L’offre de retailing ne définit pas les systèmes remplacés ni les fonctions effectivement activées chez un transporteur.
À demander : Quel périmètre prend en charge offres, commandes et services, avec quelles références conservées dans les systèmes existants ?
OpenAirlines présente SkyBreathe comme une plateforme d’efficacité carburant destinée à plusieurs équipes d’une compagnie aérienne.
Pour quel besoin ? Compagnie aérienne qui veut mesurer des gestes opérationnels et leur effet sur la consommation.
Test conseillé : Suivre une recommandation depuis les données de vol jusqu’au retour des équipes, en séparant effet observé et estimation.
En savoir plus
Faits, limites et références (1)
Limite : Les résultats affichés sont liés aux utilisateurs et méthodes de l’éditeur ; ils ne constituent pas une mesure environnementale universelle ni un gain garanti.
À demander : Quelles données de vol et méthodes produisent nos indicateurs, et comment un résultat est-il comparé à une base cohérente ?
Lecture automatique interrompue · contrôle du 31/10/2026 · Portée du contrôle
Air / PSSlogiciel
Amadeus Altéa
Amadeus présente Altéa Reservation pour les réservations et informations passagers et itinéraires, avec politiques de distribution et gestion des préférences client.
Pour quel besoin ? Transporteur évaluant son système central et les échanges avec ses canaux de distribution.
Test conseillé : Faire évoluer un vol et vérifier la cohérence entre inventaire, réservation, enregistrement et notifications.
En savoir plus
Faits, limites et références (1)
Limite : Altéa Reservation et la gamme de compagnie ne sont pas identiques à une API distributeur ; modules, droits et workflows doivent être précisés.
À demander : Quel produit et quelles interfaces gèrent réservation, passagers et traitement des demandes dans le périmètre proposé ?
La documentation KrisConnect de Singapore Airlines distingue des accès à son contenu NDC par outils ou partenaires et un parcours de connexion directe, avec documents d’onboarding.
Pour quel besoin ? Vendeur aérien dont la demande justifie une connexion au contenu de cette compagnie.
Test conseillé : Confirmer les marchés et partenaires éligibles, puis tester bagage, siège et changement après émission.
En savoir plus
Faits, limites et références (1)
Limite : Une présentation du programme ne vaut pas ouverture du compte ni engagement sur une fonction de votre distributeur. Les contenus, marchés et opérations doivent être validés avec le transporteur et le partenaire choisi.
À demander : Quel circuit utilisera notre agence et quelles étapes d’accord, de recette et de service après-vente sont requises pour le contenu visé ?
Qatar Airways distingue Oryx Portal, la connexion via des agrégateurs approuvés avec Oryx Link et la connexion directe à ses API NDC pour de grands partenaires.
Pour quel besoin ? Agence ou agrégateur qui veut étudier le contenu et les services de cette compagnie.
Test conseillé : Comparer un même itinéraire sur les canaux disponibles et contrôler options, règles et prise en charge après-vente.
En savoir plus
Faits, limites et références (1)
Limite : Les différentes voies n’offrent pas automatiquement les mêmes fonctions ni les mêmes conditions d’accès. Le programme et le contrat du partenaire doivent être rapprochés du parcours opérationnel retenu.
À demander : Quelles fonctions de recherche, émission et après-vente sont ouvertes par notre voie de connexion, et qui intervient lorsqu’une action manque ?
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.
Page reçue, contenu non confirmé · contrôle du 31/10/2026 · Portée du contrôle
Transport B2BAgences
Resaneo
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.
Page reçue, contenu non confirmé · contrôle du 31/10/2026 · Portée du contrôle
Air / GDSJSON API
Travelport TripServices
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 ?
Kyte décrit une API de distribution réunissant accès à des contenus LCC et NDC, services complémentaires et opérations de suivi pour vendeurs de voyages et compagnies.
Pour quel besoin ? Plateforme de voyage qui veut ajouter du contenu aérien tout en conservant la maîtrise de son expérience de vente.
Test conseillé : Vérifier un trajet aller-retour avec options, prix total, création du dossier et assistance disponible après la vente.
En savoir plus
Autres points à examiner
Approche pensée pour les vendeurs qui ne veulent pas reconstruire une connexion par compagnie.
À évaluer pour une stack aérienne légère et centrée API.
Faits, limites et références (1)
Limite : Un accès unifié ne rend pas identiques les règles des compagnies. Les opérations possibles et les contenus autorisés doivent être vérifiés par marché et par fournisseur.
À demander : Quel cas montre recherche, ajout d’un service et modification du dossier pour chaque compagnie, avec ses identifiants et responsabilités ?
API pour distribuer des contenus interline, alternatifs et intermodaux, avec protection de correspondance et gestion des commandes.
Pour quel besoin ? Compagnie ou vendeur qui souhaite proposer un trajet combiné et doit comprendre la protection offerte au voyageur lors d’une correspondance manquée.
Test conseillé : Construire un itinéraire à deux opérateurs, simuler un retard du premier segment et documenter assistance, nouvelle réservation, paiement et information client.
En savoir plus
Autres points à examiner
À considérer pour construire des trajets multi-segments au-delà du simple vol point à point.
Adapté aux compagnies, OTAs et vendeurs travel avec ambition réseau.
Faits, limites et références (1)
Documenté : Retail Connect présente des connexions de vols et services distribuées par microsite ou API, ainsi qu’une protection des correspondances.
Limite : Un parcours assemblé et une protection additionnelle doivent être distingués d’un billet interligne unique.
À demander : Qui traite chaque segment, la correspondance manquée et la demande d’assistance ?
Aucune solution ne correspond à ces critères. Essayez d’élargir votre recherche ou de modifier un filtre.
Comparer des rôles comparables
Ce que chaque famille prend réellement en charge
Ces rôles peuvent coexister chez un même acteur. Comparez d’abord la tâche et la responsabilité, puis demandez une preuve sur le produit et le contrat proposés.
Fonctions, limites et preuves à demander : Air et NDC
Rôle
Usage
Limite à examiner
Preuve utile
Standard NDC
Décrire les échanges d’offres et de commandes.
Un standard ne fournit ni inventaire ni droit d’émission à lui seul.
Version supportée et opérations effectivement mises en œuvre par chaque connexion.
GDS ou agrégateur
Réunir plusieurs contenus dans une intégration.
Le servicing peut varier selon compagnie, marché et type de tarif.
Une agence souhaite ajouter les vols à ses séjours sans créer une équipe de billetterie complète. Elle doit distinguer l’accès au contenu aérien, le droit d’émettre, le paiement et la responsabilité lors d’un changement de vol. Ces fonctions peuvent relever d’acteurs différents.
Un essai révélateur
Faire comparer un aller-retour simple, un trajet avec correspondance et un dossier modifié. Demander le prix final, les services inclus, les étapes manuelles et le délai de traitement de chaque cas.
Questions à poser aux fournisseurs
Quelles compagnies et quels types de tarifs sont réellement accessibles sur vos marchés ?
Qui émet le billet, conserve le dossier et traite une modification après départ ?
Les bagages, sièges, frais et conditions sont-ils visibles avant la confirmation ?
Que se passe-t-il lorsqu’une offre disparaît entre la recherche et la réservation ?
Consignez les réponses et demandez une démonstration fondée sur vos propres données. Les conditions exactes restent à confirmer auprès de chaque acteur.
Selon votre métier
Des parcours pour aborder cette famille de solutions
Le même fournisseur ne sera pas évalué sur les mêmes tâches selon l’équipe qui l’utilise. Ces parcours relient la catégorie à un dossier et à des mesures propres à chaque métier.
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.
Navitaire, Accelya, PROS et Resaneo interviennent à des endroits différents du parcours aérien. Situez le système de réservation, la construction de l’offre, sa diffusion et le travail de l’agence avant de comparer leurs interfaces.
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.
À utiliser avant de valider un choix de siège, puis après obtention du dossier. Cette fiche rapproche ce que l’interface a proposé avec les services réellement présents dans la réservation.
Le choix d’une interface aérienne dépend de ce que votre équipe doit vendre et de ce qu’elle doit encore pouvoir traiter après émission. Une agence qui réserve pour quelques clients n’a pas le même besoin qu’un vendeur qui orchestre des recherches automatisées sur plusieurs marchés. Décrivez les itinéraires et les exceptions avant de comparer le nombre de compagnies annoncé.
Situations, priorités et fonctions à différer
Situation
Ce qu’il faut privilégier
Ce qui peut attendre
Agence avec équipe de billetterie
Un portail agent peut suffire si les réservations, échanges et contacts de support y sont accessibles. Demandez comment un autre agent reprend un dossier créé par un collègue.
Différez l’API tant que la ressaisie ne constitue pas un problème mesuré.
Vendeur numérique multi-sources
Une API ou un agrégateur peut rapprocher plusieurs contenus. Gardez la source, les droits et les opérations possibles de chaque offre ; une interface commune ne rend pas les règles identiques.
Ne généralisez pas un échange réussi sur une compagnie à tout le contenu.
Voyagiste qui assemble un séjour
Reliez le transport au dossier de production, aux participants et aux échéances des autres prestations. Une annulation du séjour ne doit pas être traitée comme une annulation déjà confirmée du billet.
Prévoyez une reprise manuelle lorsque les décisions de production dépassent les capacités de l’interface.
Préparez une liste d’itinéraires réellement représentatifs : trajet direct, correspondance, services annexes et modification après émission. Pour chacun, distinguez ce que le système a retourné, ce que le fournisseur a confirmé et ce qui reste à faire par un agent. Le choix doit inclure cette charge de travail, même lorsque l’offre initiale semble mieux tarifée.
Un service complémentaire disparaît après changement de vol
Cas d’exercice : un dossier aérien change de vol et conserve son prix affiché, mais un siège ou un besoin particulier ne figure plus dans la preuve finale. La confirmation de l’itinéraire ne suffit pas à démontrer le maintien de toutes les prestations. L’équipe doit relire les composants et leur état, sans reprendre automatiquement les libellés de l’ancien panier.
Comparez segment, voyageur, service et références avant puis après l’opération. Une demande particulière enregistrée n’est pas une réponse de compagnie. Distinguez ce qui est conservé, remplacé, refusé ou encore en attente. La nouvelle information au voyageur décrit les changements effectivement confirmés et l’interlocuteur qui doit résoudre le point restant.
Transport
Preuve à retrouver : Segments et statut du dossier modifié.
Retrouver la preuve du nouvel itinéraire.
Service
Preuve à retrouver : Référence du siège ou composant.
Vérifier le résultat, pas seulement l’ancien montant.
Demande
Preuve à retrouver : Réponse de compagnie et contexte.
Séparer signalement et prestation acceptée.
Décider et transmettre
Clôturer lorsque les composants attendus sont rapprochés ou explicitement suivis comme manquants. Garder la réponse fournisseur et la communication au voyageur ; un total inchangé ne clôture pas l’écart.
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 comparer les solutions de cette famille ?
Définissez d’abord votre usage prioritaire, puis comparez les acteurs sur les points suivants : Compagnies accessibles, émission des billets, modifications, annulations, services additionnels, devises et assistance après-vente. Demandez qui porte les accréditations et qui traite les incidents de réservation. Faites chiffrer le même trajet avec et sans bagage, puis une modification après émission : conservez les références du dossier, du billet et des services, ainsi que le montant restant à régler.
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.
Une réservation de vol confirme-t-elle l’émission ?
Commande, référence de réservation et billet sont des objets à rapprocher. Demandez quel état confirme l’émission, où retrouver les numéros de billet et qui intervient si le paiement aboutit sans retour d’émission. Vérifiez l’état du dossier avant de permettre une nouvelle tentative.
NDC signifie-t-il accès à toutes les compagnies ?
Le standard décrit les échanges ; l’accès dépend du partenaire et du compte. Comparez compagnies activées, marchés, tarifs, services annexes et après-vente. Une recherche disponible ne prouve pas que modification et remboursement sont également ouverts.
Une API NDC remplace-t-elle mon outil de billetterie ?
Vérifiez quelles opérations du poste sont couvertes : émission, documents, modification et reprise après réponse manquante. Faites retrouver une commande et son billet par le compte prévu, puis identifiez les actes qui passent encore par un agent. Un accès NDC ne démontre pas à lui seul que l’ensemble de ce travail est automatisé.
Comment comparer deux sources aériennes sans fausser le prix ?
Alignez marché, devise, voyageurs, segments, bagages et conditions, puis relisez l’offre avant l’acte autorisé. Dans le cas fictif de la grille, le passage de 565 € à 585 € doit rester visible avec sa version et l’accord obtenu. Un prix seul ne prouve ni disponibilité ni équivalence des services.
Une confirmation de vol conserve-t-elle tous les services associés ?
Il faut relire chaque composant après le changement. Une confirmation d’itinéraire ne démontre pas le maintien d’un siège ou d’une demande particulière.
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.
