Résumé

  • LLC "AFLT-SYSTEMS" ressemble moins à un éditeur indépendant qu’à une filiale stratégique chargée de transformer la contrainte d’import-substitution d’Aeroflot en logiciels, intégration, réseau, support et capacité de reprise. Les chiffres publics donnent une échelle réelle: plus de quarante systèmes en développement ou support, environ vingt-cinq mille vols par mois, plus de huit cents spécialistes et un périmètre annoncé autour de cinquante-cinq millions de passagers par an.

  • Le dossier économique reste incomplet. Les produits FlyBag, FlyID, FlyNav, SODA et les autres briques affichées ont une logique opérationnelle claire, et SODA est le meilleur cas public de productivité avec un cycle de livraison présenté comme réduit de trois mois à un mois.

    Mais les prix ne sont pas publics, les revenus propres reposent sur des agrégateurs secondaires, la concentration sur Aeroflot semble élevée, les partenariats extérieurs sont surtout des accords d’intention ou d’adaptation, et les signaux d’usage autour des logiciels de cockpit rappellent que remplacer un fournisseur ne suffit pas à réduire le risque si l’expérience intégrée échoue.

  • Le jugement le plus solide est conditionnel. Si AFLT-SYSTEMS abaisse durablement le coût de changement, améliore la résilience et rend les systèmes d’Aeroflot plus rapides à modifier, elle peut justifier une économie captive même avec des marges modestes. Si, au contraire, elle ne fait que déplacer la dépendance vers une mosaïque de partenaires domestiques sans service mesurable, elle devient un centre de coût nécessaire, mais pas une entreprise logicielle prouvée.

Une société née d’une contrainte, pas d’une mode

L’histoire économique de LLC "AFLT-SYSTEMS" commence par une contrainte de continuité. Aeroflot n’opère pas un commerce numérique ordinaire. Une compagnie aérienne vend des sièges, gère des horaires, transporte des passagers, maintient des avions, distribue de l’information aux équipages, traite les interruptions et doit conserver la confiance dans des opérations où le retard d’un système peut rapidement devenir un coût commercial, politique et réputationnel. Dans ce cadre, le logiciel n’est pas une couche décorative. Il est une partie de la capacité d’exploitation.

La société se présente publiquement comme une entreprise informatique du groupe Aeroflot. Elle revendique trois ans de présence sur le marché, plus de quarante systèmes en développement ou en support, environ vingt-cinq mille vols par mois servis par ses logiciels, plus de huit cents spécialistes et une empreinte annuelle touchant environ cinquante-cinq millions de passagers. Ces chiffres doivent être lus avec prudence, car ils sont fournis par l’entreprise elle-même et ne détaillent pas les contrats, les coûts, les niveaux de service ni la répartition exacte entre employés, sous-traitants et partenaires.

Ils donnent cependant l’ordre de grandeur du problème: ce n’est pas une petite équipe chargée de numériser un service périphérique; c’est une structure placée près du noyau opérationnel d’un grand groupe aérien.

La création de la société en septembre 2022, selon les registres agrégés, arrive dans un contexte évident. Le transport aérien russe devait réduire sa dépendance aux systèmes étrangers de réservation, de distribution, de gestion d’entreprise et d’analyse. Le passage vers Leonardo pour les systèmes passagers, les débats sur Sabre et Amadeus, et les estimations de migration de SAP vers des solutions domestiques dessinent le même paysage: une grande compagnie russe ne peut plus traiter le choix logiciel comme un simple arbitrage entre prix, fonctionnalités et confort commercial.

La disponibilité politique du fournisseur, la souveraineté des données, la capacité de correction locale et la possibilité de reprendre un service après incident deviennent des variables de premier rang.

Cela change la manière d’évaluer AFLT-SYSTEMS. Une société logicielle traditionnelle doit convaincre des clients externes, protéger une marge brute, défendre un prix et montrer que son produit s’étend au-delà d’un compte principal. Une filiale captive doit d’abord prouver autre chose: qu’elle réduit un risque intolérable pour son groupe, qu’elle rend l’exploitation plus modifiable, et qu’elle évite qu’une dépendance étrangère se transforme en interruption. Le rendement financier visible peut alors être faible sans que le projet soit irrationnel. Mais cette indulgence a une limite.

Même une filiale captive doit finir par montrer qu’elle ne remplace pas une dépendance par une autre plus opaque, plus coûteuse et moins mesurable.

L’incitation centrale: payer pour le contrôle

Le moteur de l’entreprise est le contrôle. Aeroflot a besoin de systèmes qui continuent de fonctionner quand les fournisseurs internationaux, les canaux de maintenance, les licences ou les mises à jour deviennent incertains. Dans l’aviation, l’absence de contrôle ne se mesure pas seulement au prix d’un abonnement perdu. Elle se mesure en retards, annulations, surcharge des centres d’appels, travail manuel, défaut de traçabilité, risques de sécurité et perte de capacité à modifier rapidement les règles commerciales.

Le coût de dépendance est donc asymétrique: il peut paraître faible en temps normal et devenir énorme quand l’accès au fournisseur se ferme.

AFLT-SYSTEMS répond à cette asymétrie en internalisant ou en localisant des capacités qui touchaient auparavant plusieurs couches du système aérien: commerce électronique, vente au détail aérienne, systèmes commerciaux, assistance aux vols, intégration du back-office, échange de données et infrastructure réseau. Cette liste paraît large, mais elle a une cohérence économique. Les compagnies aériennes ne souffrent pas seulement de la perte d’un logiciel isolé.

Elles souffrent des interfaces entre logiciels: réservation, données passagers, planification, documents de vol, données météo, informations d’aéroport, centre d’appels, paiements, fidélité, disponibilité des services et gestion des exceptions. Si un groupe veut réduire sa dépendance, il doit réduire les ruptures entre ces couches.

Le problème est que le contrôle n’est pas gratuit. Il remplace souvent un modèle dans lequel un fournisseur mondial amortissait les coûts de recherche, de développement, de conformité et de support sur de nombreux clients par un modèle où un groupe national supporte une plus grande part de ces coûts. Si le marché domestique est assez large, ou si plusieurs compagnies réutilisent les mêmes briques, la charge devient supportable. Si le client principal reste presque seul, l’économie ressemble davantage à une assurance chère qu’à un éditeur extensible.

