Épisode 4 de la série “Mon NDC est meilleur que le tien”

Dans les épisodes précédents, on a parlé d’outils, d’agents, de travel managers. Aujourd’hui, on ouvre le capot. Parce que derrière les promesses commerciales, il y a une réalité technique que peu de gens comprennent vraiment et qui explique beaucoup de frustrations sur le terrain.

Pourquoi existe-t-il autant de versions NDC ? Pourquoi deux compagnies qui “font du NDC” ne proposent-elles pas les mêmes fonctionnalités ? Et est-ce qu’on va un jour arriver à quelque chose de vraiment standardisé ?

Réponses honnêtes.

Sommaire

NDC : un standard, mais lequel ?

Commençons par le commencement. NDC est un standard de communication basé sur XML un langage de structuration de données utilisé pour faire dialoguer des systèmes informatiques entre eux. L’idée de l’IATA était simple : définir un vocabulaire commun pour que les compagnies aériennes puissent exposer leur contenu à n’importe quel système de distribution, sans passer par les GDS.

Bonne idée. Sauf que ce “vocabulaire commun” a été publié en plusieurs versions successives. Et chaque version a ajouté, modifié, ou supprimé des fonctionnalités.

Voici les grandes étapes :

NDC 13.1 et 14.1 (2013-2014)

Les premières versions, expérimentales. Quelques compagnies pionnières testent le concept. Le standard est encore embryonnaire : la recherche de vols fonctionne à peu près, mais l’after-sale est quasi inexistant. Personne ou presque ne les utilise encore en production.

NDC 15.1 et 16.1 (2015-2016)

Le standard commence à prendre forme. Les fonctionnalités de base se stabilisent. Les premiers agrégateurs sérieux commencent à travailler dessus. C’est la période des “proof of concept” à grande échelle.

NDC 17.1 et 18.1 (2017-2018)

La maturité arrive. Air France-KLM, Lufthansa Group, British Airways lancent leurs API NDC en production sur ces versions. Les ancillaires font leur apparition. Le marché commence à y croire vraiment.

NDC 18.2 (2019)

La version charnière. Elle introduit des fonctionnalités d’after-sale structurées, une meilleure gestion des offres Corporate, et des capacités de personnalisation avancées. La majorité des compagnies “NDC matures” aujourd’hui tourne sur cette version ou sur ses évolutions.

NDC 21.3 (2021)

La version la plus récente et la plus complète à ce jour. Elle standardise davantage la gestion des ordres (les “Orders” remplacent les PNR traditionnels), renforce les capacités de modification post-émission, et pose les bases d’une interopérabilité accrue entre acteurs.

Le problème ?

En 2026, on trouve encore des compagnies qui tournent en 17.1, d’autres en 18.2, certaines en 21.3. Et quelques-unes qui mixent les versions selon les fonctionnalités. Ce n’est pas de l’anarchie, c’est de la réalité industrielle. Migrer un système de distribution central d’une version à l’autre, pour une grande compagnie, c’est un chantier de 12 à 24 mois minimum.

Image illustrative créée par infostourisme.com - Le standard NDC illustre la complexité croissante des systèmes de distribution aérienne entre promesse d’uniformisation et réalité technique fragmentée — Image illustrative créée par infostourisme.com – Le standard NDC illustre la complexité croissante des systèmes de distribution aérienne entre promesse d’uniformisation et réalité technique fragmentée

L’IATA, architecte et arbitre

L’IATA, l’Association internationale du transport aérien est l’organisation qui publie et maintient le standard NDC. Son rôle est double : définir les spécifications techniques, et certifier les acteurs qui l’implémentent.

La certification IATA NDC existe à plusieurs niveaux. Elle atteste qu’un acteur compagnie ou agrégateur a bien implémenté les fonctionnalités correspondant à un niveau donné. C’est une garantie minimale de conformité.

Mais voilà le nœud du problème : la certification IATA garantit la conformité au standard, pas l’exhaustivité de l’implémentation.

Autrement dit, une compagnie peut être certifiée NDC niveau 3 et n’avoir implémenté que 40% des fonctionnalités disponibles dans ce niveau. La certification dit “vous parlez bien le langage NDC”. Elle ne dit pas “vous parlez couramment”. C’est comme certifier qu’un restaurant sait faire de la cuisine française parce qu’il propose une entrée, un plat et un dessert sans préciser si c’est du surgelé réchauffé ou de la haute gastronomie.

L’IATA travaille à renforcer ce système de certification, à rendre les niveaux plus granulaires, les exigences plus précises. Mais c’est un travail de longue haleine, dans une organisation qui doit faire consensus entre des centaines de compagnies aux intérêts divergents.

Pourquoi les compagnies divergent malgré tout

