Un système d'IA a reproduit la décision des régulateurs aériens pour 296 passagers

L'aéroport est temporairement fermé, l'avion est bloqué, et il lui reste encore plusieurs vols dans la soirée. Annuler le départ le plus vide semble raisonnable — jusqu'à ce qu'on constate qu'il n'y a nulle part où replacer ses passagers. Parfois, il est plus simple de retirer du programme un vol plus rempli : les départs voisins ont des places, et après l'annulation l'avion restera là où l'on en aura besoin ensuite.

C'est précisément ce problème que l'équipe de Sergueï Ershov a étudié avec une compagnie aérienne russe non nommée. Selon les auteurs, ils ont assemblé huit outils d'IA et, après une série de corrections, reproduit la décision d'une employée du service commercial : annuler deux vols transportant 296 passagers. Les passagers pouvaient être replacés sur d'autres départs dans les deux jours suivants, tout en préservant le programme ultérieur de l'appareil.

Le modèle lit les messages, Python compte les places

Le détail le plus utile du cas tient à la répartition du travail. Le modèle de langage analyse le texte ou la capture d'écran du message signalant la perturbation et formule les explications. Le taux de remplissage des vols, les places disponibles, le classement et les autres calculs sont réalisés par de simples scripts Python. L'employé vérifie le résultat avant de passer à l'étape suivante.

Le système rassemble les restrictions des aéroports, repère les vols concernés, vérifie les options de réacheminement et les mouvements des avions. Il examine ensuite un éventuel remplacement d'appareil et construit un scénario global. Les employés chargent les données sous forme de fichiers issus du système de programmation, du système de réservation Leonardo et du BI. Dans le projet décrit, cet outil n'était pas connecté directement aux systèmes de production.

Imaginons deux vols dont on propose de transférer les passagers sur un même départ voisin. Si l'on vérifie chacun séparément, il est facile de promettre deux fois les mêmes sièges libres. C'est pourquoi le système puise les places dans un pool commun. Ce contrôle paraît banal, mais c'est de lui que dépend la faisabilité d'une proposition d'annulation en apparence élégante.

Une vraie perturbation a révélé des règles absentes du cahier des charges

La première vérification a porté sur une perturbation de juillet, dont la décision des employés était déjà connue. Le système a placé en tête de la liste d'annulation les mêmes vols. Sur le scénario d'août, plus complexe, des erreurs ont commencé à apparaître.

Par exemple, l'outil a jugé un vol impossible parce que l'heure d'arrivée tombait dans l'intervalle de restrictions. Or l'aéroport fonctionnait alors en mode « sur accord » : cela exigeait une décision distincte, et non une annulation automatique. Un autre point concernait les vols aller-retour d'un même avion. La décision commerciale doit souvent être prise d'emblée pour la paire, en tenant compte des passagers et des conséquences des deux vols.

Des erreurs ont aussi été trouvées dans le traitement de l'heure. Lors du filtrage des publications, le message de levée de la restriction pouvait sortir de la période choisie. Dans un calcul, le système a obtenu 1093 minutes au lieu de 1346. Les auteurs ont relié les événements d'instauration et de levée de la restriction, en ajoutant des vérifications pour les intervalles à cheval sur minuit.

On a aussi constaté qu'en cas d'écarts dans le programme, l'outil doit s'arrêter et solliciter un spécialiste. Poursuivre le calcul avec des données contradictoires donnait un résultat auquel on ne pouvait pas se fier.

Ce que prouvent les 164 exécutions

Les auteurs font état de 164 exécutions d'un seul scénario d'août. La chaîne finale comprenait 13 étapes, la création d'un fichier Excel, la vérification de l'export et un journal de calcul. Après les corrections, le système a choisi la même paire de vols que l'employée, avec la même explication : l'annulation préservait les départs suivants et permettait d'éviter leur décalage d'environ deux heures.

C'est un test de reproductibilité utile, mais de portée limitée. Des exécutions répétées d'un même scénario ne remplacent pas une vérification sur des perturbations indépendantes. L'article ne contient aucune mesure de gain de temps, d'effet financier ou de part de recommandations erronées. La concordance avec la décision du spécialiste ne prouve pas non plus, en soi, que l'option retenue soit optimale.

Pour le développeur, le repère est concret : isoler d'abord les calculs, les contraintes et les points d'arrêt, puis seulement connecter le modèle à l'analyse des messages entrants. Le product manager devrait définir à l'avance comment comparer les recommandations au travail des employés sur de nouveaux cas. L'essentiel du travail dans ce type de déploiement consiste à extraire les règles de l'expérience de l'équipe et à rendre chaque décision vérifiable.