Nous avons construit un solveur d'équipages aériens plus rapide. Il a juste échoué plus vite.
La première fois que je me suis retrouvé dans un centre de contrôle des opérations d'une compagnie aérienne pendant une véritable cascade de perturbations, il était un peu plus de 3 heures du matin et une tempête hivernale avait fermé une escale clé quelques heures plus tôt. Le mur d'écrans à l'avant de la salle se remplissait de rouge — annulation après annulation — et ce dont je me souviens le plus, c'est que personne n'utilisait le solveur de planification d'équipages à plusieurs millions de dollars que la compagnie avait payé. Les régulateurs avaient repoussé leurs claviers et retravaillaient à la main les rotations d'équipage brisées, sur des tableurs et un tableau blanc, au moment précis où le logiciel était censé justifier son coût.
Cette image est ce qui nous a finalement conduits à construire une IA de planification des équipages aériens pour la reprise après IROPS — mais pas de la manière à laquelle je m'attendais, et pas avant d'avoir misé sur la mauvaise solution et de l'avoir vue échouer. L'IROPS, si vous n'avez jamais eu ce plaisir, est le terme du secteur pour désigner les opérations irrégulières : les tempêtes, les fermetures, la pagaille en cascade lorsqu'un programme de vols se désagrège. Cela coûte au secteur du transport aérien un montant estimé à 60 milliards de dollars par an, soit environ 8 % des revenus mondiaux des compagnies aériennes, selon l'IATA. Environ un vol sur cinq dans le monde en est touché. Et le secret honteux que j'ai appris cette nuit-là, c'est que le logiciel d'optimisation le plus sophistiqué de l'aviation est essentiellement conçu pour être inutile pendant les événements mêmes qui coûtent le plus cher.
Le solveur optimisait une compagnie aérienne qui n'existait plus
Il est utile de comprendre ce que font réellement les solveurs d'équipages hérités. Ils exécutent une génération de colonnes — une technique d'optimisation par séparation et évaluation des prix qui excelle véritablement à trouver la façon légale la moins coûteuse de doter en personnel un programme de vols connu. Le hic tient dans le mot connu. Le solveur prend un instantané du réseau, fige le temps et calcule l'affectation optimale des équipages pour ce monde figé. Il fonctionne par cycles de traitement par lots, généralement toutes les 30 à 60 minutes.
En exploitation normale, cela convient. Le monde bouge à peine d'un cycle à l'autre. Mais pendant une cascade de perturbations, l'état du réseau change toutes les quelques minutes. Les équipages se déplacent. Les correspondances sautent. Les avions restent bloqués. Le temps que le solveur retourne une solution, les données d'entrée qu'on lui a fournies sont déjà erronées — de sorte que la réponse est un plan parfait pour une compagnie aérienne qui n'existe plus.
J'ai commencé à appeler cela l'écart optimisation-exécution : la distance entre le monde que le solveur supposait et le monde réellement présent sur l'aire de trafic. L'écart est sans danger lors d'un retard isolé. Pendant une cascade, il est fatal, parce que le solveur a été conçu pour l'efficacité — le programme le moins coûteux dans un monde connu — et ce dont vous avez désespérément besoin à 3 heures du matin, c'est de la résilience : un programme survivable dans un monde inconnu.
Le plus cruel avec un solveur d'équipages hérité, c'est que pendant un effondrement, il continue de fonctionner — vous remettant calmement un plan impeccable pour un réseau qui s'est désagrégé pendant qu'il calculait.
Pourquoi ne pouvions-nous pas simplement rendre le solveur plus rapide ?
C'est la partie dont je ne suis pas fier, et c'est la partie qui compte vraiment.
Lorsque mon équipe s'est penchée pour la première fois sur le problème, notre diagnostic était le diagnostic évident de l'ingénieur : le solveur est trop lent. Le monde change toutes les cinq minutes et l'optimiseur met de trente minutes à une heure, alors comblez l'écart — rendez-le plus rapide. Nous avons passé un temps considérable à construire un moteur de reprise plus rapide, en nous appuyant sur des heuristiques moins coûteuses pour obtenir une réponse réalisable dans la fenêtre de décision opérationnelle plutôt que d'attendre une solution prouvée optimale.
Et cela a fonctionné, au sens étroit où il retournait des réponses plus vite. Puis nous l'avons testé face à des données de perturbation réelles et je l'ai regardé produire avec assurance des plans de reprise qui étaient déjà invalides, simplement plus tôt. Nous avions construit une machine qui optimisait une compagnie aérienne fantôme à plus grande vitesse.
L'erreur était de traiter la vitesse comme le goulot d'étranglement. Ce n'en était pas un. Le goulot d'étranglement, c'était que les données d'entrée étaient de la fiction. Le solveur — le nôtre y compris — a besoin de faits établis : « Le commandant Smith est à la porte B7 à Denver. » Mais pendant une cascade, le commandant Smith est peut-être à l'hôtel, peut-être dans la navette du personnel, il a peut-être loué une voiture et se trouve à mi-chemin de Colorado Springs. L'état honnête du monde, c'est « probablement à Denver », et un solveur par génération de colonnes ne peut rien faire d'un probablement. Nous avions affiné la réponse à une question dont les données étaient des ordures.
Cet échec est la raison pour laquelle le produit existe. Si nous avions livré le solveur rapide, nous aurions vendu aux compagnies aériennes un moyen plus rapide de commettre la même erreur coûteuse.
Le trou noir de données à 1,2 milliard de dollars
Si vous voulez voir cet échec précis à pleine échelle, regardez ce qui est arrivé à Southwest en décembre 2022. L'effondrement a coûté à la compagnie environ 1,2 milliard de dollars, a entraîné l'annulation d'environ 16 900 vols, et a laissé bloqués près de deux millions de passagers pendant les fêtes.
La version populaire, c'est « des logiciels vétustes ». La véritable histoire est plus précise et plus utile. Le système de planification des équipages de Southwest, SkySolver, s'est heurté à une explosion combinatoire qu'il ne pouvait pas traiter par le calcul. Mais en dessous de cela, la compagnie a perdu la trace de l'endroit où ses propres pilotes et agents de bord se trouvaient physiquement. Le report de la position des équipages passait en grande partie par téléphone — des équipages bloqués dans des escales périphériques appelant un centre de planification où les temps d'attente grimpaient jusqu'à plusieurs heures. Cette latence a créé ce que je considère comme un trou noir de données : le système générait des programmes pour des équipages qui n'étaient pas là où il pensait qu'ils étaient. Il optimisait un réseau fantôme, et la structure de réseau point à point signifiait qu'il n'existait aucun « point de régénération » de type plaque tournante où équipages et avions se retrouvent naturellement, si bien que le rayon d'impact ne cessait de s'étendre d'escale en escale.
Ce n'est pas de l'histoire ancienne que tout le monde aurait depuis corrigée. En juillet 2024, le système de planification de Spirit a créé des affectations conflictuelles pour 43 % de ses équipages disponibles, un événement estimé entre 50 et 100 millions de dollars, parce que le système manquait de la souplesse nécessaire pour réaffecter proprement les équipages pendant la perturbation. Le schéma se répète parce que l'architecture sous-jacente — optimiser un instantané figé, exiger des données d'entrée certaines — est la même dans tout le secteur.
Southwest, à son crédit, a réagi en dépensant : environ 1,7 milliard de dollars en technologie en 2024, dans le cadre d'un programme pluriannuel plus vaste, une migration vers AWS qui a considérablement réduit l'empreinte de leurs centres de données, et un algorithme de planification environ 30 % plus rapide. C'est le bon réflexe. Mais une version plus rapide de la même architecture — c'est le piège dans lequel nous avons nous-mêmes failli tomber — comble l'écart de vitesse tout en laissant grand ouvert l'écart de certitude des données.
Que se passe-t-il désormais lorsqu'un retard dépasse trois heures ?
Pendant la majeure partie de l'histoire de l'aviation, une reprise lente vous coûtait de la bonne volonté. Des passagers en colère, une mauvaise presse, quelques bons d'achat. Ce calcul a changé le 28 octobre 2024.
C'est la date à laquelle la règle de remboursement automatique du ministère des Transports des États-Unis est entrée en vigueur — la toute première obligation de remboursement automatique. Tout retard intérieur de plus de trois heures (six pour l'international) déclenche désormais un remboursement en espèces, versé sous sept jours ouvrables, sans même que le passager ait à le demander. Pas un bon d'achat. Pas un réacheminement. Des espèces.
Faites le calcul pour un transporteur de taille moyenne effectuant 300 départs par jour. Un jour vraiment mauvais, si ne serait-ce qu'un sixième d'entre eux — 50 vols — dépasse la barre des trois heures, avec une valeur moyenne de billet de 280 $ et 150 passagers par vol, vous vous exposez à environ 2,1 millions de dollars d'exposition à des remboursements obligatoires en une seule journée. Une reprise lente après IROPS était autrefois un problème de réputation. C'est désormais un poste de dépense qui frappe dès la même semaine.
Il y a désormais un compteur qui tourne à chaque heure où votre reprise prend du retard, et depuis octobre dernier il paie en espèces, automatiquement, à chaque passager qu'il touche.
C'est la partie qui a recadré toute la conversation pour moi. Le coût de l'écart optimisation-exécution n'est plus abstrait. Il s'accumule, en dollars, face à une horloge qui s'est déclenchée à l'instant même où la tempête a commencé.
Augmentez le solveur, ne le remplacez pas
Voici la décision qui définit notre approche, et elle est délibérément peu séduisante : nous ne remplaçons pas votre solveur.
Les solveurs en place encodent des décennies de savoir métier propre aux compagnies aériennes, et le domaine qui les entoure se consolide, il ne s'effondre pas. Jeppesen — la référence du secteur, avec plus d'une centaine de compagnies aériennes clientes — a été vendu par Boeing à Thoma Bravo pour 10,55 milliards de dollars en avril 2025, l'une des plus importantes cessions technologiques de l'histoire de l'aérospatiale, et a depuis lancé Stratosphere, une couche d'IA pour la gestion prédictive des perturbations. La plateforme iFlight d'IBS Software remporte des déploiements modernes, nativement cloud — Korean Air est passée en production début 2026, avec des transporteurs comme Aeroitalia et les compagnies du Groupe Dubreuil qui l'adoptent également — soutenue par un accord de co-ingénierie avec AWS. Le CrewSolver d'Optym offre une réduction documentée des coûts d'équipage de 3 à 7 % côté planification.
Aucun de ceux-là n'est l'ennemi. Mais remarquez ce en quoi chacun excelle : l'optimisation en phase de planification et l'analytique prédictive — le monde connu, calculé à merveille. Le problème de la reprise en temps réel, à entrées incertaines, est l'écart qui reste béant. Un remplacement complet de plateforme est aussi un projet de 12 à 18 mois, et aucun responsable des opérations ne veut arracher le système qui fonctionne 350 jours par an pour réparer les 15 jours qui posent problème. Pour le DSI qui signe réellement le contrat, le calcul est pire que le calendrier : arracher un système dans lequel sont encodées des décennies de logique de conventions collectives propres au transporteur — au moment précis où la propriété même de Jeppesen vient de changer de mains pour 10,55 milliards de dollars et où sa feuille de route à long terme reste une question ouverte — est un pari que la plupart des services informatiques ne feront pas. S'installer aux côtés de l'installation existante, en consommant ses flux plutôt qu'en remplaçant son schéma, est la seule intégration qu'ils autoriseront.
Nous avons donc construit un moteur de reprise après IROPS propulsé par le ML qui s'installe aux côtés d'une installation Jeppesen ou IBS existante et gère ce que le solveur central ne peut pas : les perturbations en cascade avec des positions d'équipage incertaines, l'analyse du rayon d'impact à l'échelle du réseau, et des plans de reprise produits en quelques minutes plutôt que les 4 à 12 heures que prend habituellement une reprise manuelle. Des données de cas régionaux suggèrent que l'automatisation peut réduire ce temps de reprise d'environ 78 %. L'objectif n'est pas d'être plus intelligent que le système en place. C'est d'être utile dans les conditions exactes pour lesquelles le système en place n'a jamais été conçu.
Apprendre à un modèle à travailler avec « probablement à Denver »
Une fois que nous avons cessé d'essayer de rendre le solveur plus rapide, le véritable problème d'ingénierie s'est précisé : construire quelque chose qui prospère grâce à l'incertitude au lieu de s'y étrangler.
Le premier élément, c'est l'intelligence de position des équipages. Au lieu d'exiger un emplacement certain, nous alimentons un modèle avec des positions probabilistes — en fusionnant tous les signaux en temps réel disponibles avec le comportement historique, de sorte que le système raisonne sur l'endroit où un équipage se trouve probablement plutôt que d'attendre un appel téléphonique enfoui depuis quatre heures dans une file d'attente. Ce seul changement — passer de « certain ou rien » à « distribution de probabilité » — est ce qui permet à un plan de reprise de survivre au contact d'une véritable cascade.
Le deuxième élément, c'est de traiter le réseau comme un graphe et d'analyser où les défaillances vont se propager avant qu'elles ne le fassent — le rayon d'impact, cartographié sur la structure de réseau propre à cette compagnie aérienne, afin de voir quelle fermeture d'escale annule discrètement six vols en aval deux heures plus tard.
Le troisième élément, c'est un simulateur de scénarios, en somme un jumeau numérique de l'exploitation, afin qu'une équipe des opérations puisse répéter à l'avance un scénario de tempête hivernale et tester des stratégies de reprise lorsqu'il n'y a ni tempête réelle ni horloge réelle. L'aviation fait déjà confiance aux jumeaux numériques là où les données sont riches — la plateforme AVIATAR de Lufthansa ingère 23,7 téraoctets par jour à travers 34 intégrations de compagnies aériennes et atteint une précision de 93,6 % sur la prédiction des défaillances de maintenance. Les jumeaux d'équipage et de planification en sont encore à leurs débuts, ce qui est précisément là que se trouve l'opportunité.
Et ce qui traverse l'ensemble, c'est le moteur de contraintes. Chaque recommandation doit être légale au regard des règles de fatigue de la Part 117 de la FAA — les limites de temps de vol de 8 à 9 heures, les périodes de service de 9 à 14 heures — et au regard de la convention collective de la compagnie aérienne, qui est fréquemment plus restrictive que la réglementation. La plupart des fournisseurs traitent ces règles comme de la « configuration ». Nous considérons l'encodage de la convention collective spécifique d'un transporteur, par flotte et par base d'affectation, comme une ingénierie fondamentale, parce qu'un plan de reprise qui viole une clause d'une convention collective n'est pas un plan — c'est un grief.
Pourquoi nous fonctionnons d'abord en mode fantôme
Les gens de ce secteur ont raison de se méfier d'une boîte noire qui leur dit comment déplacer des pilotes à 3 heures du matin. Je vais donc vous dire l'objection que j'entends le plus, parce que je l'avais moi-même.
Un vice-président des opérations nous a dit très tôt, en substance, qu'ils venaient de prendre une licence pour le module complémentaire d'IA de gestion des perturbations de leur fournisseur en place et qu'ils ne voyaient pas pourquoi ils auraient besoin de nous. C'est légitime. Puis la tempête suivante est arrivée, le module leur a donné des prédictions et non une reprise d'équipage exécutable, et les régulateurs étaient de retour devant le tableau blanc. La distinction que cette conversation m'a apprise : il y a un monde de différence entre une IA agentique pour le chat en contact avec les passagers — le mot à la mode du circuit des conférences en 2026 — et une IA qui prend des décisions opérationnelles concernant les équipages et les avions. Un agent conversationnel qui réaccommode un passager est une bonne chose. Ce n'est pas le même problème d'ingénierie que de rétablir un réseau.
C'est pourquoi la première fois qu'une compagnie aérienne exécute notre moteur, il ne touche pas aux opérations. Il fonctionne en mode fantôme : la recommandation de notre modèle se place à côté de la décision réelle du régulateur humain, et nous mesurons l'écart, jour après jour, sur les propres perturbations de la compagnie aérienne. La confiance ne s'affirme pas dans une présentation commerciale. Elle se gagne sur une feuille de comparaison, sans aucun risque opérationnel, jusqu'à ce que l'équipe des opérations décide d'elle-même que les recommandations sont meilleures que le tableau blanc.
On ne gagne pas le droit de réacheminer les pilotes de quelqu'un avec un point de référence. On le gagne en ayant raison, discrètement, aux côtés d'un humain, pendant des semaines, avant que quiconque ait à vous croire.
L'honnête vérité, c'est qu'en observant le mode fantôme, j'ai compris ce que nous vendions réellement. Pas un optimiseur. Pas de la vitesse. Nous vendions un moyen pour un responsable des opérations de faire confiance à une machine pendant la pire nuit de son année — et la confiance doit se bâtir avant la tempête, pas pendant.
Ce que valent réellement les 15 jours
Si vous dirigez l'exploitation d'une compagnie aérienne de taille moyenne, votre solveur d'équipages fonctionne parfaitement 350 jours par an. Je ne suis pas là pour prétendre le contraire. La question, c'est ce qui se passe les 15 jours où il ne fonctionne pas — et ce sont ces jours-là qui produisent les gros titres à un milliard de dollars, les audits révélant 43 % d'équipages mal affectés, et désormais, depuis octobre dernier, les remboursements automatiques en espèces décomptés à l'heure.
L'erreur que tout le secteur ne cesse de commettre — l'erreur que j'ai commise en premier, avec mon propre solveur plus rapide — c'est de traiter ces 15 jours comme un problème de vitesse à résoudre en calculant plus fort. Ils ne le sont pas. Ce sont un problème de certitude, et on ne résout pas un problème de certitude en exigeant davantage de certitude d'un monde qui est activement en train de se désagréger. On le résout en construisant quelque chose qui raisonne dans l'incertitude, répète la catastrophe avant qu'elle n'arrive, et fait ses preuves dans l'ombre avant qu'on lui accorde jamais confiance en pleine lumière. C'est le moteur que nous avons construit, et il est décrit en détail sur notre solution d'IA de planification des équipages aériens.
Quelque part cette nuit, il y a un centre de contrôle des opérations où le mur d'écrans est calme et vert, et un solveur d'équipages ronronne à travers son cycle de traitement par lots exactement comme prévu. Le travail que nous faisons est destiné à la nuit où cette salle vire au rouge — quand les téléphones s'engorgent, que les rotations se brisent plus vite que quiconque ne peut les noter, et qu'un régulateur se saisit d'un tableau blanc parce que la certitude que le logiciel exige a discrètement quitté les lieux. Tout l'enjeu est de s'assurer que, cette nuit-là, la machine raisonne encore honnêtement au sujet d'une compagnie aérienne qu'elle ne peut plus voir pleinement.
