J'ai construit une IA pour battre le solveur sur la reprise d'équipages aériens. Elle a perdu, et cette défaite est devenue le produit.

Le benchmark que j'ai conçu pour gagner, et que j'ai perdu

J'ai construit la première version de StormCrew pour battre le solveur. C'était tout le discours que j'avais en tête. Le contrôle des opérations aériennes repose sur des moteurs d'optimisation vieux de plusieurs décennies, donc si je pouvais entraîner quelque chose de plus intelligent, j'aurais une histoire qui vaut d'être racontée. J'y ai passé des semaines. Puis j'ai confronté mon moteur de reprise à CBC, un solveur mature open source en nombres entiers mixtes, éprouvé sur le terrain depuis avant que je sache écrire une boucle for, et CBC a gagné. Pas d'un écart d'arrondi.

Je me souviens d'avoir fixé les deux colonnes de chiffres et d'avoir ressenti ce creux particulier qu'on ressent quand l'expérience conçue pour vous donner raison prouve au contraire que vous avez tort. Le solveur était plus rapide. Ses plans coûtaient moins cher. Il n'a jamais une seule fois renvoyé un programme irréalisable. Ma version astucieuse a perdu sur les trois critères.

Alors j'ai fait la seule chose honnête qui me venait à l'esprit. J'ai changé la revendication, pas les chiffres.

J'ai construit l'IA pour battre le solveur. Le solveur a gagné. La partie intéressante s'est révélée être tout ce que ce combat dissimulait.

Ce retournement est l'épine dorsale de ce que StormCrew est vraiment devenu, et je pense que c'est une histoire plus utile que celle que je m'étais proposé de raconter. Vous pouvez tout exécuter vous-même sur veriprajna.com/fr/demos/stormcrew-recuperation-des-equipages-irops-aeriens-en-secondes-legal-par-construction, mais laissez-moi vous expliquer ce qui m'a fait changer d'avis, parce que le pivot est tout l'intérêt.

Qu'est-ce qui casse vraiment quand une tempête cloue un hub au sol ?

Je suis retourné lire les post-mortems des effondrements après que CBC m'a humilié, et presque aucun des échecs n'était « les maths étaient légèrement sous-optimales ». Les opérations irrégulières, ce que le secteur appelle IROPS, coûtent aux compagnies aériennes environ 60 milliards de dollars par an (IATA). Le désastre canonique, Southwest en décembre 2022, a coûté environ 1,2 milliard de dollars, avec environ 16 900 annulations et à peu près 2 millions de passagers bloqués. Quand j'ai retracé comment ces journées se délitent réellement, l'optimiseur n'a jamais été le méchant.

Trois choses cassent à la place. La reprise est trop lente : quand une tempête cloue un hub au sol, la réaffectation d'équipages pour la cascade en aval reste largement une ruée manuelle de 4 à 12 heures (un benchmark sourcé, pas un chiffre inventé). Elle est trop risquée : chaque réaffectation d'équipage doit respecter FAA Part 117 pour les limites de service et de repos et, pour chaque transporteur, une CBA syndicale, et une seule violation est un événement de conformité, pas une note de bas de page. Et elle est trop opaque : la cascade de vols en aval qui viennent de perdre leur équipage reste invisible jusqu'à ce que ces vols soient déjà en cours d'annulation.

Ce dernier point, c'est ce que les outils hérités manquent, et c'est la première chose que j'ai fait afficher dans la démo. Injectez une tempête sur le hub le plus chargé et l'application met en évidence le rayon d'impact : les vols cloués au sol plus les vols en aval à un saut qui perdent leur équipage via la rotation. Dans le scénario ensemencé, ce sont 53 vols à risque sur le réseau.

Depuis la règle de remboursement automatique du DOT (oct. 2024), chaque retard en cascade de plus de 3 heures est désormais aussi un coup financier automatique. Donc le coût d'être lent, illégal ou aveugle a augmenté précisément pendant que les outils restaient les mêmes. Aucun de ces trois échecs n'est corrigé par une meilleure fonction objectif. J'optimisais la seule chose qui allait déjà bien.

Pourquoi ai-je arrêté d'essayer de battre CBC pour commencer à le nourrir ?

J'ai fait la paix avec ma défaite face à CBC en lui donnant un autre travail. Au lieu de concurrencer le solveur, je l'ai encapsulé. Le pipeline est entièrement du code réel, déterministe et ensemencé : un réseau aérien synthétique et un état des équipages, un injecteur de perturbation qui calcule le rayon d'impact par accessibilité de graphe sur la rotation, un générateur de vacations, puis CBC comme moteur qui choisit le plan, puis une comparaison fantôme contre l'inaction, puis un certificat signé.