Voici ce que beaucoup ne comprennent pas : même deux compagnies qui implémentent la même version du standard NDC peuvent produire des API radicalement différentes. Comment est-ce possible ?

Parce que le standard définit un cadre, pas un comportement.

Prenons une analogie simple. Le code de la route est le même pour tout le monde. Mais la façon dont un chauffeur de taxi parisien conduit n’a rien à voir avec celle d’un conducteur de bus scolaire en province. Même règles, comportements différents.

En NDC, c’est pareil. Le standard définit les messages qui peuvent s’échanger entre systèmes les requêtes, les réponses, les structures de données. Mais il laisse une liberté considérable sur plusieurs points cruciaux :

Les champs optionnels.

Une grande partie des champs du standard NDC est optionnelle. Chaque compagnie décide lesquels elle remplit, lesquels elle ignore. Une compagnie peut choisir de ne pas exposer les conditions tarifaires détaillées. Une autre peut décider de ne pas supporter la modification de nom post-émission. Toutes les deux sont “conformes au standard”.

Les extensions propriétaires.

Le standard NDC autorise les compagnies à ajouter leurs propres champs personnalisés ce qu’on appelle des extensions. Air France a les siennes. Lufthansa a les siennes. Emirates aussi. Ces extensions permettent d’exposer des fonctionnalités spécifiques à la compagnie, mais elles cassent l’interopérabilité : un agrégateur doit les implémenter une par une, compagnie par compagnie, mais de son coté, il doit produire une interface « unique » qui doit traiter toutes ces spécificités en une seule fonctionalité.

La logique métier sous-jacente.

Deux compagnies peuvent utiliser le même message NDC pour gérer un échange de billet, mais avec des règles métier totalement différentes derrière. Délais, pénalités, conditions tout ça est dans le système de la compagnie, pas dans le standard.

Résultat concret :

un agrégateur NDC sérieux ne développe pas “une connexion NDC”. Il développe une connexion par compagnie, en tenant compte des spécificités de chacune. Ce travail peut prendre de 3 à 9 mois par compagnie, selon la complexité de son implémentation, mais aussi la collaboration qui est très différente d’une compagnie à l’autre. Je pourrais écrire une livre d’anecdotes différentes, marrantes, des crises de nerfs, des demandes lunaires, …, mais non, je vais rester positif, car avec NDC, on le standard (qui n’en est pas vraiment un) du futur, pour les échanges avec les airlines.

Ce que ça implique pour les agrégateurs

C’est ici que se joue la vraie différence entre un bon et un mauvais agrégateur NDC.

Un agrégateur superficiel implémente le tronc commun du standard et espère que ça suffira. Ça marche pour les cas simples. Ça casse dès qu’on touche aux fonctionnalités avancées ou aux spécificités de chaque compagnie.

Un agrégateur sérieux fait un travail d’ingénierie compagnie par compagnie : il mappe les extensions propriétaires, il teste chaque fonctionnalité en production, il maintient sa connexion à chaque mise à jour de l’API de la compagnie. C’est un travail continu, jamais terminé, qui nécessite des équipes dédiées par compagnie stratégique.

C’est précisément pour ça que la question “Combien de compagnies avez-vous en production ?” de l’épisode 1 est si importante. Derrière chaque compagnie en production, il y a des mois de travail d’intégration spécifique. Un agrégateur qui prétend en avoir cinquante sans équipe technique conséquente ment ou survole, c’est aussi à ce niveau qu’il y’a une différence, entre avoir une compagnie, et gérer un nombre de fonctionnalités conséquentes et importantes pour les agences, surtout dans le corporate.

Convergence ou fragmentation : le vrai verdict

La question que tout le monde se pose : est-ce qu’on va finir par avoir un NDC vraiment unifié, où chaque compagnie parle exactement le même langage ?

La réponse honnête : partiellement, et progressivement.

L’IATA pousse vers plus de convergence avec chaque nouvelle version. La 21.3 est sensiblement plus homogène que la 17.1. Les prochaines versions iront dans le même sens. Mais la convergence totale est une chimère pour une raison simple : les compagnies aériennes ont des modèles commerciaux différents, des systèmes legacy différents, et des stratégies de distribution différentes. Elles n’ont pas toutes intérêt à exposer exactement le même contenu de la même façon.

Ce vers quoi on se dirige, c’est un standard de plus en plus structurant sur le tronc commun recherche, réservation, émission, after-sale de base et une fragmentation qui persiste sur les fonctionnalités avancées et les contenus différenciés. C’est-à-dire exactement là où se joue la valeur commerciale.

La NDC ne sera jamais aussi simple qu’une prise électrique universelle. Elle sera toujours, en partie, un puzzle. La question est de savoir qui a les pièces et qui sait les assembler.

A très vite pour le prochain épisode.