Les chiffres disponibles illustrent cette tension. Aeroflot Group a transporté environ cinquante-cinq millions de passagers en 2025 et affiché des revenus IFRS de plus de neuf cents milliards de roubles, avec un EBITDA ajusté important et une dette nette élevée. En divisant ces montants par le trafic, on obtient des ordres de grandeur utiles pour le groupe: environ seize mille trois cents roubles de revenu par passager, environ trois mille trois cent cinquante roubles d’EBITDA ajusté par passager, et près de neuf mille sept cents roubles de dette nette par passager. Ces ratios ne sont pas les revenus d’AFLT-SYSTEMS.

Ils montrent seulement la taille économique du système que les logiciels doivent protéger.

Une estimation secondaire attribue à AFLT-SYSTEMS environ 1,9 milliard de roubles de revenu en 2024 et environ 150,9 millions de roubles de profit. Si l’on rapproche mécaniquement ce revenu du périmètre déclaré de cinquante-cinq millions de passagers touchés, on obtient environ trente-quatre à trente-cinq roubles par passager. Le profit représenterait moins de trois roubles par passager. Ce calcul est faible, car le périmètre comptable, les prix de transfert et les coûts capitalisés ne sont pas publics.

Il reste parlant: même si les chiffres sont indicatifs, le coût apparent par passager peut être modeste par rapport aux enjeux d’exploitation d’un grand transporteur.

Identité, contrôle et ambiguïtés juridiques

Le cœur du dossier est suffisamment clair pour l’analyse: l’entreprise est liée au groupe Aeroflot et se présente comme son bras informatique. Les identifiants juridiques publics sont cohérents entre plusieurs sources agrégées: INN 7716971253, KPP 770501001, OGRN 1227700598916, adresse à Moscou. Les registres agrégés mentionnent une inscription en septembre 2022. Une fiche de sanctions agrégée indique que l’entité n’apparaissait pas sur les listes internationales suivies dans l’instant observé, mais cette information doit rester un constat daté, non une garantie durable.

La zone plus trouble concerne la gouvernance détaillée. Un agrégateur nomme Denis Sergeevich Popov comme directeur général dans son instantané. Un autre signale un changement de direction fin décembre 2025 vers Ruslan Gennadyevich Vereshchagin et donne une répartition de participants à 66%, 30% et 4%. Ces éléments ne doivent pas être transformés en certitude sans confirmation directe du registre compétent. Ils indiquent surtout que le lecteur ne doit pas confondre lien stratégique avec transparence complète.

L’appartenance opérationnelle au groupe est visible; l’économie précise de contrôle, de participation et de transactions liées l’est moins.

Cette distinction compte. Dans une filiale captive, la création de valeur dépend beaucoup des règles internes: qui finance le développement, qui supporte le risque d’incident, comment les licences sont facturées, quels actifs restent dans la filiale, quelles dépenses sont capitalisées, et comment les coûts de partenaires sont refacturés au groupe. Une transaction liée sur une plateforme technologique de commerce électronique a bien été signalée par un système de publication d’informations d’Aeroflot, mais les détails n’étaient pas divulgués sous les restrictions russes applicables.

Pour l’investisseur, le concurrent ou le partenaire, cela laisse une marge d’incertitude significative.

Les marques ajoutent une autre nuance. Aeroflot est présenté comme titulaire de la marque AFLT SYSTEMS ou AFLT SISTEMS, tandis qu’AFLT-SYSTEMS est titulaire de marques telles que FLYID, FLYBAG et FLYNAV. Cette répartition est cohérente avec une filiale portant une identité de groupe et des produits opérationnels propres. Elle ne prouve pas, à elle seule, une capacité commerciale indépendante. Une marque enregistrée protège un signe; elle ne démontre ni adoption, ni prix, ni rentabilité.

Mais dans un environnement où les logiciels aéronautiques doivent être réutilisables et documentés, la formalisation de marques produit n’est pas insignifiante. Elle suggère une volonté de transformer des projets internes en modules nommés.

La conclusion de cette partie est simple. L’identité publique est assez nette pour dire qu’AFLT-SYSTEMS est un instrument logiciel d’Aeroflot. Elle n’est pas assez transparente pour déduire une économie autonome. Entre ces deux phrases se situe tout le risque analytique.

Ce que vend réellement le catalogue

Le catalogue public donne une image d’entreprise plus verticale qu’horizontale. FlySmart Revenue, FlyID, FlyBag, KUPOL avec un partenaire, FlyNav, SODA et FlyThrust ne forment pas une suite générique pour toutes les entreprises. Ils appartiennent à un monde précis: aviation commerciale, commerce aérien, données passagers, documents de vol, navigation, analyse et intégration. C’est une bonne nouvelle pour la pertinence produit, mais une limite pour l’extensibilité. Plus le logiciel colle au métier d’Aeroflot, plus il peut créer de valeur opérationnelle pour Aeroflot; plus il s’éloigne d’un marché large et facilement vendable.

FlyBag est l’exemple le plus concret côté utilisateur. L’entreprise décrit un ensemble comprenant un composant serveur, une application mobile et un service d’administration sur tablettes F+tech T1100 avec le système Aurora. Les fonctions mentionnées couvrent les dossiers de briefing, la météo, les données d’aéroport, l’état de l’avion, les données d’équipage, les cartes, les bibliothèques, les rapports et certaines fonctions liées au carburant.

Cette couverture illustre un principe central: dans un cockpit, la valeur n’est pas seulement dans une application; elle est dans la synchronisation entre information, support, disponibilité hors ligne, ergonomie, traçabilité et procédures de repli.

SODA est le cas le plus intéressant côté plateforme. Les articles technologiques indiquent que SberTech a aidé AFLT-SYSTEMS à construire une plateforme de traitement de données aériennes remplaçant Sabre Intelligence Exchange pour Aeroflot. Les gains rapportés sont précis: le temps de sortie serait passé de trois mois à un mois, les ressources de support auraient été optimisées par cinq, et la plateforme couvrirait plus de cent cinquante services à forte charge.

Ces chiffres restent des affirmations fournies par les parties intéressées ou répétées par des médias spécialisés; ils ne donnent pas la base de coût, le périmètre de comparaison ni un audit indépendant. Mais ils répondent exactement à la question économique la plus importante. Si une plateforme réduit le délai de changement d’un groupe aérien, elle réduit le coût de dépendance.

