Southwest Airlines a perdu la trace de ses propres pilotes. C'est là que j'ai compris que les chatbots ne sauveraient pas la logistique.

L'appel téléphonique qui a changé ma façon de penser à l'IA ne venait ni d'un client ni d'un investisseur. Il venait d'un ami — un pilote — qui a passé Noël 2022 à dormir sur le sol de l'aéroport international de Denver.

Il n'était pas bloqué à cause de la météo. La tempête était passée. Il était bloqué parce que Southwest Airlines avait littéralement perdu la trace de l'endroit où il se trouvait. Le système de planification des équipages de la compagnie — un optimiseur hérité appelé SkySolver — calculait des plans de reprise à partir de positions d'équipage vieilles de plusieurs heures. Il générait des horaires pour une compagnie aérienne fantôme. Mon ami a appelé la ligne d'assistance de planification et est resté en attente pendant huit heures. Le temps que quelqu'un décroche, l'horaire qu'ils venaient de calculer était déjà de nouveau erroné.

Cette semaine-là, Southwest a annulé plus de 16 900 vols. Deux millions de passagers se sont retrouvés bloqués. La compagnie a perdu plus d'un milliard de dollars. Et voici la partie qui m'a hanté : toutes les autres grandes compagnies aériennes américaines ont affronté la même tempête, les mêmes pistes gelées, les mêmes pénuries de personnel. United, Delta, American — elles se sont toutes rétablies en 48 heures. Southwest a sombré pendant une semaine entière.

Je revenais sans cesse à une seule question : pourquoi le logiciel d'une compagnie aérienne s'est-il effondré alors que les autres ont plié puis se sont rétablis ? La réponse, je l'ai découvert, n'avait rien à voir avec la météo et tout à voir avec la manière dont nous construisons les cerveaux informatiques des opérations complexes depuis trente ans. C'est cette prise de conscience qui m'a conduit à créer Veriprajna — et à écrire cet article de recherche qui expose l'intégralité de l'argumentation technique.

Mais la version courte est celle-ci : nous optimisons la logistique pour l'efficacité dans un monde qui ne récompense plus l'efficacité. Nous construisons des systèmes qui trouvent la réponse la moins chère à une question connue, alors que ce dont nous avons réellement besoin, ce sont des systèmes qui trouvent une réponse viable à une question inconnue.

La topologie qui a tué Noël

Pour comprendre pourquoi Southwest s'est effondrée, il faut comprendre un concept de la théorie des graphes — et je vous promets que c'est plus intéressant que ça n'en a l'air.

Delta, United et American exploitent des réseaux en étoile (hub-and-spoke). Les vols rayonnent depuis des hubs centraux comme Atlanta ou Newark. Si une tempête frappe le Nord-Est, une compagnie en étoile peut « cloisonner » les dégâts — annuler tous les vols à destination de Newark pour une matinée, réinitialiser le sous-graphe et reprendre. Les équipages et les avions repassent fréquemment par le hub, créant des points de reprise naturels.

Southwest a été pionnière d'un modèle différent : le point à point. Un avion et son équipage volent selon une chaîne linéaire — Baltimore vers Denver vers San Diego vers Phoenix vers Sacramento. Économiquement brillant. On tire davantage d'heures de vol de chaque appareil. Mais mathématiquement ? C'est un château de cartes. Un retard sur le premier tronçon n'affecte pas seulement le retour — il se propage en cascade tout au long de la chaîne. L'équipage censé voler de San Diego à Phoenix est coincé à Denver. L'avion qui les attend à San Diego reste immobilisé.

En termes de théorie des graphes, le diamètre du graphe de dépendances dans un réseau point à point est bien plus grand que dans un réseau en étoile. Le rayon d'impact d'une seule perturbation n'est pas contenu.

Je me souviens de la nuit où j'ai cartographié cela pour la première fois sur un tableau blanc dans notre bureau. Mon équipe et moi débattions de la question de savoir si l'échec de Southwest était un problème de logiciel ou un problème de conception de réseau. L'un de mes ingénieurs, agacé par mon insistance à dire que c'était les deux, a récupéré les données de vol réelles et a commencé à dessiner les chaînes de dépendances. Nous avons regardé la cascade se dérouler sur la carte. Un retard à Baltimore s'est propagé à Denver, ce qui a rompu une correspondance vers San Diego, ce qui a bloqué un équipage censé voler vers Phoenix, ce qui…

