En 2026, lorsque vous réservez un vol sur votre smartphone, votre demande transite par de multiples couches de technologies modernes : une application mobile, un service web, un processeur de paiement, avant d’arriver au système qui réserve votre siège. Ce système est, dans la plupart des cas, un logiciel dont les origines remontent aux années 1960, fonctionnant sur une infrastructure que l’industrie du voyage tente de remplacer depuis des décennies sans y parvenir complètement. Sabre, Amadeus et Travelport gèrent à eux seuls la quasi-totalité des réservations de vols dans le monde. Ils traitent chaque année des milliards de transactions pour des centaines de compagnies aériennes, des milliers d’agences de voyages et un inventaire en temps réel couvrant des millions de combinaisons de sièges. Le plus ancien d’entre eux trouve son origine dans un ordinateur central IBM de 1964 qui a réduit les délais de réservation de 90 minutes à quelques secondes et a révolutionné l’aviation commerciale.
L'explication du maintien de ces systèmes en l'état n'est pas une question d'inertie organisationnelle ou de conservatisme en ingénierie. Elle illustre ce qui se produit lorsque le logiciel est si profondément intégré à un processus opérationnel critique que le coût et le risque de son remplacement deviennent injustifiables, quel que soit le calendrier. L'industrie a alors réagi en modernisant son système central plutôt qu'en tentant de le remplacer. Pour quiconque travaille sur la modernisation de systèmes existants à grande échelle, les systèmes de réservation des compagnies aériennes constituent l'exemple le plus parlant de ce que signifie concrètement l'expression « trop important pour échouer ».
Travaillez vers l'intérieur. Comprenez le graphe de dépendance.
SMART TS XL extrait les règles métier, les cartes de dépendances et le code mort dans les programmes COBOL et les programmes existants.
EN SAVOIR PLUS…L'origine : pourquoi les ordinateurs centraux ont résolu le problème des compagnies aériennes
Le système SABRE (Semi-Automated Business Research Environment) d'origine n'était pas un produit, mais une solution sur mesure conçue pour répondre à une crise opérationnelle spécifique. À la fin des années 1950, la croissance d'American Airlines dépassait les capacités de son système de réservation manuel. Réserver un siège nécessitait un appel téléphonique, la vérification manuelle d'une fiche d'inventaire, une mise en attente, un rappel et un enregistrement papier ; un processus qui prenait en moyenne 90 minutes par réservation et qui s'avérait inadapté à l'expansion.
Lorsque SABRE devint pleinement opérationnel en 1964, reposant sur deux ordinateurs centraux IBM 7090 et connecté à 1 500 terminaux aux États-Unis et au Canada, il pouvait traiter 7 500 réservations par heure avec un taux d'erreur quasi nul. Pour la première fois, une compagnie aérienne pouvait gérer en temps réel la disponibilité des sièges, stocker l'intégralité des dossiers passagers et permettre des réservations instantanées sur l'ensemble de son réseau. Le délai de réservation passa de 90 minutes à quelques secondes.
Le choix architectural qui a rendu cela possible, le traitement centralisé des transactions sur un ordinateur central, n'a pas été motivé par des considérations philosophiques. Il a été imposé car c'était la seule architecture disponible en 1964 capable de répondre aux exigences de latence, de fiabilité et d'accès simultané nécessaires à la gestion en temps réel des stocks des compagnies aériennes. Et elle a si bien fonctionné qu'elle est devenue le modèle architectural sur lequel tous les systèmes de réservation de compagnies aériennes ultérieurs ont été construits.
La plateforme de traitement des transactions (TPF) d'IBM, initialement conçue pour SABRE, est devenue l'environnement d'exploitation de toute la catégorie. Selon IBM, la quasi-totalité des plus grandes banques, compagnies d'assurance, enseignes de distribution et compagnies aériennes l'utilisent encore. Amadeus, fondée en 1987, s'est appuyée sur la TPF. Galileo (aujourd'hui Travelport) a également utilisé la TPF pour le lancement de son GDS. Trois générations de systèmes de services passagers coexistent désormais dans l'aviation commerciale, et nombre d'entre elles fonctionnent encore sur des mainframes TPF. Ce n'est pas que la technologie n'ait jamais été remise en question, mais plutôt que le débit transactionnel, la fiabilité et la tolérance aux pannes offerts par la TPF sur matériel mainframe se sont avérés extrêmement difficiles à reproduire à une échelle équivalente sur d'autres architectures.
Que font réellement ces systèmes à grande échelle ?
Du point de vue du génie logiciel, il est difficile de saisir intuitivement l'échelle à laquelle fonctionnent les systèmes de réservation des compagnies aériennes. Un système de distribution global ne se contente pas de gérer la disponibilité des sièges ; il gère un problème d'inventaire combinatoire d'une complexité stupéfiante.
Un seul vol transatlantique propose des centaines de classes tarifaires. Chaque classe tarifaire est soumise à des règles spécifiques : obligation d’achat anticipé, durée minimale de séjour, dates d’exclusion, frais de modification, escales autorisées ou non, accords de partage de code avec les compagnies aériennes partenaires. Une réservation impliquant deux compagnies aériennes, une correspondance et un aller-retour génère un ensemble de milliers de combinaisons tarifaires potentiellement valides. Ces combinaisons doivent être vérifiées, tarifées et comparées aux disponibilités en temps réel avant qu’une réponse ne soit fournie, généralement en moins d’une seconde.
Aux périodes de forte affluence, Sabre et Amadeus traitent conjointement des dizaines de milliers de transactions par seconde. Chaque transaction comprend une consultation des disponibilités en temps réel, l'évaluation des règles tarifaires, la création ou la modification du dossier passager (PNR) et la coordination avec les systèmes de contrôle des départs, de fidélisation et de services annexes. Le temps de réponse garanti se mesure en millisecondes, car un agent de voyages ou un moteur de réservation qui attend plus de quelques secondes pour une vérification de tarif verra sa demande expirer et devra soit réessayer, soit abandonner la transaction.
Le TPF sur mainframe offre ce débit avec un taux de panne que les professionnels de l'informatique d'autres secteurs ont du mal à croire. La tolérance aux pannes du mainframe, ses processeurs redondants, ses composants remplaçables à chaud et des décennies de code système d'exploitation éprouvé garantissent une disponibilité de 99,999 % comme paramètre de fonctionnement standard, et non comme un objectif à atteindre. Reproduire ces performances à un coût équivalent sur une infrastructure cloud constitue le principal défi technique de tous les programmes de modernisation informatique des compagnies aériennes entrepris depuis les années 1990.
Les tentatives de modernisation : ce que les programmes mis en œuvre pendant une décennie ont réellement révélé
L'histoire de la modernisation des systèmes de réservation des compagnies aériennes est celle de programmes qui visaient à remplacer le système central et qui ont abouti, des années plus tard, à un système hybride qui enveloppait plutôt ce système central.
Le projet Jetstream d'American Airlines, lancé dans les années 2000 avec l'objectif explicite de remplacer le système PSS Sabre, s'est finalement soldé par l'adoption d'un nouveau produit Sabre plutôt que par le développement d'une solution alternative. L'hypothèse initiale, selon laquelle la conception interne permettrait d'obtenir un meilleur système plus rapidement, s'est heurtée à la même réalité que presque tous les grands programmes de remplacement de systèmes existants : le système en place présentait des exigences dont personne n'avait connaissance jusqu'à ce que le système de remplacement ne puisse y répondre.
Il nous faut examiner en profondeur l'architecture système, modifier le moteur principal et découpler les règles afin de pouvoir les modifier rapidement. Cette déclaration, faite par la direction informatique d'American Airlines lors du programme Jetstream, décrit précisément le problème. Les règles intégrées au système existant – logique de calcul des tarifs, implémentation des accords de partage de code, calculs de conformité réglementaire, intégrations de la gestion des revenus – s'étaient accumulées au fil des décennies d'évolution de l'entreprise et n'étaient documentées sous aucune forme permettant leur extraction sans exécuter le système existant et observer son comportement.
Le programme de modernisation de Sabre, lancé dans les années 2010, a nécessité plus d'une décennie d'efforts et des milliards de dollars d'investissement pour migrer la majeure partie de son code hors de son infrastructure mainframe sur site. En 2019, environ 11 % du code de Sabre était encore exécuté dans des centres de données sur site, le reste ayant été migré. En février 2026, Sabre a renouvelé son accord de services de paiement (PSS) à long terme avec WestJet, démontrant ainsi que, même après une décennie d'efforts de modernisation et des milliards d'investissements, le PSS demeure le pilier commercial de l'entreprise.
Amadeus a mené à bien une migration plus complète vers le cloud, franchissant une étape importante avec le retrait de ses derniers mainframes. Son approche, consistant à remplacer progressivement les composants fonctionnels tout en préservant le modèle de données et l'architecture transactionnelle, a permis de conserver les choix architecturaux initiaux, malgré l'évolution du matériel. La sémantique des transactions, la structure PNR et la logique de gestion des stocks ont ainsi été transférées vers une infrastructure moderne tout en conservant leur conception fondamentale.
Pourquoi le remplacement est plus difficile qu'il n'y paraît : la complexité cachée
L'explication généralement avancée pour justifier le maintien des systèmes de réservation des compagnies aériennes sur mainframe est le coût et le risque. Ces deux facteurs sont bien réels. Mais ils ne sont que les symptômes d'une réalité technique plus profonde qu'il est essentiel de comprendre précisément, car elle s'applique à tout programme de modernisation de systèmes critiques existants.
Les règles métier n'existent que dans le code. La logique de calcul des tarifs dans un système de distribution global (GDS) est le fruit de décennies d'exigences réglementaires, d'accords bilatéraux entre compagnies aériennes, de révisions des normes IATA et de modifications des règles métier, autant d'éléments non documentés indépendamment du code qui les implémente. La spécification constitue l'implémentation. Remplacer l'implémentation sans la spécification implique d'observer le comportement du système existant de manière exhaustive afin de reconstituer ce que la spécification aurait défini. Ce processus, qui prend des années, est sans fin, car l'observation ne peut jamais être suffisamment complète pour couvrir tous les cas particuliers.
La sémantique transactionnelle de TPF est difficile à reproduire pour les architectures modernes. TPF assure un traitement transactionnel synchrone et atomique, avec une cohérence garantie sur l'ensemble du dossier PNR, la réservation de siège, la mise à jour du dossier passager, l'autorisation de paiement et la confirmation, le tout étant validé comme une seule unité atomique, ou pas du tout. Reproduire cela sur des architectures de microservices distribuées exige une orchestration rigoureuse, des transactions compensatoires et une gestion distribuée des verrous, ce qui est à la fois complexe et potentiellement plus lent que l'équivalent synchrone sur mainframe. L'expérience du secteur aérien montre que la « cohérence à terme » n'est pas acceptable pour la gestion des stocks de sièges ; un vol surbooké représente un échec opérationnel catastrophique, et non une incohérence temporaire à résoudre ultérieurement.
La surface d'intégration. Un système de réservation de vols (PSS) mature est connecté à des centaines de systèmes externes : contrôle des départs, gestion des revenus, programmes de fidélisation, systèmes aéroportuaires, connexions GDS tierces, partenaires en partage de code, rapports réglementaires, etc. Chaque connexion possède des contrats d'interface, des formats de messages, des exigences de synchronisation et des comportements de gestion des erreurs spécifiques, implémentés par le système existant et intégrés à l'architecture de chaque système dépendant. Remplacer le PSS implique soit de maintenir simultanément tous les contrats d'interface existants (ce qui limite l'architecture de remplacement), soit de coordonner les modifications avec chaque système dépendant (ce qui dépasse les capacités d'un seul programme).
Le problème des données en temps réel. Les réservations aériennes sont des données en temps réel, effectuées des mois à l'avance et qui doivent être honorées à la lettre. Il n'existe pas de point de basculement direct permettant d'abandonner les données de l'ancien système. La migration doit transférer l'intégralité des dossiers PNR (Pilote de Réservation) de l'ancien système vers le nouveau, en conservant intactes toutes les règles, tarifs, restrictions et services annexes associés. La migration des PNR à l'échelle mondiale, sans aucune perte de données et avec une garantie de fonctionnement identique, s'est avérée être l'un des défis techniques les plus complexes de la modernisation des entreprises.
Réponse architecturale : moderniser autour du noyau
L'approche qui a réellement fonctionné, chez Amadeus, chez Sabre, dans les compagnies aériennes individuelles, n'est pas le remplacement mais l'encapsulation stratégique et l'extraction progressive.
L'encapsulation d'API expose les fonctions de réservation essentielles sous forme d'API REST ou SOAP modernes, permettant ainsi aux nouvelles applications d'interagir avec le système existant via une interface moderne sans modifier la logique transactionnelle sous-jacente. Les compagnies aériennes ont développé des applications mobiles, des moteurs de réservation web et des outils de service client basés sur des couches API qui traduisent les requêtes modernes en appels de transaction TPF et renvoient des réponses structurées. Le terminal à écran vert est remplacé par une interface graphique moderne ; le traitement transactionnel sous-jacent reste inchangé.
La méthode Strangler Fig est utilisée pour les fonctions non essentielles. Les fonctions connexes aux fonctions principales (gestion des revenus, gestion des programmes de fidélité, reporting et analyses, planification des équipages) sont extraites une à une et réimplémentées sur une infrastructure moderne. Chaque extraction réduit l'empreinte du système existant sans toucher au cœur transactionnel, qui présente le risque le plus élevé. Au fil d'une décennie d'extraction progressive, le rôle du système existant se réduit progressivement, passant d'une plateforme applicative globale à un moteur transactionnel spécialisé.
Infrastructure cloud à architecture préservée. La mise hors service du mainframe d'Amadeus a permis de transférer les charges de travail vers une infrastructure cloud tout en préservant l'architecture transactionnelle d'origine. Le matériel a évolué ; la conception logicielle, le modèle de données, la sémantique des transactions et la structure PNR ont conservé les choix architecturaux qui avaient fait leurs preuves depuis des décennies.
Nouvelle gestion des offres et des commandes en complément du système PNR traditionnel. La norme IATA ONE Order, qui remplace les enregistrements PNR par un modèle moderne de gestion des commandes, est mise en œuvre par les compagnies aériennes en complément du système PNR existant. Les technologies d'offres et de commandes de nouvelle génération de Sabre, mentionnées dans le renouvellement de son contrat avec WestJet pour 2026, présentent cette approche comme la voie à suivre : non pas un remplacement du système de réservation intégré (PSS), mais l'ajout d'une couche commerciale moderne qui, à terme, prendra en charge une part croissante des réservations, tandis que le système PNR central gérera le reste.
Ce que cela signifie pour toute modernisation des systèmes hérités critiques
L'histoire des systèmes de réservation aérienne n'est pas propre au secteur de l'aviation. Elle constitue l'exemple le plus visible d'une tendance qui se retrouve dans les systèmes centraux bancaires, la gestion des polices d'assurance, la facturation des télécommunications et le traitement des prestations sociales : un logiciel qui devient la spécification faisant autorité des règles métier, sert de plateforme d'intégration pour des dizaines de systèmes dépendants et fonctionne à une échelle et avec un niveau de fiabilité tels qu'un remplacement radical est tout simplement impossible.
Les leçons sont les mêmes dans tous les secteurs d'activité :
L'extraction des règles métier du code, avant toute modernisation, est indispensable. Les programmes COBOL et TPF qui implémentent la construction des tarifs, la logique des accords de partage de code et les règles de conformité réglementaire constituent la seule documentation subsistante de ces règles. Une modernisation qui n'extrait et ne valide pas au préalable cette logique ne peut produire un système de remplacement fonctionnant correctement en toutes circonstances, car il est impossible de connaître tous les cas de figure sans analyser l'intégralité du code.
La cartographie des dépendances détermine la séquence de migration. Aucune compagnie aérienne n'a réussi à remplacer son système de services de transport (PSS) en commençant par le composant le plus critique et le plus intégré. Toute modernisation réussie a débuté par les systèmes périphériques : les systèmes de reporting, les services auxiliaires, les fonctions administratives non critiques, pour ensuite progresser graduellement vers le centre. Cette séquence découle du graphe de dépendances : les composants présentant le moins de dépendances entrantes sont les plus sûrs à migrer en premier.
La validation opérationnelle à chaque étape est indispensable. Seule la validation par double exécution, consistant à faire fonctionner le nouveau système en parallèle avec l'ancien, à comparer les résultats et à valider l'équivalence avant tout basculement de trafic, répond aux exigences de fiabilité des systèmes où les défaillances ont des conséquences physiques, financières et réglementaires.
Comment SMART TS XL S'applique à l'analyse des activités connexes aux compagnies aériennes
Les compagnies aériennes qui utilisent Sabre ou Amadeus PSS en parallèle de leurs propres programmes COBOL, systèmes de calcul des tarifs, comptabilité des revenus, calcul des points de fidélité, rapports réglementaires, sont confrontées exactement au même défi analytique que tout programme de modernisation de mainframe d'entreprise : comprendre ce que contient réellement le code avant de décider quoi en faire.
SMART TS XL's analyse de code statique Cette extraction permet de récupérer la logique métier intégrée aux programmes COBOL, les règles de validation des tarifs, les calculs de comptabilisation des recettes et la logique d'éligibilité aux niveaux de fidélité, qui n'existe nulle part ailleurs que dans le code source. Pour les compagnies aériennes souhaitant moderniser des systèmes connexes sans modifier le cœur du système de paiement, cette extraction fournit les spécifications auxquelles le système de remplacement doit se conformer.
La cartographie des dépendances applicatives construit le graphe de dépendances qui détermine la séquence de migration : quels programmes côté compagnie aérienne dépendent de quels flux de données provenant du PSS ? Quels programmes de reporting dépendent de quelles sorties de traitement par lots COBOL ? Quels systèmes en aval doivent être mis à jour lors de toute modification d’un composant ? Ce graphe de dépendances rend possible une modernisation progressive et sécurisée, à l’instar de l’approche utilisée par Sabre et Amadeus pour leurs systèmes centraux, appliquée ici au code côté compagnie aérienne.
L' analyse d'impact permet de répondre à la question qui précède toute décision de modernisation : si ce programme est modifié, quelles autres conséquences seront observées ? Pour les systèmes des compagnies aériennes où une modification de calcul dans un programme de comptabilité des revenus peut affecter simultanément les rapports réglementaires, le règlement des partenaires et la consolidation financière, connaître l'étendue de l'impact avant toute modification est indispensable à une gestion des changements conforme aux exigences de fiabilité de la compagnie.
L' analyse de modernisation du système existant fournit un inventaire complet des programmes pré-modernisation : chaque programme concerné, sa complexité, ses dépendances, son pourcentage de code mort et sa classification des risques liés à la migration. La leçon de tout programme de modernisation de compagnie aérienne – commencer par les périphéries, progresser vers le centre et valider à chaque étape – exige de connaître précisément ces périphéries et la structure des dépendances. Cette connaissance provient de l'analyse structurelle du code lui-même, et non d'une documentation antérieure à son évolution.
Les couches géologiques des logiciels critiques
Réserver un vol sur un smartphone en 2026, c'est interagir avec un logiciel aux multiples couches distinctes. L'interface moderne en surface. La couche API en dessous. Et, encore plus bas, le moteur de transactions PSS, fonctionnant sur une infrastructure qui a considérablement évolué depuis les années 1960, mais qui conserve une sémantique transactionnelle et des modèles de données qui étaient pertinents lors de leur conception et qui ont fait leurs preuves.
Le système de réservation des compagnies aériennes n'est pas un échec de la modernisation. Il est le fruit de six décennies de décisions rationnelles prises par des ingénieurs et des dirigeants qui ont compris, à chaque proposition de remplacement, que le risque d'erreur était supérieur au coût du maintien d'un système performant. Les systèmes qui perdurent aussi longtemps le font parce qu'ils le prouvent, transaction après transaction, vol après vol, saison après saison.
La leçon pratique pour toute équipe de modernisation n'est pas que les anciens systèmes ne doivent jamais être remplacés. Elle réside plutôt dans le fait que la décision de les remplacer doit être prise en ayant une connaissance approfondie de leur contenu, des éléments qui en dépendent et de l'ampleur réelle des changements, et non sur la base d'estimations optimistes réalisées avant même d'avoir mesuré la complexité. Le secteur aérien l'a appris à ses dépens. Les outils d'analyse qui permettent d'obtenir une connaissance structurelle complète avant même d'écrire la première ligne de code offrent la possibilité d'apprendre de cette manière, et ce, à moindre coût.