FlyID, FlyNav, FlySmart Revenue et FlyThrust sont moins documentés publiquement dans les éléments disponibles. Leur présence dans le catalogue indique une ambition de couvrir identité, navigation, revenu et opérations. Le lecteur doit cependant résister à la tentation de remplir les blancs. Un nom de produit ne permet pas de déduire la maturité, le nombre d’utilisateurs, le chiffre d’affaires, la marge ou la criticité. La bonne lecture est donc graduée: FlyBag et SODA fournissent les preuves publiques les plus exploitables; le reste du catalogue dessine un périmètre stratégique mais pas encore une base économique chiffrée.

Cette prudence ne réduit pas l’importance de l’entreprise. Dans l’aviation, un produit partiellement captif peut être plus important qu’un produit vendu à beaucoup de clients secondaires. Le point décisif est la criticité du flux qu’il protège. Un système qui évite des interruptions, réduit les tâches manuelles ou accélère les changements réglementaires peut créer un rendement énorme sans apparaître comme un logiciel à forte marge dans les comptes de sa filiale.

Infrastructure et ressources: une empreinte réelle, pas une preuve suffisante

AFLT-SYSTEMS n’est pas seulement visible par ses annonces de produits. Elle apparaît aussi dans les registres réseau. RIPE la liste comme membre servant la Russie, et un enregistrement d’ASN l’associe à AS201606, avec environ 1 024 adresses IPv4 et aucune adresse IPv6 affichée dans la vue observée. Les relations amont ou de pairage visibles incluent notamment RETN, Digital Network et TransTeleCom. Un service de réputation d’IP attribue à l’empreinte visible un score de risque bas, avec un nombre d’adresses proche.

Un autre service associe une adresse échantillon à AFLT-SYSTEMS et à des noms d’hôte liés à Aeroflot, tout en signalant un seul rapport d’abus dans l’instant observé.

Ces données ne disent pas où tournent les applications critiques, comment le routage est sécurisé, quelles redondances existent, ni quelles charges sont hébergées directement par la société. Elles sont pourtant importantes. Une entreprise qui affirme fournir de l’échange de données et de l’infrastructure réseau doit avoir une présence réseau vérifiable. La présence d’un ASN et d’un bloc d’adresses ne prouve pas la qualité opérationnelle; elle confirme que l’entreprise n’est pas seulement une marque projet portée par une page de présentation.

L’absence d’IPv6 visible mérite d’être notée sans surinterprétation. Dans beaucoup d’environnements d’entreprise et d’infrastructure, IPv4 reste central. Pour une compagnie opérant dans un contexte national particulier, l’absence affichée d’IPv6 ne suffit pas à conclure à un retard stratégique. Elle signale plutôt que les lecteurs devraient demander une architecture plus complète avant de juger la modernité ou la résilience réseau.

Les questions pertinentes sont concrètes: séparation des environnements, plans de continuité, reprise après incident, gestion des certificats, protection des accès, supervision, journalisation et exercices de restauration.

Les marchés publics et appels d’offres agrégés ajoutent des indices sur les ressources mobilisées: licences de sécurité Kaspersky, assurance médicale volontaire, services de messagerie, d’antispam, d’annuaire et d’authentification, services de plateforme cloud, ordinateurs portables, moniteurs, ainsi que des prestations d’adaptation et de déploiement autour du portefeuille électronique du pilote. Ces achats ne forment pas une carte complète des coûts.

Ils montrent un profil d’entreprise de services et d’intégration où les dépenses ne sont pas seulement de la recherche logicielle pure; elles couvrent poste de travail, sécurité, cloud, identité et mise en exploitation.

Ce profil est cohérent avec une filiale chargée de remplacer des systèmes étrangers sous contrainte. L’économie ne se limite pas à écrire du code. Elle comprend l’achat de composants, la gestion d’annuaires, les contrats de support, les terminaux, les systèmes d’exploitation domestiques, l’intégration, les tests, la formation, le support de première ligne et la reprise. C’est précisément là que les marges peuvent s’éroder: plus l’entreprise doit absorber de services autour du logiciel, moins elle ressemble à un éditeur léger.

Prix, modèle d’affaires et économie unitaire

La donnée la plus honnête sur les prix est l’absence de prix publics. Le site officiel indique que les prix des droits logiciels, de la cession de droits, des travaux et services sont individuels et fournis sur demande. Cette phrase a de la valeur. Elle indique un modèle d’entreprise contractuel, probablement ajusté au périmètre, au service, à l’intégration et au client. Elle ne suggère pas une tarification standardisée par siège, par vol ou par passager. Pour une entreprise captive ou semi-captive dans l’aviation, c’est attendu.

L’économie unitaire doit donc être approchée par des proxys, non affirmée. Le groupe Aeroflot transporte environ cinquante-cinq millions de passagers par an. Si les logiciels d’AFLT-SYSTEMS touchent un périmètre semblable, chaque petite réduction du coût par passager peut avoir un effet agrégé important. Un rouble économisé par passager représente déjà des dizaines de millions de roubles à l’échelle du groupe; quelques minutes économisées par perturbation peuvent réduire les charges de centre d’appels, de compensation, de personnel et d’exploitation.

Mais ces calculs ne deviennent sérieux que si l’on connaît les processus affectés et le coût de référence.

Le chiffre secondaire d’environ 1,9 milliard de roubles de revenu pour 2024, s’il est proche de la réalité, donnerait une empreinte financière faible par rapport au groupe. Rapporté au périmètre passager annoncé, il équivaut à environ trente-quatre ou trente-cinq roubles par passager touché. Le profit secondaire d’environ 150,9 millions de roubles représenterait moins de trois roubles par passager. Ces ratios peuvent faire paraître l’entreprise peu coûteuse.

Mais ils peuvent aussi masquer des coûts ailleurs dans le groupe: salaires portés par d’autres entités, infrastructures mutualisées, dépenses capitalisées, contrats partenaires ou prix de transfert.

La bonne question n’est donc pas: AFLT-SYSTEMS a-t-elle une marge logicielle élevée? La question est: l’argent dépensé par Aeroflot pour cette capacité réduit-il davantage de risques et de coûts qu’il n’en ajoute? Une plateforme comme SODA, si elle réduit réellement le délai de livraison de trois mois à un mois, peut être rentable même sans prix de licence spectaculaire. Une application de cockpit, si elle remplace des documents, simplifie les briefings et fiabilise la navigation, peut économiser de la coordination.