« Ce n'est pas une chaîne », a-t-il dit. « C'est une fracture. »

Il avait raison. Et la fracture était invisible pour le logiciel censé la réparer.

Pourquoi SkySolver a-t-il calé ?

SkySolver repose sur les mêmes fondements mathématiques qui alimentent la plupart des optimisations logistiques : la programmation linéaire en nombres entiers mixtes et une technique appelée génération de colonnes. Ce sont les chevaux de trait de la recherche opérationnelle, la discipline qui régit la façon dont nous déplaçons les atomes à travers le monde depuis les années 1950.

Voici comment cela fonctionne en clair : le système prend un instantané du monde — où se trouve chaque membre d'équipage, quel est le statut de chaque avion — fige le temps et calcule la manière mathématiquement la moins chère de couvrir tous les vols. Pour une grande compagnie aérienne assurant 4 000 vols quotidiens, le nombre de combinaisons possibles équipage-vol est pratiquement infini. La génération de colonnes gère cela en générant itérativement des combinaisons « prometteuses » et en resserrant la recherche.

C'est élégant. C'est puissant. Et cela comporte une hypothèse fatale ancrée dans son ADN : le monde reste immobile pendant qu'il réfléchit.

En temps normal, un cycle de résolution de 30 à 60 minutes convient parfaitement. Mais pendant l'effondrement, l'état du réseau de Southwest changeait toutes les quelques minutes. Les équipages ne pouvaient pas signaler leurs positions parce que les lignes téléphoniques étaient saturées. Les données qui alimentaient SkySolver étaient périmées de plusieurs heures. Le système optimisait un monde qui n'existait plus.

Quand le rythme des perturbations dépasse la vitesse de l'information, l'optimisation ne se dégrade pas en douceur. Elle s'effondre.

C'est ce que j'appelle l'écart d'optimisation-exécution — le décalage mortel entre la vitesse à laquelle un solveur peut calculer et la vitesse à laquelle la réalité évolue. Et ce n'est pas propre aux compagnies aériennes. J'ai vu le même schéma de défaillance dans la logistique portuaire, la régulation ferroviaire et les chaînes d'approvisionnement industrielles. Les mathématiques sont les mêmes. La fragilité est la même.

Le moment où j'ai cessé de croire aux chatbots pour la logistique

Environ six mois après la crise de Southwest, j'étais assis en réunion avec un investisseur qui m'a dit, avec une confiance totale : « Utilisez simplement GPT. Affinez-le sur des données de planification. Problème résolu. »

J'ai essayé d'expliquer pourquoi cela ne fonctionnerait pas. Il m'a interrompu : « Mais il sait raisonner. Je l'ai vu résoudre des problèmes de maths. »

Cette conversation a cristallisé quelque chose que je peinais à formuler. Toute l'industrie commettait une erreur de catégorie — confondant l'aisance linguistique des grands modèles de langage avec le raisonnement opérationnel requis pour gérer des systèmes complexes. Des fournisseurs inondaient le marché de « copilotes IA » qui plaquaient une interface de conversation sur des solveurs hérités. Un régulateur demande : « Comment récupère-t-on l'horaire de Denver ? » et le LLM traduit cela en un appel d'API vers le même optimiseur défaillant en dessous.

C'est une nouvelle couche de peinture sur un moteur grippé.

Voici le problème fondamental : les LLM sont des moteurs probabilistes conçus pour prédire le prochain token dans une séquence. Ils imitent la forme du raisonnement sans posséder de modèle du monde. En termes de sciences cognitives, ce sont d'immenses moteurs du Système 1 — une reconnaissance de motifs rapide et intuitive. L'optimisation logistique est une tâche du Système 2 — une vérification lente, réfléchie et pas à pas des contraintes.

Et le problème des contraintes est là où cela devient dangereux. En écriture créative, une exactitude de 99 % est excellente. En planification d'équipage, une exactitude de 99 % est illégale. Si un LLM génère un horaire qui affecte un pilote disposant de 7 heures et 59 minutes de repos à un vol en exigeant 8, l'ensemble de l'horaire est invalide. Les LLM ne gèrent pas naturellement la nature strictement binaire des contraintes de faisabilité. Ils privilégient la cohérence linguistique sur l'exactitude logique.

