Notre IA a réservé un hôtel qui n'existait pas — et les maths le prédisaient
La première fois que j'ai vu notre assistant de voyage confirmer un hôtel qui n'existait pas, la salle de démonstration a littéralement applaudi.
Un testeur avait demandé un éco-lodge de luxe au Costa Rica à moins de 200 $ la nuit. Le modèle a renvoyé le « Tabacon Springs Eco-Lodge » — un descriptif magnifique, un tarif nocturne plausible, un écran de confirmation. Cela se lit à merveille. C'est aussi deux établissements réels, Tabacon et Nayara Springs, fondus en un seul lieu fictif. Le Tabacon Springs Eco-Lodge n'existe pas. Si une famille s'était trouvée de l'autre côté de cet écran, elle aurait pris l'avion pour le Costa Rica et serait arrivée à une réception qui n'avait jamais entendu parler d'elle.
Ce moment résume à lui seul la raison pour laquelle la réservation de voyage par IA agentique est plus difficile qu'il n'y paraît, et c'est pourquoi je veux revenir sur ce que nous avons raté avant de bien faire. En bref : dans le voyage, une réponse fluide et une réponse vraie sont deux objets distincts, et l'écart entre les deux n'est pas un bug que l'on corrige à force d'itérations. C'est une propriété structurelle du fait d'utiliser un modèle probabiliste pour accomplir une tâche déterministe.
Un agent de voyage humain qui devine la disponibilité se fait renvoyer. Une IA qui devine est félicitée pour son ton — jusqu'à ce qu'un client se retrouve planté dans un aéroport.
Le conseil d'administration a demandé « une stratégie d'IA ». Le marché leur a donné une raison de paniquer.
Je vais planter le décor, car si vous dirigez le produit dans une agence de voyages d'affaires ou chez une OTA, vous vivez cela en ce moment même.
Entre février et avril 2026, chaque grande couche de distribution du voyage a lancé ou annoncé une réservation agentique. Sabre, PayPal et Mindtrip ont annoncé la première expérience agentique de bout en bout du secteur le 12 février — les vols généralement disponibles au T2 2026, fonctionnant sur les API Mosaic de Sabre couvrant plus de 420 compagnies aériennes et deux millions d'hôtels, avec par-dessus la base de connaissances de 6,5 millions de points de Mindtrip. La veille, le PDG de Marriott confirmait que le mode IA de Google réserverait directement chez Marriott, contournant entièrement le canal des OTA. Amadeus a intégré un assistant génératif baptisé Cytric Easy dans Microsoft Teams, développé avec Accenture. Navan continue de publier des chiffres qui font paraître lente chaque TMC historique.
Alors le directeur financier entre dans la salle et demande pourquoi vous ne « faites pas un truc d'IA comme Navan ». Et voici le piège dans lequel j'ai vu tomber des équipes intelligentes : elles entendent cette question comme sortir vite un chatbot, alors que la vraie question — la seule qui compte — est comment faire cela sans nous brûler comme Air Canada.
Les acheteurs à qui je parle ne se demandent pas s'il faut faire de la réservation agentique. Ce débat est clos. Ils demandent comment le faire sans miser l'entreprise sur l'inventaire d'une seule plateforme, et sans qu'une machine sûre d'elle mais dans l'erreur crée une responsabilité qu'ils devront personnellement assumer.
La responsabilité porte déjà un nom, et votre équipe juridique le connaît
Si vous voulez comprendre pourquoi les conseillers juridiques du voyage sont nerveux, une seule affaire suffit.
Le 14 février 2024, le Civil Resolution Tribunal de Colombie-Britannique a condamné Air Canada à verser 812,02 $ à Jake Moffatt après que son chatbot a inventé une politique de tarif de deuil rétroactif contredisant les règles tarifaires réelles de la compagnie. La défense d'Air Canada était que le chatbot constituait, en substance, une entité juridique distincte responsable de ses propres déclarations. Le tribunal a rejeté cet argument en des termes clairs : une entreprise est responsable de tout ce qui figure sur ses interfaces, que les mots proviennent d'une page web statique ou d'un modèle.
Huit cent douze dollars, c'est une erreur d'arrondi. Le précédent, non. Chaque note juridique de la travel-tech rédigée depuis cite Moffatt, et une décision plus récente a tranché dans l'autre sens sans pour autant aider les déployeurs — en janvier 2026, un tribunal de Hangzhou a restreint la responsabilité d'un fournisseur de LLM lorsqu'un utilisateur a tenté de faire exécuter la promesse d'un chatbot. Lues ensemble, les deux affaires pointent dans la même direction inconfortable : le devoir de diligence retombe sur la marque de voyage, pas sur le fournisseur du modèle. Vous ne pouvez pas externaliser la faute vers OpenAI.
Et il ne s'agit pas que d'argent. En 2025, des touristes ont grimpé à 4 000 mètres dans les Andes péruviennes à la recherche du « Canyon sacré de Humantay », un lieu qu'un planificateur d'IA avait inventé de toutes pièces. Un couple malaisien a parcouru 400 kilomètres pour emprunter un « Kuak Skyride » qui n'existe pas. Un village de Tasmanie de 33 habitants s'est mis à recevoir des appels au sujet de sources thermales qu'il n'a jamais eues. La norme ISO 31030, relative à la gestion des risques liés aux voyages, fait de la sécurité du voyageur l'obligation du déployeur — ces incidents sont précisément ce qu'elle vise à prévenir. Avec environ un quart des touristes utilisant désormais l'IA pour planifier leurs voyages, le rayon d'impact a cessé d'être théorique il y a un bon moment.
Ce que j'ai mal compris : je pensais que c'était un problème de prompt
Voici la partie dont je ne suis pas fier.
Notre première version était, honnêtement, un joli wrapper. Un modèle performant, un prompt système bien conçu, de la recherche documentaire sur un catalogue d'hôtels, une interface de conversation soignée. Cela faisait bonne impression en démo — assez bonne pour que je me surprenne à croire que les hallucinations étaient un cas limite que nous éliminerions à force de meilleurs prompts et d'un index de recherche plus vaste. Un investisseur m'a dit à peu près à cette époque de simplement utiliser GPT et d'arrêter de trop réfléchir. Pendant environ un mois, je l'ai à moitié cru.
Le moment Tabacon Springs est ce qui a brisé cette conviction, mais ce qui m'a réellement fait changer d'avis, c'est de m'asseoir et de faire le calcul que j'évitais.
Une réservation de vol réaliste comporte une dizaine d'étapes séquentielles : interpréter l'intention, rechercher, filtrer, tarifer, mettre en attente, vérifier la politique, recueillir les données du passager, transmettre au paiement, valider le PNR, émettre le billet. Supposons — généreusement — que chaque étape soit un appel à un modèle probabiliste juste 90 % du temps. De bout en bout, votre taux de réussite est de 0,9 à la puissance dix. Environ 34 %.
Vous ne pouvez pas vous sortir par des prompts d'une défaillance stochastique cumulative. L'erreur ne diminue pas à mesure que vous ajoutez des étapes. Elle se multiplie.
Puis j'ai trouvé le chiffre qui a mis fin au débat interne. Le benchmark TravelPlanner du OSU NLP Group a mesuré GPT-4, utilisant le populaire schéma ReAct, complétant des itinéraires réalistes de plusieurs jours à 0,6 %. Pas 60 %. Zéro virgule six. Six voyages réussis sur mille.
Les gens brandissent un chiffre de « 97 % » issu du même benchmark, et je veux être précis ici, car l'emprunter nous ferait passer soit pour malhonnêtes, soit pour naïfs : ces 97 % proviennent d'un solveur piloté par du code exécuté contre une base de connaissances statique et figée — des instantanés d'OpenFlights et de Yelp — et non d'un modèle réservant contre un inventaire vivant et changeant. Ce n'est pas un chiffre de réservation en production, et quiconque le cite comme tel n'a pas lu l'étude. Le chiffre honnête pour un LLM pilotant tout le flux est le petit.
C'est là qu'a eu lieu le tournant. Le problème n'a jamais été le prompt. Le problème, c'est que nous avions placé un modèle probabiliste dans le flux de contrôle, tout court.
Comment empêcher une IA de réserver un hôtel qui n'existe pas ?
Une fois que j'ai cessé d'essayer de rendre le modèle plus fiable et que j'ai commencé à essayer de le retirer des parties qui doivent être fiables, l'architecture s'est presque conçue toute seule.
La règle sur laquelle nous nous sommes arrêtés : le modèle de langage fait de la langue, et rien d'autre. Il extrait ce que veut dire un voyageur et résume les résultats en langage clair. Il n'appelle pas le GDS. Il ne vérifie pas la politique. Il ne touche pas au paiement. Chacun de ces éléments est une logique déterministe codée en dur. Nous exécutons l'orchestration comme une machine à états — LangGraph est notre plan de contrôle habituel, même si nous n'en faisons pas une religion ; si un client est installé sur AWS Bedrock AgentCore ou Vertex AI Agent Builder, nous construisons là-bas à la place.
Le détail qui compte plus que le framework, c'est l'état typé. La plupart des déploiements d'agents en production que j'ai vus meurent de la même mort silencieuse : l'état dérive discrètement d'une étape à l'autre, personne ne s'en aperçoit, et l'agent agit avec assurance sur une image corrompue du monde. Un schéma d'état strictement typé avec Pydantic — chaque champ déclaré, validé à chaque transition — est la chose peu spectaculaire qui l'empêche. Lorsqu'une réservation doit couvrir plusieurs validations, un motif saga gère le retour arrière : si l'hôtel échoue après que le vol est déjà émis, le graphe sait comment annuler et défaire plutôt que de laisser un voyageur à moitié réservé.
Nous l'avons conçu comme trois capacités, et non un seul produit, car tout acheteur n'a pas besoin de l'ensemble. Il y a l'agent de réservation déterministe — le cœur. Il y a la vérification en tant que service, une API autonome que toute équipe de travel-AI existante peut appeler pour demander « cet hôtel est-il réel, ce prix est-il à jour, ce PNR est-il réellement confirmé ? » — un garde-fou qui se place devant un wrapper que vous avez déjà déployé, ce qui constitue une réponse bien moins coûteuse lorsque le service juridique agite Moffatt dans votre comité de pilotage que de tout arracher. Et il y a une couche de politique et de conformité qui compile la politique de voyage d'entreprise ou les règles tarifaires d'une OTA en contraintes appliquées, instrumente les obligations de devoir de diligence de l'ISO 31030 et porte les exigences de transparence du règlement européen sur l'IA. Nous avons expliqué comment les trois s'articulent sur la page de solution consacrée à ce travail.
L'application des politiques doit être du code, pas un prompt. Les prompts dérivent d'une version de modèle à l'autre. Les règles métier n'en ont pas le droit.
Le chiffre que personne ne met sur la diapositive du pitch
Si je pouvais faire intégrer une seule chose à chaque équipe de voyage avant qu'elle ne lance, ce ne serait pas l'hallucination. Ce serait l'économie de la recherche.
Les fournisseurs de GDS ne facturent pas par réservation. Ils facturent par recherche de segment, généralement 3 à 3,50 $ plus environ 10 % de commission, et ils imposent des ratios look-to-book qui vous pénalisent pour les recherches spéculatives. Le groupe Lufthansa a de nouveau relevé ses frais de réservation GDS, à compter du 1er janvier 2026, sur Amadeus, Sabre et Travelport. Imaginez maintenant un agent qui lance « obligeamment » quatre recherches exploratoires par tour de conversation parce que le modèle a décidé d'être minutieux. Sur la marge commerçante de 3 à 5 % d'une OTA, cet agent brûlera le bénéfice du trimestre sur un chatbot qui ne réserve jamais rien en réalité.
C'est la ligne la plus négligée de chaque démo de voyage agentique à laquelle j'ai assisté, et c'est exactement pourquoi ces démos ne survivent pas au contact de la production. Un agent déterministe plafonne et met en cache les recherches parce que la couche d'orchestration — et non l'humeur du modèle — décide quand une recherche vaut son coût.
Et pour une TMC, cette économie se rattache directement au chiffre que le directeur financier poursuit réellement. La métrique que cette construction fait bouger, c'est le pourcentage de réservations sans intervention et le temps de traitement de la file d'attente hors ligne qui se cache derrière. Chaque réservation hallucinée ou non exécutable est un dossier qui retombe sur un agent humain — ce qui est le coût visé quand quelqu'un dans la salle dit « faites un truc d'IA comme Navan ».
Pourquoi ne pas simplement le construire sur l'API Amadeus ?
Quelques réalités que j'ai dû apprendre à la dure, et que j'aborde désormais dès le premier appel de découverte pour que personne ne soit surpris au troisième mois.
Si vous êtes une TMC qui prévoit de « simplement construire sur l'API Amadeus », vérifiez quelle clé vous avez. Le niveau Self-Service Production d'Amadeus exclut spécifiquement le point de terminaison Flight Create Orders — il est, selon leur propre formulation, conçu pour les entreprises sans certification d'agence de voyages. Pour réellement émettre des commandes, il vous faut le niveau Enterprise. J'ai vu cette seule ligne repousser une feuille de route d'un trimestre.
Puis il y a la couture que tout le monde considère comme résolue et qui ne l'est pas : le NDC face au GDS. La New Distribution Capability est excellente pour l'offre et la commande initiales, mais le service après-réservation — échanges, remboursements, réacheminement en cas d'opérations irrégulières — s'exécute toujours sur l'infrastructure GDS, même lorsque la vente d'origine était en NDC. Un agent de production a besoin des deux tuyaux, pas d'un choix binaire entre eux. Et le NDC lui-même n'est pas une chose unique : la gestion des commandes de niveau 4 via un agrégateur comme Verteil ou Duffel est une intégration différente de l'achat de niveau 3 auquel la plupart des wrappers s'arrêtent. Les IROPS sont l'endroit où l'écart devient réel — un seul événement météorologique peut bloquer des voyageurs par avions entiers, chacun coûtant de 500 à 2 000 $ à réacheminer. Un agent qui sait chercher mais ne sait pas assurer le service est un jouet.
Et si votre conception fait que l'agent émet les billets directement plutôt que de router vers un système hôte, vous voilà en territoire d'accréditation — ARC aux États-Unis, qui prend environ 25 jours une fois les prérequis remplis, ou la pleine accréditation IATA, qui peut prendre de six à douze mois. Il y a aussi un piège de paiement : dès qu'une interface de conversation collecte des données de carte, vous avez tiré toute votre pile dans le périmètre PCI. Le commerce agentique confie aujourd'hui encore l'autorisation réelle à une étape de paiement humaine, avec la tokenisation via un fournisseur comme VGS ou Checkout.com qui maintient les données de carte hors de votre environnement.
Rien de tout cela n'est dans le keynote. Tout cela est dans le rapport d'incident de production.
« Pourquoi ne pas simplement acheter celui de Sabre, ou Cytric, ou Navan ? »
On me pose sans cesse la question, et ma réponse honnête les surprend : parfois, vous devriez.
Si vous êtes une OTA de loisirs heureuse de distribuer l'inventaire de Sabre sur les rails de Sabre, la pile Sabre–PayPal–Mindtrip est un achat raisonnable — tant que vous avez accepté une offre verrouillée sur Sabre et l'absence d'une couche de politique d'entreprise ou d'instrumentation ISO 31030. Si vous êtes une entreprise Microsoft-native déjà sur Cytric et Concur, Cytric Easy dans Teams vous convient probablement, et je vous le dirai directement. Si vous voulez arracher entièrement votre TMC et exploiter une plateforme IA-native, Navan a véritablement mérité ses chiffres — 73 % de frais sans intervention, des violations de politique tombées de 35 % à moins de 5 % — et je ne vais pas prétendre que nous les battons à leur propre jeu.
Nous correspondons à un cas plus étroit et précis : vous voulez conserver vos contrats GDS existants et votre relation avec votre TMC et ajouter de l'intelligence par-dessus, de façon neutre vis-à-vis des fournisseurs, sans devenir un distributeur pour celui à qui vous avez acheté votre agent. C'est cela, la construction. Et les parties que je ne peux pas faire, je le dis à voix haute — nous ne sommes pas un agent d'émission accrédité IATA/ARC, donc l'émission passe par votre hôte ; nous ne détenons pas vos accords commerciaux GDS ; et nous ne pouvons pas corriger une politique de voyage d'entreprise ambiguë, même si nous vous aiderons à la resserrer lors de la découverte, car une politique ambiguë fait un agent ambigu, aussi bon que soit le code.
L'échéance qui referme la fenêtre
Une dernière chose sur le chrono. Les obligations de transparence du règlement européen sur l'IA pour les déployeurs entrent en vigueur le 2 août 2026, et les orientations sur la classification à haut risque sont tombées le 2 février 2026. Si votre agent parle à des consommateurs de l'UE, la divulgation n'est pas optionnelle et « on l'ajoutera plus tard » est un constat de non-conformité annoncé. Nous intégrons dès le départ l'interface de divulgation de l'article 50 et une piste d'audit de journalisation et d'explication, car greffer la transparence sur un wrapper boîte noire est bien plus douloureux que de la concevoir dès l'origine.
Voilà donc où j'en suis arrivé après tout cela. La fluidité est désormais gratuite — chaque wrapper sur le marché a l'air confiant, et un voyageur ne peut pas distinguer une vraie confirmation d'une confirmation hallucinée en la lisant. Ce qu'un voyageur peut distinguer, en fin de compte, c'est si la chambre est bien à la réception à son arrivée. Cet écart — entre une phrase qui se lit comme vraie et un PNR qui l'est vraiment — ne se referme pas parce que le modèle a grossi. Il se referme parce que quelqu'un a décidé, avant le lancement, que le modèle ne serait jamais la chose qui répond « est-ce réel ? ». La couche déterministe qui y répond est peu spectaculaire, elle passe moins bien en démo, et c'est tout le travail.
Le Tabacon Springs Eco-Lodge n'est toujours pas un lieu réel. La seule question qui compte, c'est de savoir si votre système le sait avant que votre client ne se retrouve dans le hall. Si vous voulez voir comment nous avons construit le nôtre pour qu'il le sache, l'analyse complète est ici.