Mais si elle provoque du travail supplémentaire, des contestations d’usage ou des solutions de repli bricolées, le coût apparent du logiciel sous-estime le coût réel.

Il faut aussi distinguer marge interne et option externe. Un produit vendu principalement à Aeroflot peut être rationnel pour le groupe, mais il ne vaut pas automatiquement comme actif exportable. Pour devenir un éditeur plus large, AFLT-SYSTEMS devrait montrer des contrats hors groupe, des renouvellements, des déploiements récurrents, une documentation transférable et un support capable de servir des clients aux exigences différentes. Les accords avec Aurora et RusAero vont dans ce sens, mais les éléments disponibles décrivent surtout des intentions, de l’adaptation et de l’intégration.

Ils ne prouvent pas encore une base récurrente indépendante.

Coûts, capital et charge organisationnelle

Les coûts visibles et probables d’AFLT-SYSTEMS appartiennent à plusieurs familles. La première est humaine. L’entreprise revendique plus de huit cents spécialistes, tandis qu’un agrégateur plus ancien mentionne cent trois personnes. L’écart peut venir du calendrier, de la définition des effectifs, de la présence de sous-traitants ou de l’agrégation de profils dans un groupe. Il ne doit pas être ignoré. Pour une société logicielle, la différence entre cent salariés et huit cents spécialistes change la lecture des revenus, de la productivité, de la marge et de la capacité de support.

En utilisant seulement les chiffres officiels, on peut construire deux repères faibles mais utiles. Vingt-cinq mille vols par mois impliquent environ trois cent mille vols par an. Rapportés à huit cents spécialistes, cela représente environ trois cent soixante-quinze vols touchés par spécialiste et par an. Cinquante-cinq millions de passagers rapportés au même effectif donnent environ soixante-huit mille sept cent cinquante passagers touchés par spécialiste.

Ces ratios ne disent rien de la productivité réelle, car ils ne connaissent ni la charge par système, ni la durée des astreintes, ni les tickets, ni les heures de développement, ni la part de travail faite par des partenaires. Ils aident seulement à comprendre que l’entreprise se mesure à l’échelle d’un grand réseau aérien.

La deuxième famille de coûts est l’intégration. Remplacer une brique étrangère ne signifie pas écrire une brique équivalente puis l’installer. Il faut reconnecter les données, former les utilisateurs, adapter les procédures, maintenir les terminaux, gérer les exceptions, produire des rapports, prouver la sécurité et supporter les changements. Les achats observés dans les appels d’offres agrégés pointent vers cette réalité: sécurité informatique, services cloud, courriel, annuaire, authentification, matériel, écrans, ordinateurs portables et portefeuille électronique du pilote.

Ce sont des coûts de fonctionnement autant que des coûts de construction.

La troisième famille est le capital technologique. SODA est présenté comme bâti avec SberTech Platform V. FlyBag s’appuie sur des tablettes F+tech T1100 et sur Aurora OS. Les partenariats Cloud.ru concernent des produits numériques pour la relation client et le back-office, avec robots conversationnels, assistants vocaux, analyse de dialogue et support opérateur. Bastion et BI.ZONE apparaissent dans le contexte de cybersécurité. Tout cela montre une stratégie de remplacement par écosystème domestique. C’est plus crédible qu’un discours d’autosuffisance totale, car aucune filiale aérienne ne peut tout reconstruire seule.

Mais cela veut aussi dire que le risque de dépendance ne disparaît pas; il change de fournisseurs et de juridiction.

Enfin, il existe un coût de gouvernance. Les systèmes critiques exigent des décisions de priorité: faut-il corriger une friction cockpit, accélérer un module de données, renforcer la sécurité, automatiser le centre d’appels ou intégrer un partenaire régional? Dans une filiale captive, ces arbitrages peuvent être rapides si le groupe impose une feuille de route claire. Ils peuvent aussi devenir opaques si le client interne, les partenaires et les équipes produit ne partagent pas la même mesure de succès.

Fournisseurs et partenaires: substitution ne veut pas dire solitude

Le réseau de partenaires d’AFLT-SYSTEMS est l’un des éléments les plus instructifs du dossier. SberTech est associé à SODA. Cloud.ru apparaît dans une coopération stratégique autour de produits de service client et de back-office, avec une attention portée à la fiabilité de l’infrastructure et à l’import-substitution. Bastion apparaît dans la cybersécurité, y compris dans des initiatives liées aux solutions de transport et de logistique.

Les informations postérieures à l’attaque contre Aeroflot mentionnent aussi un renforcement du SOC, des partenaires tels que BI.ZONE et Bastion, l’usage d’EDR et le développement d’un centre de sécurité au sein d’AFLT-SYSTEMS.

Ces partenariats révèlent un choix rationnel. L’entreprise ne semble pas essayer de refaire seule toute la chaîne de valeur. Elle assemble des composants domestiques et des expertises spécialisées autour du besoin aérien. Pour Aeroflot, c’est probablement la seule voie praticable. L’alternative serait soit de dépendre encore de fournisseurs internationaux difficiles à maintenir, soit de financer une reconstruction complète trop lente et trop chère. L’écosystème domestique permet d’avancer plus vite, à condition que l’intégration soit rigoureuse.

Mais l’économie de partenaire crée aussi de nouvelles zones de coût et de risque. Un fournisseur cloud peut améliorer l’élasticité et l’accès à des environnements sécurisés, mais il ajoute une dépendance d’hébergement et de service. Une plateforme de développement peut accélérer la livraison, mais elle enferme une partie de l’architecture. Un fournisseur de cybersécurité peut renforcer la défense, mais il ne remplace pas la responsabilité interne de gouvernance, de segmentation et de reprise.

Un fabricant de tablette et un système d’exploitation domestique peuvent réduire la dépendance étrangère, mais ils introduisent des enjeux d’ergonomie, de robustesse matérielle, de compatibilité et de cycle de vie.

L’analyse économique doit donc refuser un faux choix. Ce n’est pas entre dépendance et autonomie absolue. C’est entre dépendances étrangères difficiles à contrôler et dépendances domestiques plus proches, mais encore dépendances. Le gain d’AFLT-SYSTEMS dépend de sa capacité à orchestrer ces relations mieux que ne le ferait une direction informatique traditionnelle dispersée. Si la filiale impose des standards de produit, d’intégration, de support et de sécurité, elle crée un actif. Si elle devient seulement l’acheteur central d’une série de solutions domestiques, elle déplace le problème.