Quand je l'exécute sur la tempête ensemencée, le générateur produit 1 762 vacations de reprise légales (dont 52 repositionnements deadhead pour déplacer les équipages là où ils sont nécessaires), plus 53 replis d'annulation, soit 1 815 colonnes candidates au total. CBC résout la partition à 1 815 variables et 115 contraintes à coût minimal jusqu'à OPTIMAL et renvoie un plan en environ 0,11 seconde. Résultat sur ce scénario : 52 vols sur 53 rééquipés (98 pour cent), 1 annulation, 34 équipages utilisés (25 de ligne et 9 de réserve).

Le problème de la compagnie aérienne n'a jamais été que le solveur était trop faible. C'était que la reprise était trop lente, trop risquée, et invisible jusqu'à ce qu'il soit trop tard.

Notez l'honnêteté de cette capture d'écran. Le moteur de reprise est CBC, nommé sur le panneau. La revendication durable n'est pas que mon code surpasse un solveur en optimisation. C'est que le plan arrive en bien moins d'une seconde là où le processus manuel sourcé prend 4 à 12 heures, et l'application mesure cet écart au grand jour. Je veux être précis sur le périmètre, parce que c'est une démo et je refuse de la faire passer pour plus que ce qu'elle est : ces chiffres exacts sont les résultats d'un seul réseau synthétique ensemencé, pas une garantie en monde ouvert. La vitesse-contre-manuel est la revendication qui voyage.

La garantie de légalité appartient au code, pas au jugement d'un modèle

J'ai une opinion ferme que je n'ai gagnée qu'en construisant ceci, alors laissez-moi la formuler clairement. Une garantie de légalité ne peut pas vivre dans le jugement d'un modèle. Elle doit vivre dans du code déterministe, par construction. La façon d'empêcher qu'une vacation d'équipage illégale ne soit jamais recommandée n'est pas d'entraîner un modèle à l'éviter, ni d'ajouter un terme de pénalité à l'objectif en espérant que l'optimiseur la contourne. C'est de rendre la vacation illégale impossible à générer dès le départ.

Donc les contraintes sont appliquées au moment de la génération, pas évaluées après. Part 117 plafonne une période de service à 780 minutes, le temps de vol à 480 minutes, et exige un sit minimal de 30 minutes ; la CBA d'exemple plafonne une vacation à 4 segments. Seules les vacations qui satisfont toutes ces contraintes deviennent des colonnes candidates. C'est du masquage d'actions. Une affectation illégale n'est pas pénalisée, elle est irreprésentable. Quoi que CBC fasse des colonnes qu'on lui remet, et quoi que le copilot optionnel dise ensuite du plan, ni l'un ni l'autre ne peut ressusciter une vacation illégale, parce qu'elle n'a jamais été dans l'ensemble.

Cela me donne un invariant au lieu d'un score : 0 affectations illégales, jamais, testées unitairement (la suite de tests est à 3/3 réussis, vérifiant que le rayon d'impact est non vide, que seules des colonnes légales sont générées, et que le plan récupéré est une partition légale). Un score, on peut le régresser. Un invariant, on peut le promettre.

C'est aussi pourquoi je ne trouve plus convaincants les discours d'« ops IA autonomes » quand l'histoire de sécurité est « le modèle a appris à ne pas ». J'ai fait confiance à un modèle pour respecter une règle dure exactement une fois pendant cette construction, tôt, et c'était bien jusqu'à l'entrée où ce ne l'était pas. Dans un domaine où une seule violation est un événement réglementaire, « généralement légal » équivaut à « pas légal ». Je préfère supprimer la possibilité plutôt que la superviser.

Que se passe-t-il le pire jour de l'année ?

J'ai failli livrer une version qui auto-approuverait n'importe quoi, et je suis content qu'un scénario m'ait arrêté. Basculez la démo sur severe, où l'événement est assez grave pour que les réserves soient épuisées et que seulement environ 30 pour cent des équipages restent. CBC trouve quand même un plan pleinement légal, en environ 0,05 seconde, toujours 0 illégal. Mais ce plan annulerait 20 vols sur 53, soit 38 pour cent du rayon, bien au-dessus du seuil d'auto-approbation de 15 pour cent de l'OCC.

La bonne décision dans ce cas n'est pas de tamponner en silence un plan qui annule plus d'un tiers du réseau touché. Donc le statut bascule sur ESCALATE, validation humaine requise, avec la raison affichée. Le plan est toujours calculé, toujours légal, toujours présenté au régulateur (33 vols récupérés, 62 pour cent du rayon). Il n'est simplement pas auto-approuvé.