Un chatbot capable d'expliquer un horaire n'est pas la même chose qu'un agent capable d'en réparer un.

Les tests de référence sur des problèmes combinatoires comme le problème du voyageur de commerce le confirment à grande échelle. À mesure que le nombre de nœuds augmente, les LLM « visitent » des villes deux fois, en sautent complètement d'autres et perdent le fil de l'état sur de longues séquences. Ils ne peuvent pas simuler des futurs ramifiés ni revenir en arrière. Ils sont aveugles à l'effet papillon — la réalité selon laquelle une petite décision de planification prise maintenant peut provoquer une catastrophe trois jours plus tard.

Ce qui fonctionne vraiment : apprendre à une IA à penser en graphes

Alors si les solveurs hérités sont trop lents et les LLM trop peu fiables, que construire ?

C'est la question à laquelle mon équipe et moi avons consacré des années, et l'architecture à laquelle nous sommes parvenus repose sur l'apprentissage par renforcement sur graphes — une fusion des réseaux de neurones sur graphes (pour comprendre la topologie du réseau) et de l'apprentissage par renforcement (pour apprendre des politiques de décision dynamiques). Nous sommes passés du calcul d'un horaire à l'apprentissage de la façon de planifier.

L'intuition qui a tout débloqué était d'une simplicité trompeuse : les réseaux logistiques ne sont pas des feuilles de calcul. Ce sont des graphes. Les aéroports sont des nœuds. Les vols sont des arêtes. Les entrepôts sont des nœuds. Les camions sont des arêtes. Les architectures d'apprentissage automatique traditionnelles — celles conçues pour les images ou le texte — peinent avec cette structure relationnelle. Les réseaux de neurones sur graphes en sont l'architecture native.

Nous utilisons des réseaux d'attention sur graphes (Graph Attention Networks) pour encoder l'état de l'ensemble du réseau logistique. Chaque entité — pilote, avion, aéroport — devient un nœud doté d'un plongement à haute dimension qui capture à la fois des propriétés statiques (type d'appareil, qualifications d'équipage) et un état dynamique (retard actuel, statut de maintenance, fatigue accumulée). Les connexions entre eux transportent des informations sur la durée du vol, le risque météorologique et les affectations d'équipage.

La magie réside dans ce qu'on appelle le passage de messages. Quand un blizzard ferme Denver, le GNN met à jour le plongement de Denver. Cette mise à jour circule le long de chaque arête connectée — chaque vol entrant, chaque affectation d'équipage. Un pilote à Baltimore se préparant à voler vers Denver reçoit un « signal de risque » dans son plongement avant même de décoller. Le système voit la connectivité. Il comprend le rayon d'impact. Ce type de conscience topologique est impossible dans les représentations de données plates et tabulaires qu'utilisent les systèmes hérités.

Au-dessus de cette couche de perception du graphe, nous exécutons des agents d'apprentissage par renforcement. Un agent RL observe l'état, prend une action (échanger un équipage, annuler un vol, retarder un départ, transférer un équipage à vide vers une nouvelle position) et reçoit une récompense. Au fil de millions d'itérations d'entraînement, il apprend une politique qui maximise les résultats à long terme.

Cette expression — long terme — est déterminante. Une heuristique pourrait dire : « N'annulez pas ce vol, il fait perdre du revenu. » Notre agent RL apprend : « Si je n'annule pas ce vol, l'équipage se retrouve coincé à Denver, et je perds dix vols demain. Annule-le maintenant. » Il apprend le sacrifice stratégique au service de la survie systémique.

Comment entraîner une IA à des catastrophes qui ne se sont pas encore produites ?

On ne peut évidemment pas entraîner un agent d'apprentissage par renforcement sur une compagnie aérienne en activité. Les essais-erreurs dans le monde réel coûtent des millions et créent des risques de sécurité. C'est là qu'intervient le jumeau numérique — et je ne parle pas d'un tableau de bord avec un rendu 3D d'un aéroport.