Le cas Cloud.ru est révélateur. Les annonces parlent d’assistants vocaux, de robots conversationnels, d’analyse des dialogues, de support aux opérateurs et de raccourcissement du parcours client. Ce sont des usages où le retour économique peut être réel: moins d’appels longs, plus de résolution au premier contact, meilleure priorisation des cas, baisse de la charge humaine en période d’irrégularité. Mais aucune annonce ne donne encore le volume traité, la réduction de coût, le taux de résolution ou la satisfaction passager. Le partenariat est donc un signal d’orientation, pas une preuve de rendement.

Concentration client et tentation de l’export interne

La concentration client est probablement le risque économique le plus évident. Les faits publics rattachent fortement AFLT-SYSTEMS à Aeroflot. Les systèmes mentionnés répondent aux besoins d’Aeroflot, les chiffres d’échelle renvoient au trafic du groupe, et la transaction liée sur la plateforme de commerce électronique confirme l’importance du compte interne. Cette concentration n’est pas forcément négative. Pour une filiale construite afin de protéger un groupe stratégique, elle est même logique. Elle devient un problème seulement si l’on cherche à la valoriser comme éditeur indépendant.

Le groupe Aeroflot lui-même donne une base de demande massive. En 2025, son trafic se situe autour de 55,3 millions de passagers, avec un taux de remplissage proche de 90% et une place dominante dans l’aviation russe. Un client interne de cette taille peut justifier une grande équipe logicielle, surtout dans un contexte où la continuité opérationnelle et la souveraineté des données comptent autant que le prix. Les coûts fixes d’une filiale peuvent être amortis sur un grand nombre de vols, de passagers, de routes, d’équipages et de transactions.

Le point faible est l’absence de preuve publique d’une diversification commerciale aboutie. L’accord avec Aurora pour adapter FlyBag à ses besoins est important. Aurora exploite des vols régionaux, domestiques et internationaux, et l’adaptation d’un portefeuille électronique du pilote à un autre transporteur suggère que le produit peut sortir du périmètre immédiat d’Aeroflot. L’accord d’intention avec TsUGA RusAero pour la planification des vols, le support de vol et l’intégration de systèmes spécialisés va dans la même direction. Mais les mots comptent.

Une adaptation, un accord d’intention et une annonce de coopération ne sont pas des revenus récurrents audités, ni des renouvellements, ni une preuve d’adoption à grande échelle.

Il existe cependant une voie plausible d’extension. Dans un marché national où plusieurs transporteurs doivent gérer les mêmes contraintes de fournisseurs, de données, de cybersécurité et de documentation, une solution développée pour Aeroflot peut devenir un standard de fait si elle est assez robuste. C’est particulièrement vrai pour les systèmes où la conformité, la langue, les terminaux et l’écosystème local importent plus qu’une fonctionnalité générique. FlyBag pourrait suivre cette logique si l’expérience cockpit est solide.

SODA pourrait aussi être réutilisable si sa promesse de cycles plus courts et de support optimisé se vérifie ailleurs.

La barrière à cette extension est la personnalisation. Plus un produit est construit selon les processus internes d’Aeroflot, plus son adaptation à un autre transporteur devient un projet de services. Ce n’est pas une condamnation; beaucoup de logiciels d’entreprise se vendent avec intégration. Mais cela limite les marges et ralentit la croissance. Pour que l’économie devienne véritablement logicielle, AFLT-SYSTEMS devrait montrer qu’elle vend une base produit stable, pas seulement du travail d’adaptation.

Concurrence et alternatives: le vrai rival est l’ancien fournisseur absent

La concurrence d’AFLT-SYSTEMS ne se réduit pas à d’autres éditeurs russes. Son premier concurrent historique est le modèle dans lequel Aeroflot utilisait ou côtoyait des fournisseurs internationaux pour les systèmes passagers, l’analyse, l’ERP et la distribution. Sabre, Amadeus, SAP et les autres noms du contexte ne sont pas seulement des fournisseurs; ils représentaient un mode d’organisation. Un grand groupe aérien pouvait acheter des capacités éprouvées, profiter d’une feuille de route mondiale et réduire la charge interne de développement. La contrepartie était la dépendance.

Après les ruptures de 2022, cette dépendance est devenue un risque de souveraineté opérationnelle. Le passage vers Leonardo, les explications sur la coexistence temporaire de systèmes de réservation et les estimations de migration des systèmes d’entreprise montrent que l’alternative étrangère n’était plus neutre. Dans ce monde, AFLT-SYSTEMS n’a pas besoin d’être meilleur que Sabre ou SAP sur tous les critères abstraits. Elle doit être suffisamment bonne, suffisamment contrôlable et suffisamment rapide à modifier pour que le groupe préfère une solution locale imparfaite à une solution étrangère incertaine.

Cela ne veut pas dire que l’entreprise échappe à la concurrence. Les alternatives domestiques existent dans chaque couche: plateformes de réservation, intégrateurs, fournisseurs cloud, éditeurs de sécurité, systèmes d’exploitation, solutions de documents de vol, services de support client et services de données. Une filiale captive peut choisir de construire, acheter, assembler ou adapter. Sa valeur dépend de la qualité de ces choix.

Construire trop de choses en interne peut créer des retards et des coûts; acheter trop de choses peut réduire la filiale à une fonction d’achat; assembler sans architecture forte peut accumuler des interfaces fragiles.

Le risque concurrentiel le plus sérieux est donc interne: l’écart entre une plateforme produit et une intégration de circonstance. Un produit comme SODA gagne en crédibilité parce qu’il promet une amélioration mesurable de cadence et de support. Un produit comme FlyBag gagne en crédibilité s’il améliore la vie réelle du pilote et la fiabilité des documents de vol. Mais si l’expérience utilisateur est contestée, si les procédures de repli sont mal conçues ou si les performances ne suivent pas, les alternatives peuvent revenir sous forme de solutions concurrentes, de projets internes parallèles ou de demandes de remplacement.

Dans ce type de marché, le client ne cherche pas seulement une fonctionnalité. Il cherche une garantie d’exploitation. Le fournisseur qui gagne est celui qui réduit le nombre de surprises. AFLT-SYSTEMS a un avantage structurel: elle est proche du client principal, comprend le contexte national et peut coordonner avec les partenaires domestiques. Elle a aussi une faiblesse structurelle: cette proximité peut réduire la pression commerciale qui force les éditeurs indépendants à documenter, standardiser et mesurer.

