Les principes fondamentaux de la vente au détail dans le secteur aérien moderne. Une série de courtes vidéos explicatives sur le MAR : la terminologie, la structure et les changements qui interviennent lorsque les compagnies aériennes passent des PNR aux commandes.
Les articles précédents ont présenté l'OOSD tel qu'il existe en théorie : son schéma, sa structure et ses normes. Celui-ci porte sur ce à quoi ressemble concrètement le fait de développer à partir de ce modèle.
En bref : c'est complexe, c'est un travail de longue haleine, et il arrive plus souvent qu'on ne le pense que la spécification et la mise en œuvre divergent.
Le problème du système bilingue
L'un des principaux défis liés à la mise en place d'un système moderne de gestion des livraisons réside dans le fait que les systèmes hérités n'ont pas disparu. Les compagnies aériennes utilisent toujours des systèmes articulés autour des PNR, des SSR et des références de réservation à six caractères. Les services d'assistance en escale, la gestion des bagages et les systèmes APIS fonctionnent avec des identifiants hérités. On ne peut pas simplement remplacer l'ancien système par le nouveau ; il faut gérer les deux en parallèle.
Une approche consiste à mettre en place ce que l'on pourrait appeler un système bilingue : plutôt que de traduire entre l'ancien et le nouveau système, on conserve les deux représentations en parallèle au sein du même système. Le système comprend les PNR et les commandes ; il peut communiquer dans les deux sens sans perte d'informations.
Dans la pratique, la tendance à la divergence est bien réelle. Le nouveau monde obéit à des contraintes différentes — voire, dans certains cas, à aucune contrainte là où l'ancien monde imposait des limites strictes. Une commande peut compter 200 passagers. Une réservation PNR était généralement plafonnée à 20. Un système conçu pour 20 devra à terme être repensé pour en gérer 200. Maintenir les deux mondes synchronisés aussi longtemps que possible permet de gagner du temps, mais pas indéfiniment.
Construire aux côtés de l'OrMS
Il y a un autre problème : dans de nombreuses implémentations, le système de gestion des commandes et le système de gestion des livraisons sont développés en parallèle, par des équipes différentes, selon des normes en constante évolution. Dès qu’un des deux systèmes évolue, l’autre doit suivre. On se retrouve ainsi à développer conjointement sur la base de spécifications en constante évolution, et lorsque ces spécifications changent (ce qui arrive inévitablement), les deux équipes doivent s’adapter.
Il ne s'agit pas ici de critiquer le processus de normalisation, mais plutôt d'une réflexion sincère sur ce qu'implique le fait d'être parmi les premiers à mettre en œuvre ces normes. Les normes sont élaborées par des comités et validées au fil du temps ; les cas limites et les contradictions pratiques n'apparaissent pas toujours avant que quelqu'un ne tente de les mettre en pratique.
Ce que la spécification ne couvre pas
Certains éléments du tableau opérationnel ne relèvent absolument pas du schéma OOSD, mais font néanmoins partie intégrante de la réalité quotidienne de l'exploitation d'un système de contrôle des départs. Les messages de planification, les MVT, les SSIM et les ASM ne font pas partie de l'OOSD, mais un DCS doit tout de même conserver les données de planification. Pour l'instant, cela implique de continuer à recevoir ce type de messages hérités provenant de l'OrMS, même dans le cadre d'une implémentation par ailleurs moderne.
De même, les accords interlignes et les accords de partage de code ajoutent une couche de complexité que le schéma gère au niveau conceptuel ; il existe une distinction entre la compagnie aérienne responsable de l'offre, le transporteur effectif et le transporteur commercial, mais la mise en œuvre pratique est floue et doit souvent être traitée au cas par cas.
La distinction entre le vendeur et le prestataire de services de livraison
Un concept qu'il est utile de comprendre si vous développez dans ce domaine : le schéma fait la distinction entre un vendeur (l'entité qui a ajouté des articles à une commande) et un prestataire de livraison (l'entité chargée de mettre à jour les codes de statut de livraison). Il s'agit de rôles distincts, assortis de droits d'accès différents. Les vendeurs ne peuvent pas voir les articles des autres vendeurs dans une commande. Un prestataire de livraison doit avoir une vue d'ensemble de la commande : tous les articles, tous les services, quel que soit le vendeur, car il est chargé d'accompagner le passager tout au long de son trajet.
Si vous développez un système de distribution de contenu (DCS), vous êtes un fournisseur de services de diffusion. Cela signifie que votre modèle d'accès, vos besoins en matière de données et vos responsabilités diffèrent de ceux d'un système de vente.
Q : Le fait de s'appuyer sur l'OOSD a-t-il posé des défis majeurs, comme le décalage au niveau de la limite du nombre de passagers ?
Oui. La norme de commande n'impose aucune limite quant au nombre de passagers, mais un système de réservation (DCS) hérité peut avoir une limite stricte de 20. Ce n'est qu'un exemple parmi tant d'autres de ce genre d'incompatibilité qui se présente constamment. On le retrouve partout : dans le fonctionnement des identifiants, dans la modélisation des données d'horaires, dans la gestion des réservations interlignes. En toute honnêteté, la mise en place d'un tel système est un projet qui s'étend sur plusieurs années, et une grande partie du travail consiste à combler les écarts entre l'ancien et le nouveau système.
Q : Ces difficultés d'intégration et ces cas particuliers sont-ils consignés quelque part ?
Ils devraient l'être. Il y a un réel intérêt à comparer ce que prévoient les spécifications avec ce qui fonctionne réellement dans la pratique, tant comme ressource interne que comme source d'informations utiles pour l'ensemble du secteur. L'ironie, c'est que les équipes les mieux placées pour documenter cela sont justement celles qui sont trop occupées à le mettre en œuvre. C'est une lacune bien connue.