Nos jumeaux numériques sont des moteurs de transition d'états. Nous modélisons chaque appareil avec des cycles de maintenance propres à son immatriculation, chaque porte d'embarquement, chaque membre d'équipage avec des compteurs de fatigue individuels et des états contractuels. Nous numérisons le règlement — la partie 117 de la FAA, les conventions syndicales, les manuels de maintenance. Chaque transition d'état est vérifiée par rapport à ces règles.

Puis nous injectons le chaos.

Nous utilisons des générateurs stochastiques pour simuler 10 000 ans d'opérations en une semaine. Nous créons des super-tempêtes, des immobilisations mécaniques massives, des grèves. Nous démarrons les agents sur des journées faciles — temps ensoleillé, horaires légers — puis nous augmentons progressivement la difficulté, en introduisant des défaillances en cascade qui feraient passer l'effondrement de Southwest pour un léger désagrément.

Je me souviens de la première fois où nous avons fait passer la crise de Southwest de décembre 2022 dans notre simulateur. Nous avions construit une réplique du solveur hérité pour servir de référence. Le solveur hérité a fait exactement ce qu'a fait SkySolver — il a calé sur la latence des données, a optimisé pour le mauvais état et a produit le même enchevêtrement d'équipages bloqués. Temps de reprise : sept jours simulés.

Notre agent GRL a fait quelque chose qu'aucun de nous n'attendait. Il a détecté le schéma de fracture point à point émergeant à Denver des heures avant la cascade complète. Puis il a exécuté ce que nous appelons désormais une stratégie de cloisonnement préventif — il a annulé 20 % des vols à destination de Denver tôt, piégeant la perturbation localement, et a transféré des équipages à vide vers Phoenix pour créer une base opérationnelle secondaire.

Le réseau de la côte Est est resté opérationnel à 95 %. Le total des annulations a chuté de 66 %. L'effondrement a été contenu à une perturbation régionale.

Mon ingénieur — le même qui avait dessiné la fracture sur le tableau blanc — a simplement fixé l'écran. « Il a sacrifié Denver pour sauver le réseau », a-t-il dit. « Aucun régulateur humain n'aurait eu le cran de faire ça à 6 heures du matin le 22 décembre. »

Il avait raison. Et c'est bien là le point. L'agent avait « vécu » des milliers de crises en simulation. Il avait exploré les confins de l'espace des états où les solveurs hérités s'effondrent, et il avait appris à quoi ressemble la survie. Pour le détail technique complet de l'architecture — les plongements GAT, la boucle d'entraînement PPO, le masquage d'actions — j'ai publié l'intégralité de la recherche.

Et le problème de la boîte noire ?

Les gens objectent toujours ici, et ils ont raison. « Vous me dites de confier le contrôle des opérations d'une compagnie aérienne à un réseau de neurones ? Comment savoir qu'il n'hallucinera pas un horaire illégal ? »

C'est l'objection la plus importante en matière d'IA critique pour la sécurité, et quiconque la balaie n'est pas sérieux. Voici comment nous la résolvons.

Nous ne laissons jamais le réseau de neurones produire directement la décision finale. Nous utilisons ce que nous appelons une architecture en sandwich — inspirée du cadre NICE pour la programmation en nombres entiers guidée par l'apprentissage par renforcement. La couche neuronale (notre agent GRL) analyse l'état complexe et bruité et propose une distribution de probabilité sur les actions. Ensuite, une couche symbolique déterministe — un moteur de contraintes qui encode chaque règle stricte de l'exploitation — applique un masque. Si le réseau de neurones suggère une action qui viole une réglementation (un pilote dépasse ses heures de service, un appareil vole avec un point de maintenance ouvert), la couche symbolique ramène à zéro la probabilité de cette action.

Le système ne peut pas exécuter une action illégale. Pas « ne le fera probablement pas ». Ne peut pas.

Cela nous donne quelque chose de remarquable : l'optimalité des politiques d'IA apprises avec les garanties de sécurité de la logique formelle. Et cela résout aussi le problème computationnel par l'autre bout. Au lieu que le solveur hérité explore un milliard de possibilités, le réseau de neurones élague l'arbre pour ne garder que les dix branches les plus prometteuses. Le solveur n'a plus qu'à valider et affiner ces quelques options. Le temps de calcul passe de plusieurs heures à quelques secondes.