Le cockpit comme test économique, pas seulement technique

Les informations autour du portefeuille électronique du pilote montrent pourquoi l’économie logicielle dans l’aviation est difficile. Sur le papier, remplacer des documents, cartes, manuels, informations météo et données de briefing par une application intégrée est une bonne idée. Elle peut réduire le papier, améliorer l’actualité de l’information, centraliser les rapports et alléger certains processus. Dans une compagnie grande et contrainte, c’est aussi un lieu naturel d’import-substitution: les équipages doivent accéder aux documents et procédures sans dépendre de canaux fragiles.

Les reportages d’octobre 2024 indiquent qu’Aeroflot a commencé l’exploitation d’essai d’un portefeuille électronique du pilote russe fourni par AFLT-SYSTEMS, avec une exploitation industrielle envisagée début 2025. Les descriptions parlent de documentation de vol, cartes, manuels, MEL et procédures anormales. En mai 2025, Aurora a signé un accord d’intention pour adapter FlyBag à ses besoins, avec un déploiement prévu après adaptation sur ses vols régionaux, domestiques et internationaux. Ces éléments soutiennent l’idée que FlyBag n’est pas un simple concept interne.

Mais le cockpit impose une sanction directe à la mauvaise intégration. Des commentaires publics sur l’article technique de FlyBag ont critiqué certains aspects du flux tablette et logiciel; la réponse de l’entreprise a reconnu que des erreurs observées pendant l’exploitation d’essai avaient été résolues et que les retours des pilotes continuaient d’être collectés. Séparément, un syndicat de pilotes de Sheremetyevo a allégué l’existence d’un contrôle du parquet après des plaintes liées à SmartSky sur tablettes F+tech T1100, avec des inquiétudes concernant erreurs techniques, redémarrages, repli insuffisant et sécurité.

Des médias technologiques et un canal public ont repris des éléments de cette controverse.

Il serait injuste et imprudent d’attribuer toutes ces plaintes à AFLT-SYSTEMS. Les éléments disponibles distinguent FlyBag, SmartSky, SZ RCAI, le matériel F+tech, Aurora OS et les politiques opérationnelles d’Aeroflot. Une mauvaise expérience sur tablette peut venir du matériel, de l’application, de l’intégration, de la formation, de la procédure de repli ou de la gouvernance du déploiement. C’est précisément pour cette raison que le signal est utile. Dans un cockpit, l’utilisateur ne vit pas la distinction juridique entre fournisseurs; il vit un flux intégré.

L’économie de FlyBag dépend donc moins du nombre de fonctions que de la confiance. Si le système réduit le temps de préparation, assure l’accès aux documents, synchronise bien les données et fournit un repli crédible, sa valeur est élevée. Si les pilotes doivent multiplier les vérifications, contourner des erreurs ou réclamer des procédures parallèles, la valeur s’évapore rapidement. Un logiciel critique ne se juge pas au catalogue, mais au comportement quand le vol est sous contrainte.

SODA et la promesse plus mesurable de la donnée

SODA est le point où le dossier devient le plus quantifiable. La plateforme est décrite comme une solution de traitement de données aériennes construite avec l’aide de SberTech et destinée à remplacer Sabre Intelligence Exchange pour Aeroflot. Les bénéfices annoncés sont de nature économique: réduire les délais de sortie, optimiser les ressources de support, servir de nombreux services à forte charge.

Contrairement à un produit cockpit, où une partie de la valeur dépend de l’ergonomie et du jugement utilisateur, une plateforme de données peut être mesurée par disponibilité, latence, fréquence de livraison, défauts, coût de support et vitesse de changement.

Le passage de trois mois à un mois pour les sorties, s’il est comparable à périmètre constant, est considérable. Il signifie que les équipes peuvent corriger, ajuster ou lancer des fonctionnalités trois fois plus souvent. Dans un environnement aérien affecté par changements réglementaires, sanctions, évolution des routes, perturbations et contraintes d’approvisionnement, la vitesse de changement est un actif économique. Elle peut remplacer une partie de la dépendance à un fournisseur étranger dont les cycles, les accès et les priorités ne sont plus alignés.

L’optimisation par cinq des ressources de support est tout aussi intéressante, mais plus difficile à interpréter. Sans connaître le point de départ, le nombre de personnes, la charge, les incidents et les coûts, le multiplicateur peut être spectaculaire ou simplement narratif. Il faut le traiter comme une direction, non comme une valeur auditée. SODA gagne en crédibilité parce que plusieurs publications répètent le même cas et qu’un prix Global CIO dans une catégorie transport est mentionné. Mais un prix et un communiqué ne remplacent pas des mesures de disponibilité, de coût total et de satisfaction des équipes.

Le choix de SberTech Platform V montre aussi la nature du compromis. Construire sur une plateforme domestique peut accélérer la migration et réduire certains risques de dépendance étrangère. Cela peut aussi créer un verrouillage local. La question n’est pas de savoir si tout verrouillage est mauvais. Dans un environnement où l’ancien verrouillage étranger est devenu dangereux, un verrouillage domestique plus contrôlable peut être rationnel. La question est de savoir si l’architecture permet de changer de composant, de porter les données, de tester les reprises et de maintenir une indépendance suffisante entre la plateforme et les métiers.

SODA est donc le meilleur candidat pour prouver que AFLT-SYSTEMS peut produire autre chose qu’une substitution défensive. Si les gains de cadence et de support se confirment, elle devient une capacité d’amélioration continue pour Aeroflot. Si ces gains restent des chiffres de lancement sans suivi public, elle demeure un cas prometteur mais non prouvé.

Cybersécurité: après l’attaque, la résilience devient le produit

L’attaque contre Aeroflot en juillet 2025 change la lecture de toutes les annonces numériques. Plusieurs médias internationaux et spécialisés ont rapporté des annulations de vols et une perturbation liée à une cyberattaque. Les assaillants ont fait des déclarations étendues sur les dommages et les données, mais toutes n’ont pas été vérifiées publiquement par la compagnie. La partie solide est suffisante: il y a eu perturbation, enquête et visibilité internationale. Pour une grande compagnie aérienne russe, c’est un rappel brutal que la souveraineté logicielle sans résilience opérationnelle ne vaut pas grand-chose.