La partie que la plupart des discours « autonomes » sautent, c'est de savoir quand l'action correcte est de ne pas agir, et de confier la journée à un humain.

Construire cette porte a changé mon regard sur toute la catégorie. L'escalade n'est pas l'échec du système. C'est le système qui est honnête sur une mauvaise journée. Un conseiller qui renvoie toujours une réponse confiante est facile à montrer en démo et dangereux à croire. Celui qui dit parfois « celui-ci est au-dessus de votre ligne, à vous de décider » est celui que je mettrais réellement à côté d'un régulateur à 3 h du matin.

L'artefact que je voudrais si j'étais le régulateur

Je n'ai cessé de me demander de quoi un régulateur des opérations aurait besoin le lendemain matin, et la réponse n'était pas un tableau de bord, c'était un enregistrement. Donc chaque reprise se scelle dans un recovery_plan.json signé : la perturbation, le plan choisi action par action avec équipage et vol, la clause Part 117 et CBA spécifique vérifiée par action contre son plafond, le temps d'horloge de la reprise, et les chiffres d'économies. C'est le dossier d'audit de l'OCC sur pourquoi cette reprise a été recommandée, exportable en un clic.

Il y a aussi un copilot de plan optionnel, et je veux être clair sur l'endroit où il se situe. C'est un adaptateur mince vers un LLM (Claude par défaut, fournisseur interchangeable, ou un pont local sans clé) qui explique le plan en langage clair. Il s'abstient entièrement sans clé, tout le reste tourne hors ligne et sans clé, et il vit en dehors du cœur de décision. Le masque déterministe, CBC et la porte d'escalade décident. Le modèle ne fait que narrer après coup. Je l'ai placé là délibérément, parce que dès que le modèle de langage influence si une vacation est légale, j'ai perdu la garantie que toute la construction m'a permis d'obtenir.

Sur les économies, la même discipline s'applique. Sur le scénario normal, la comparaison fantôme montre 52 annulations évitées et environ 2,37 M$ d'exposition aux remboursements DOT évités (un modèle à 300 $ par passager) contre l'inaction. C'est le cadrage le plus flatteur possible, parce que la ligne de base est de bloquer tout le rayon d'impact, et c'est étiqueté comme illustratif de ce seul scénario. Ce n'est pas un titre, et ce n'est certainement pas la preuve que mon code surpasse quoi que ce soit en optimisation. J'ai perdu cet argument face à CBC dès le premier jour. Je ne vais pas le regagner discrètement dans un chiffre marketing.

Alors, que signifie réellement « augmenter, ne pas remplacer » ?

Je pensais autrefois que l'augmentation était le choix timide, ce qu'on dit quand on ne peut pas construire l'audacieux. Je pense le contraire maintenant. L'acheteur ici possède déjà une bonne pile de solveurs, Jeppesen ou IBS, et ne peut tolérer le rip-and-replace, le lock-in, ou une recommandation inexpliquée le pire jour de son année. Dire à cet acheteur « jetez tout pour mon modèle plus intelligent » n'est pas audacieux, c'est une affirmation que j'ai déjà réfutée pour moi-même avec un benchmark.

Ce que je peux honnêtement offrir, c'est la couche opérationnelle autour du solveur auquel ils font déjà confiance. Rendre la cascade visible avant qu'elle ne morde. Rendre les mouvements illégaux impossibles à générer plutôt que simplement découragés. Compresser les heures en secondes. Et savoir quand la journée est assez mauvaise pour que la bonne réponse soit d'escalader, pas d'auto-approuver. Tout dans la démo est synthétique et ensemencé, le réseau, les équipages, la perturbation, les chiffres en dollars, aucune donnée réelle de compagnie nulle part. Ce qui est réel, c'est le mécanisme, et vous pouvez le voir tourner de bout en bout sur veriprajna.com/fr/demos/stormcrew-recuperation-des-equipages-irops-aeriens-en-secondes-legal-par-construction.

Et si vous préférez le voir plutôt que de lire ma description, voici le tout qui tourne de bout en bout.

Voici la question que je n'ai pas cessé de retourner depuis que CBC m'a battu. Quand le solveur avec lequel vous rivalisez est déjà bon, et que l'acheteur le possède déjà, ce qu'il reste à construire n'est pas une meilleure réponse. C'est une meilleure relation avec la réponse : plus rapide, prouvablement légale, visible, et assez humble pour escalader. Alors, quelle part de l'IA qu'on vous vend cette année résout réellement la partie difficile, et quelle part résout à nouveau la partie qui n'a jamais été cassée ?