Il ne s'agit pas seulement des compagnies aériennes

L'effondrement de Southwest en est l'exemple le plus spectaculaire, mais la fragilité qu'il a révélée est universelle. Nous adaptons la même architecture GRL + jumeau numérique aux ports maritimes et aux réseaux ferroviaires.

Dans les ports, un navire retardé manque son créneau de poste à quai, les grues sont réaffectées, et les camions programmés pour l'enlèvement de conteneurs font la queue pendant des heures. Nous déployons une IA agentique où un « agent de mouillage » négocie avec un « agent de terminal » en temps réel, lissant les pics et les creux de congestion des portes à mesure que les perturbations se déploient.

Dans le ferroviaire, où les goulots d'étranglement à voie unique font qu'une seule mauvaise décision de « croisement » peut paralyser des trains à des centaines de kilomètres, nos agents GRL surpassent les régulateurs humains et les règles heuristiques de 15 à 20 % en réduction des retards. Ils font des choix contre-intuitifs — retenir un train de marchandises tôt pour dégager la voie à un train express situé 80 kilomètres en amont — qu'aucun système à base de règles n'envisagerait.

Le schéma est toujours le même : un réseau complexe, des contraintes strictes, des perturbations en cascade et une fenêtre de décision qui se mesure en minutes. Les solveurs hérités ne peuvent pas suivre. Les LLM ne peuvent pas raisonner à ce sujet. L'apprentissage par renforcement sur graphes le peut.

Le vrai retour sur investissement n'est pas l'efficacité — c'est la survie

L'effondrement d'une semaine de Southwest a coûté 1,2 milliard de dollars. Ce seul événement a effacé des années de gains d'efficacité tirés de l'exploitation d'un réseau point à point rationalisé. Un canal de Suez bloqué coûte à l'économie mondiale des milliards par jour. Le risque extrême — l'événement catastrophique, « une fois par décennie », qui semble désormais se produire chaque année — n'est plus une note de bas de page dans le registre des risques. Sur un horizon de dix ans, il en est le principal facteur de coût.

Nos agents génèrent des économies de coûts opérationnels de 2 à 5 % en temps normal grâce à une gestion plus intelligente des marges et à une réduction des heures supplémentaires des équipages. Cela relève du minimum requis. La vraie valeur réside dans ce qui ne se produit pas : l'effondrement qui reste contenu à une perturbation régionale, la cascade qui est cloisonnée avant d'atteindre la côte Est, la semaine à un milliard de dollars qui ne se matérialise jamais.

L'efficacité est une stratégie pour un monde stable. Nous ne vivons plus dans un monde stable.

L'ère des mathématiques statiques est révolue

J'ai commencé cet essai avec un pilote dormant sur le sol de l'aéroport international de Denver. Il vole toujours pour Southwest. La compagnie a depuis investi massivement dans la modernisation de ses systèmes. Mais le problème plus profond — la dépendance à l'échelle du secteur à des solveurs déterministes conçus pour un monde de perturbations prévisibles — reste largement ignoré.

La ruée vers l'IA générative comme sauveur de la logistique m'inquiète plus que les systèmes hérités. Au moins, ceux qui faisaient tourner SkySolver en connaissaient les limites. Ceux qui déploient des surcouches de LLM par-dessus des optimiseurs défaillants, souvent non. Ils voient un texte fluide et le prennent pour du raisonnement opérationnel. Ils voient un chatbot capable d'expliquer un horaire et supposent qu'il peut en réparer un.

Construire Veriprajna m'a appris que la partie la plus difficile de ce travail n'est pas les mathématiques — c'est l'argumentation. Convaincre une industrie que les outils auxquels elle fait confiance depuis des décennies ont un plafond structurel. Que la nouveauté clinquante (l'IA générative) vise le mauvais problème. Que la vraie solution exige de repenser la logistique comme un graphe, la perturbation comme un signal d'apprentissage, et la résilience comme quelque chose pour lequel on s'entraîne — non quelque chose que l'on espère.

L'avenir de la logistique n'appartient pas aux systèmes qui trouvent le plan le moins cher pour un monde connu. Il appartient aux systèmes qui trouvent un plan viable pour un monde inconnu. Ce n'est pas un peut-être. C'est ce que nous construisons.