Interopérabilité et qualité
Un langage commun, des preuves à demander.
Huit repères pour comprendre les standards rencontrés dans la travel tech. Pour chaque sujet, distinguez le cadre publié, les capacités du fournisseur et le résultat obtenu dans votre propre parcours.
Choisir le repère utile
| Question | Document | Ce qu’il permet de conclure |
|---|---|---|
| Que décrit le cadre ? | Référence et version du standard | Sens des objets, champs et opérations prévus. |
| À quoi avons-nous accès ? | Documentation et engagement du partenaire | Périmètre activé pour votre contrat et votre marché. |
| Que fonctionne-t-il dans notre cas ? | Recette datée et reproductible | Résultat observé, limites et anomalies à résoudre. |
Repère documenté
IATA NDC
Échanges d’offres et de commandes aériennes.
Cadre publié : L’IATA décrit NDC comme un format d’échange fondé sur les processus Offer et Order.
Limite de lecture : Un standard ne donne pas automatiquement accès à toutes les compagnies ni à toutes les opérations après-vente.
Preuve à demander : Version, compagnies activées, marché et recette de modification ou remboursement.
Référence officielle · Consultée le
Distribution aérienne : GDS, NDC et agrégateurs →Repère documenté
OCTO
Interfaces pour distribuer visites, attractions et activités.
Cadre publié : La documentation publique organise les échanges autour des produits, disponibilités et réservations.
Limite de lecture : La présence du standard ne confirme pas chaque capacité ni son activation chez le fournisseur.
Preuve à demander : Fonctions déclarées, statut de réservation, capacité et scénario d’annulation.
Référence officielle · Consultée le
Distribution des activités : billetterie et connectivité →Repère documenté
GTFS Schedule et Realtime
Description des réseaux de transport et actualisation de leur service.
Cadre publié : Schedule décrit l’offre planifiée ; Realtime fournit notamment mises à jour de trajets, alertes et positions.
Limite de lecture : Un horaire n’est pas une réservation ni une garantie de correspondance.
Preuve à demander : Calendrier réel du jour, version du flux, fuseau et comportement sans temps réel.
Référence officielle · Consultée le
GTFS : relier une destination aux transports disponibles →Repère documenté
ISO 4217 — codes monétaires
Identification de la devise dans les échanges financiers.
Cadre publié : SIX est l’agence de maintenance des codes monétaires ISO 4217.
Limite de lecture : Le code ne fixe ni taux de change ni convention d’unité de toutes les API de paiement.
Preuve à demander : Devise, unité attendue, précision, règle d’arrondi et documentation de l’opération.
Référence officielle · Consultée le
Montants et devises : contrôler les unités mineures des API →Repère documenté
IANA — base des fuseaux horaires
Relier une heure locale aux règles du lieu et de la date.
Cadre publié : La base IANA suit les changements de décalage UTC, d’heure d’été et de frontières de fuseaux.
Limite de lecture : Un décalage fixe comme UTC+1 ne décrit pas toutes les dates d’une destination.
Preuve à demander : Zone utilisée, date locale, instant UTC et tests autour des changements d’heure.
Référence officielle · Consultée le
Horaires et fuseaux horaires : fiabiliser un itinéraire international →Repère documenté
OpenAPI
Description structurée d’une interface HTTP.
Cadre publié : La spécification permet de décrire opérations, paramètres, réponses et schémas d’une API HTTP.
Limite de lecture : Un schéma valide ne prouve pas la couverture commerciale, la disponibilité ou la qualité du support.
Preuve à demander : Version du contrat d’interface, erreurs, exemples, tests et fonctions autorisées.
Référence officielle · Consultée le
Versions et dépréciations d’API : organiser une migration maîtrisée →Repère documenté
WCAG 2.2
Critères de référence pour l’accessibilité des contenus web.
Cadre publié : La recommandation W3C organise des critères vérifiables avec des niveaux A, AA et AAA.
Limite de lecture : Une vérification automatique seule ne démontre pas la conformité du parcours complet.
Preuve à demander : Essais clavier, focus, formulaires, erreurs et composants externes du parcours.
Référence officielle · Consultée le
Accessibilité numérique tourisme : parcours et réservation →Repère documenté
Schema.org
Vocabulaire de description des entités et contenus publiés.
Cadre publié : Schema.org maintient un vocabulaire partagé de données structurées.
Limite de lecture : Le balisage ne garantit ni affichage enrichi dans un moteur ni citation par un assistant.
Preuve à demander : Entité, URL canonique, faits visibles, relations et cohérence avec le contenu rendu.
Référence officielle · Consultée le
SEO et GEO tourisme 2026 : contenus utiles et citables →Une fiche d’interface à remettre à l’équipe
Notez le standard, sa version, le partenaire, le produit et les opérations réellement activées. Ajoutez les identifiants, unités, fuseaux et statuts qui doivent traverser les outils. Pour chaque inconnue, indiquez qui répond et ce qui reste suspendu. Ne transformez pas une valeur absente en une promesse commerciale.
Dictionnaire des montants · Contrôler un flux GTFS · Dossiers documentés
Questions fréquentes
Un standard prouve-t-il qu’une intégration fonctionne ?
Il donne un cadre commun. Il faut encore confirmer version, fonctions activées, droits d’accès, données de votre marché et résultat de recette.
Comment choisir la version à utiliser ?
Choisissez celle que votre partenaire supporte pour votre compte. Conservez sa documentation, les dates de dépréciation et les résultats de test ; la dernière version publiée n’est pas forcément déjà ouverte chez chaque acteur.
Comment comparer deux fournisseurs qui annoncent le même standard ?
Faites exécuter les mêmes opérations et cas d’exception. Comparez les champs effectivement reçus, les états après réservation, les fonctions absentes et les procédures de support.