Les informations ultérieures évoquent un renforcement des défenses d’Aeroflot: SOC consolidé, partenaires tels que BI.ZONE et Bastion, usage d’EDR, développement d’un centre de sécurité au sein d’AFLT-SYSTEMS et accent mis sur des mécanismes de reprise rapide. La coopération avec Bastion avait déjà été annoncée autour de la cybersécurité pour des solutions de transport et de logistique. Ces éléments sont logiques. Une filiale qui gère des logiciels et infrastructures proches du cœur opérationnel doit aussi devenir un nœud de sécurité.

La cybersécurité modifie l’économie de la filiale de deux façons. D’abord, elle augmente les coûts. Un centre de sécurité, des capacités de détection, des partenaires spécialisés, des exercices de reprise, une segmentation plus stricte et des audits demandent des budgets récurrents. Ensuite, elle augmente la valeur d’une organisation intégrée. Si AFLT-SYSTEMS peut relier les incidents applicatifs, réseau, identité, poste de travail et cloud, elle peut réduire les temps de diagnostic et de reprise. La valeur n’est pas seulement d’empêcher une attaque; elle est de limiter la durée et l’ampleur de l’interruption.

Mais la preuve publique manque encore. Les annonces parlent de renforcement; elles ne donnent pas de temps de reprise, de résultat d’audit, de périmètre restauré, de défauts corrigés ou de séparation des responsabilités. Dans l’aviation, la cybersécurité doit être jugée après les exercices et les incidents, pas après la signature de partenariats. La question décisive est de savoir si les systèmes qui servent les vols, les passagers, les données et les centres de support peuvent être isolés, restaurés et exploités en mode dégradé.

Il faut aussi éviter une erreur fréquente: croire que l’import-substitution réduit mécaniquement le risque cyber. Elle réduit certains risques de fournisseur et de juridiction. Elle peut augmenter d’autres risques si les nouveaux composants sont moins matures, moins testés ou moins observés. La résilience d’AFLT-SYSTEMS dépendra donc de preuves techniques continues, pas du seul fait que les fournisseurs soient domestiques.

Réglementation, géopolitique et souveraineté des données

La dimension géopolitique n’est pas un décor; elle structure la demande. L’aviation russe a dû composer avec la sortie ou l’indisponibilité de plusieurs fournisseurs étrangers, avec des sanctions, avec des obligations de localisation et avec une pression politique forte pour démontrer la continuité des services. Dans ce contexte, les décisions logicielles ne peuvent pas être évaluées comme dans un marché ouvert normal. Une solution plus chère ou moins élégante peut être rationnelle si elle réduit la probabilité d’un arrêt imposé de l’extérieur.

La souveraineté des données est particulièrement importante. Les systèmes passagers, les données de vol, les documents opérationnels, les interactions de centre d’appels, les données commerciales et les informations de sécurité forment un ensemble sensible. Les partenariats avec Cloud.ru sont présentés dans un cadre de fiabilité, d’environnements gérés sécurisés, de demandes de temps de réponse et d’isolation des données. Cette orientation correspond aux besoins d’industries où les données ne peuvent pas simplement être dispersées sur des plateformes étrangères sans risque politique et réglementaire.

La réglementation aérienne ajoute une autre couche. Les logiciels de cockpit, de planification et de support de vol ne sont pas des applications de bureau ordinaires. Ils interagissent avec des procédures, des normes de sécurité, des responsabilités d’équipage et des exigences de repli. Même si les éléments publics ne donnent pas une certification détaillée pour chaque produit, ils montrent que le déploiement doit être compris dans un cadre opérationnel strict. Une application comme FlyBag ne vaut pas seulement par sa fonctionnalité documentaire; elle vaut par son intégration dans les procédures de vol.

La transparence réglementaire reste incomplète. Les agrégateurs rapportent des licences liées à la protection technique de l’information confidentielle, tandis qu’un autre instantané ne détecte pas certaines licences. Sans confirmation directe du régulateur, il faut éviter d’affirmer un nombre précis. Le signal utile est que la protection de l’information et les capacités de sécurité font partie du périmètre attendu. Ce n’est pas une surprise pour une société qui travaille avec une compagnie aérienne stratégique.

La géopolitique crée aussi un risque de complaisance. Quand une entreprise est présentée comme nécessaire à la souveraineté, il devient tentant de réduire l’exigence de performance au nom de l’urgence nationale. C’est une erreur économique. L’urgence justifie la création rapide d’une capacité locale; elle ne justifie pas indéfiniment l’absence de mesures publiques sur le coût, la disponibilité, les défauts et la satisfaction utilisateur. Une filiale stratégique doit être évaluée avec une discipline plus forte, pas plus faible, parce que ses erreurs se répercutent sur une infrastructure de transport essentielle.

Les signaux non officiels doivent être lus froidement

Les signaux non officiels autour des logiciels de cockpit ne prouvent pas une faute spécifique d’AFLT-SYSTEMS. Ils prouvent autre chose: les utilisateurs critiques peuvent contester la substitution si elle détériore le flux de travail. Les commentaires Habr, la prise de parole syndicale, les reprises par des médias technologiques et un canal public montrent une inquiétude sur les tablettes, les redémarrages, les erreurs, le repli et la sécurité. Une partie concerne SmartSky et d’autres composants qui ne doivent pas être confondus avec FlyBag. Le lecteur sérieux ne transforme donc pas ces signaux en verdict judiciaire.

Il les transforme en questions d’exploitation.

La première question est l’ergonomie sous pression. Un pilote ne mesure pas le succès par le nombre de modules affichés dans une brochure. Il mesure si l’information juste est accessible au bon moment, si l’interface ne ralentit pas la préparation, si le terminal tient, si la synchronisation est fiable et si une solution de repli existe. Une application peut être techniquement riche et économiquement destructrice si elle ajoute de l’incertitude au moment où la charge cognitive est déjà élevée.

La deuxième question est la responsabilité intégrée. Les composants cités publiquement incluent logiciel, tablette, système d’exploitation, application, serveur, procédures d’Aeroflot et parfois produit d’un autre fournisseur. Si un incident survient, l’utilisateur ne peut pas attendre que chaque fournisseur explique que sa partie fonctionnait. L’organisation doit gérer le tout. Pour AFLT-SYSTEMS, être proche du groupe Aeroflot est un avantage seulement si cette proximité lui permet de résoudre rapidement les défauts intégrés, pas seulement de produire des réponses de périmètre.

La troisième question est l’apprentissage. La réponse de l’entreprise aux commentaires sur FlyBag indique que certaines erreurs d’exploitation d’essai avaient été observées et résolues, et que les retours des pilotes continuaient d’être collectés. C’est la bonne posture minimale. Dans un produit critique, reconnaître les défauts d’essai n’est pas une faiblesse; c’est une condition de maturité. Ce qui manque au public, ce sont les métriques: types d’erreurs, fréquence, temps de correction, taux d’adoption, procédures de repli et satisfaction des utilisateurs.

Ces signaux peuvent changer la valeur économique plus vite que les annonces de partenariat. Une mauvaise adoption cockpit peut annuler une partie des économies attendues. À l’inverse, un produit qui absorbe les critiques, corrige vite et s’étend à Aurora peut devenir un actif robuste. L’écart entre ces deux scénarios se mesure dans le détail opérationnel, pas dans le langage de souveraineté.

Les faits qui feraient changer l’appréciation

Le premier fait décisif serait la ventilation du revenu. Quelle part vient d’Aeroflot, d’autres compagnies du groupe, d’Aurora, de RusAero, de partenaires stratégiques ou de clients sans lien capitalistique? Tant que cette ventilation manque, on ne peut pas distinguer une filiale de coût, une plateforme interne efficace et un éditeur commercial en devenir. Une concentration presque totale sur Aeroflot ne serait pas honteuse, mais elle limiterait l’interprétation économique.

Le deuxième fait serait l’économie contractuelle. Les prix sont individualisés et disponibles sur demande. Il faudrait connaître la structure: licences logicielles, cession de droits, projets d’intégration, services managés, maintenance, support, développement à façon ou récupération de coûts. Une société peut afficher un revenu modeste parce qu’elle facture peu à son groupe, ou parce que des coûts sont ailleurs, ou parce qu’elle capitalise une partie du développement, ou parce qu’elle n’a pas encore monétisé ses produits. Sans cette structure, les ratios par passager restent des repères fragiles.

Le troisième fait serait la qualité opérationnelle. Pour FlyBag, il faudrait des mesures d’incidents, de disponibilité, de synchronisation, d’adoption, de temps de préparation, de défauts en vol ou avant vol, et de procédures de repli. Pour SODA, il faudrait confirmer le passage de trois mois à un mois, détailler le périmètre, la charge, les services concernés, les coûts de support et les incidents. Pour les services liés au centre d’appels et au back-office, il faudrait des volumes, des taux de résolution, des temps moyens et des gains de productivité.

Le quatrième fait serait la résilience cyber. Après l’attaque contre Aeroflot, les annonces de renforcement sont nécessaires mais pas suffisantes. Les informations qui changeraient le jugement seraient des audits indépendants, des résultats d’exercices de reprise, des temps de restauration, des segments isolés, des failles corrigées et une définition claire du rôle d’AFLT-SYSTEMS dans la défense et la continuité.

Le cinquième fait serait la carte des dépendances. Quelles charges tournent sur l’infrastructure propre d’AFLT-SYSTEMS, lesquelles sur l’infrastructure Aeroflot, lesquelles chez Cloud.ru ou d’autres partenaires? Quelles parties de FlyBag dépendent du matériel F+tech, d’Aurora OS, de serveurs internes, de connexions réseau ou de services tiers? Quelles parties de SODA sont portables hors de SberTech Platform V? Ces réponses déterminent si l’entreprise réduit réellement le verrouillage ou le remplace par un verrouillage plus proche.

Le sixième fait serait la preuve d’extension. L’adaptation à Aurora et l’accord avec RusAero sont des signaux prometteurs. Ils deviendraient beaucoup plus forts s’ils débouchaient sur des déploiements mesurables, des renouvellements, des clients additionnels, des références opérationnelles et une documentation de produit qui permette de vendre sans refaire chaque projet de zéro.

Jugement

AFLT-SYSTEMS est économiquement plausible parce que le problème qu’elle traite est réel. Aeroflot a une échelle suffisante pour justifier une capacité logicielle captive. Le groupe a connu un environnement où les dépendances étrangères sont devenues des risques directs. Les systèmes touchés par la filiale concernent des flux à forte valeur: passagers, vols, commerce, documents de cockpit, données, centre d’appels, sécurité et continuité. Dans ce contexte, une entreprise qui réduit le temps de changement, améliore le contrôle local et renforce la reprise peut valoir plus que ne le suggère son revenu visible.

Mais plausible ne veut pas dire prouvé. Le dossier public ne démontre pas encore une économie d’éditeur indépendant. Les prix sont sur demande, les comptes détaillés ne sont pas disponibles dans les éléments utilisés, les chiffres financiers viennent d’agrégateurs secondaires, les accords extérieurs ne prouvent pas des revenus récurrents et les signaux d’usage autour des tablettes rappellent que l’intégration peut être le point faible. La société peut être très importante pour Aeroflot sans être encore une entreprise logicielle extensible au sens commercial.

La force d’AFLT-SYSTEMS est sa proximité avec le problème. Elle connaît le client principal, travaille dans le cadre national requis, possède une présence réseau visible, formalise des produits et s’appuie sur des partenaires domestiques crédibles. Sa faiblesse est la même proximité. Une filiale captive peut manquer de discipline de marché, accepter des coûts diffus et mesurer insuffisamment la satisfaction des utilisateurs critiques. Le risque n’est pas que l’entreprise n’ait aucune valeur; le risque est que sa valeur reste indissociable d’Aeroflot et difficile à mesurer.

L’appréciation finale doit donc rester sobre. AFLT-SYSTEMS est un actif de souveraineté opérationnelle pour un grand transporteur russe. C’est probablement sa vraie fonction. Elle mérite l’attention parce qu’elle montre comment l’import-substitution devient une architecture économique: logiciels maison, plateformes domestiques, cloud local, cybersécurité, terminaux, réseau et intégration métier. Elle ne mérite pas encore une conclusion triomphale.

La preuve décisive viendra de la qualité des déploiements, de la résilience après incident, de la capacité à satisfaire les pilotes et les opérateurs, et de la possibilité de vendre des produits réutilisables au-delà du premier client.

Si ces preuves arrivent, AFLT-SYSTEMS pourra être l’exemple d’une filiale captive devenue plateforme aérienne domestique. Si elles n’arrivent pas, elle restera quelque chose de plus modeste mais encore stratégique: un coût d’assurance payé par Aeroflot pour garder la main sur des systèmes que le marché international ne garantit plus.

Sources