Votre agent de voyage IA vous ment — et vous ne le saurez qu'une fois bloqué à l'étranger

Une femme nous a écrit l'an dernier en joignant une capture d'écran. Elle avait utilisé un planificateur de voyage par IA très populaire pour réserver un séjour en famille au Costa Rica. L'IA lui avait recommandé un endroit qui s'appelait quelque chose comme « Tabacon Springs Eco-Lodge » — des descriptions luxuriantes, un prix inférieur à 200 $ la nuit, des photos qui semblaient correspondre. Elle a réservé des vols pour quatre personnes. Loué une voiture. Dit à ses enfants qu'ils allaient voir des singes depuis une cabane dans les arbres.

Le lodge n'existait pas.

Pas « il était fermé » ni « il était en rénovation ». Il n'existait tout simplement pas. L'IA avait mélangé des détails de deux ou trois vrais complexes hôteliers costariciens — le nom de l'un, les équipements d'un autre, le niveau de prix d'une auberge de jeunesse un peu plus loin — et les avait assemblés en un unique établissement magnifiquement décrit qui n'avait jamais été construit. Le lien de réservation menait à une page de paiement générique qui a débité sa carte sans rien fournir.

Quand j'ai lu cet e-mail, je n'ai pas ressenti de surprise. J'ai ressenti de la reconnaissance. Parce que mon équipe chez Veriprajna avait passé des mois à observer exactement ce mode de défaillance, à le décortiquer, à comprendre pourquoi il se produit au niveau architectural. Et la réponse est à la fois simple et profondément dérangeante pour quiconque construit des produits d'IA dans le voyage : les systèmes d'IA les plus populaires du secteur sont optimisés pour paraître corrects, pas pour l'être. Cette distinction est subtile dans un générateur de poésie. Dans la logistique du voyage, c'est la différence entre des vacances et une catastrophe.

Pourquoi votre IA invente-t-elle des hôtels qui n'existent pas ?

Voici ce que la plupart des gens ne comprennent pas au sujet des grands modèles de langage — GPT-4, Claude, Gemini, tous. Ils ne « savent » pas les choses de la façon dont une base de données les sait. Un système de réservation d'hôtel sait que la chambre 412 du JW Marriott est réservée du 3 au 7 mars. C'est un fait, stocké dans une ligne, interrogeable.

Un LLM ne fonctionne pas ainsi. Il prédit le mot suivant d'une séquence à partir de motifs statistiques présents dans ses données d'entraînement. Quand vous lui demandez un « éco-lodge de luxe au Costa Rica à moins de 200 $ », il active des grappes d'associations — « Costa Rica » fait remonter « luxuriant », « forêt tropicale », « éco-lodge ». Il se met à générer du texte statistiquement susceptible de suivre ces mots. Et quand il doit nommer l'établissement ? Il mélange. Il prend des fragments de milliers d'avis qu'il a vus et les compose en quelque chose qui sonne plausible.

Dans l'écriture créative, ce mélange s'appelle l'imagination. Dans le voyage, cela s'appelle une hallucination. Et le modèle n'a aucun moyen de faire la différence.

Le modèle optimise la cohérence, pas l'exactitude. Il est conçu pour produire une réponse qui ressemble à une réponse valide, pas une réponse qui est une réponse valide vérifiée par rapport à un inventaire en temps réel.

Ce qui aggrave les choses, c'est la façon dont ces modèles sont entraînés. Pendant l'apprentissage par renforcement à partir de retours humains (RLHF), les évaluateurs humains préfèrent systématiquement les réponses complètes et assurées aux réponses qui disent « je ne sais pas ». Le modèle apprend donc, à un niveau profond, que deviner avec assurance est récompensé et qu'admettre son ignorance est pénalisé. Un agent de voyage humain qui devine les disponibilités se fait licencier. Une IA qui devine les disponibilités est félicitée pour sa « fluidité » — jusqu'à ce que le client atterrisse dans un pays étranger sans nulle part où dormir.

La nuit où j'ai compris que la fluidité est le problème

Il y a un moment sur lequel je reviens sans cesse. Nous testions un prototype précoce — pas un produit que nous avons commercialisé, mais une expérience interne pour comprendre comment les LLM gèrent les requêtes de voyage. Je lui ai demandé de me trouver un hôtel près de Central Park à moins de 250 $ la nuit pendant la Fashion Week à New York.

Il est revenu avec trois options. Des descriptions détaillées. Des prix. Des équipements. L'une d'elles mentionnait même un bar sur le toit avec vue sur le parc. Le langage était si soigné, si précis, que mon premier réflexe a été de cliquer sur « réserver ».

Puis l'un de mes ingénieurs — un gars plutôt discret, très méthodique — a lancé la même requête sur l'API Amadeus Hotel Search. Deux des trois hôtels existaient mais n'avaient aucune disponibilité pendant la Fashion Week. Le nom du troisième hôtel ressemblait à celui d'un établissement réel mais ne correspondait à aucun identifiant d'hôtel dans le système. Le bar sur le toit ? Il appartenait à un hôtel complètement différent, six pâtés de maisons plus loin.

C'est cette nuit-là que j'ai compris que le danger n'est pas une IA qui échoue de façon évidente. Un chatbot qui dit « je ne comprends pas votre question » est agaçant mais inoffensif. Le danger, c'est une IA qui comprend parfaitement votre question et répond par une information éloquente, persuasive et factuellement fausse. Nous avons commencé à appeler cela la « vallée de l'étrange » de la fiabilité — l'intelligence verbale du système est si élevée que les utilisateurs baissent leur garde sur la vérification des faits.

L'affaire du chatbot d'Air Canada a rendu cela concret sur le plan juridique. Un chatbot a halluciné une politique de remboursement. Le tribunal a jugé que la compagnie aérienne était responsable — pas le fournisseur de l'IA, pas le chatbot en tant qu'« outil bêta ». L'entreprise qui avait déployé l'agent était responsable des affirmations de l'agent. Si votre IA promet une suite avec vue sur mer à 200 $ et que le GDS n'a qu'une chambre standard à 400 $, vous pourriez être tenu de payer la différence. Ou pire, pour le voyage gâché.

Que se passe-t-il quand on traite le LLM comme le cerveau plutôt que comme la bouche ?

Après cette nuit de tests, mon équipe a eu une longue discussion. Le genre où les gens dessinent sur des tableaux blancs et se coupent la parole. La question était simple : essayons-nous de rendre le LLM plus exact, ou changeons-nous entièrement l'architecture ?

Un camp voulait de meilleurs prompts, davantage de garde-fous, de la génération augmentée par récupération. Affiner le modèle sur des données de voyage. L'autre camp — celui où j'ai fini par me ranger — soutenait que le problème n'était pas la connaissance du modèle. Le problème était le rôle du modèle. Nous demandions à un générateur de texte de faire le travail d'un gestionnaire d'inventaire. C'est comme demander à un romancier de diriger une compagnie aérienne. Il peut décrire magnifiquement l'expérience de voler, mais il ne peut pas vous dire s'il reste une place sur le vol de 8 h pour Heathrow.

Nous avons donc pris une décision qui a changé tout ce que nous avons construit par la suite : le LLM ne serait jamais la source de l'information de voyage. Il serait le routeur de l'intention.

L'utilisateur dit « Trouve-moi un hôtel près de Central Park ». Le rôle du LLM est de comprendre cette intention, de la décomposer en paramètres structurés — lieu, plage de dates, budget, préférences — et de transmettre ces paramètres à un outil qui interroge un inventaire réel. L'outil renvoie des données concrètes. Le second rôle du LLM est de présenter ces données en langage naturel. Mais il ne génère jamais les données. Il les traduit.

Nous avons cessé de construire une IA qui parle de voyage. Nous avons commencé à construire une IA qui fait le voyage — qui interroge de vrais systèmes, interprète de vrais codes de statut, et ne confirme que ce qu'elle peut vérifier.

C'est le passage de ce que le secteur appelle un « LLM Wrapper » à un système d'IA agentique. Et la différence n'est pas incrémentale. C'est un changement d'espèce. J'ai écrit en détail sur cette architecture dans la version interactive de nos recherches.

Le modèle orchestrateur-travailleur : pourquoi un seul agent ne suffit pas

Au début, nous avons essayé de tout faire passer par un seul agent. Un seul prompt gérant les vols, les hôtels, les locations de voiture, les restrictions alimentaires, les politiques de voyage d'entreprise. Il s'est effondré sous son propre poids. La fenêtre de contexte se remplissait. Les instructions entraient en conflit. L'agent réservait un hôtel avant de confirmer les dates de vol, puis devait tout défaire.

Nous avons donc construit ce que nous appelons le modèle orchestrateur-travailleur. Voyez-le comme un consultant en voyages chevronné qui ne touche jamais un clavier, dirigeant une équipe de spécialistes qui font chacun une seule chose extrêmement bien.

L'orchestrateur est un modèle à fort raisonnement — GPT-4o ou Claude 3.5 Sonnet — qui parle à l'utilisateur, tient l'historique de la conversation et décide de ce qui doit se produire. Il ne touche pas directement au GDS. En dessous se trouvent des travailleurs spécialisés : un travailleur Vols qui parle les API Amadeus Air et comprend les codes IATA, un travailleur Hôtels qui parle les Content Services for Lodging de Sabre et connaît la différence entre un acompte et une garantie, un travailleur Politique qui vérifie les règles de voyage d'entreprise avant que quoi que ce soit ne soit présenté.

Quand un utilisateur dit « Réserve un vol pour New York mardi prochain et un hôtel près de Central Park », l'orchestrateur décompose cela en deux tâches, identifie que la recherche d'hôtel dépend de l'heure d'arrivée du vol, lance d'abord le travailleur Vols, puis le travailleur Hôtels avec les bonnes dates. Si le travailleur Hôtels échoue, l'orchestrateur présente quand même les options de vol et demande si l'utilisateur souhaite réessayer avec d'autres critères d'hôtel. Rien ne plante. Rien n'hallucine.

L'idée clé était de séparer la réflexion de l'action. L'orchestrateur réfléchit. Les travailleurs agissent. Et aucun des deux ne prétend être l'autre.

Pourquoi le « 200 OK » a failli nous berner

Voici une anecdote qui me fait encore grimacer. Nous étions en plein test d'intégration avec les API de réservation de Sabre. Notre travailleur Hôtels envoyait une demande de réservation, recevait en retour une réponse HTTP 200 — ce qui, en développement web, signifie « succès » — et la transmettait à l'orchestrateur. L'orchestrateur disait alors à l'utilisateur : « C'est réservé ! »

Sauf que ça ne l'était pas. Pas toujours.

Il nous a fallu un temps embarrassamment long pour repérer cela. La réponse HTTP était 200 parce que le message avait été livré avec succès. Mais à l'intérieur du corps de la réponse, le code de statut du segment GDS était UC — Unable to Confirm (impossible à confirmer). L'hôtel avait rejeté la demande, généralement parce que la disponibilité en cache était périmée. La chambre s'était vendue dans les millisecondes séparant la recherche et la tentative de réservation.

Le décalage entre la couche transport et la couche application est un piège classique, et nous sommes tombés dedans en plein. Un 200 OK au niveau HTTP disait « votre message est arrivé ». Un UC au niveau du GDS disait « votre réservation a échoué ». Notre système lisait l'enveloppe et ignorait la lettre à l'intérieur.

C'est à ce moment-là que nous avons mis en place ce que je considère aujourd'hui comme l'élément le plus important de notre architecture : la boucle de vérification. Chaque réponse de réservation passe par une étape de vérification distincte — soit un contrôle de code déterministe, soit un prompt spécialisé jouant le rôle d'auditeur qualité — avant qu'une quelconque confirmation ne parvienne à l'utilisateur. La règle est absolue :

Un agent IA n'est jamais autorisé à émettre un message de confirmation à moins d'avoir analysé le code de statut spécifique du segment GDS et de l'avoir validé comme HK — Holding Confirmed (réservation confirmée). Tout le reste est un échec, quoi que dise l'en-tête HTTP.

HK signifie que l'inventaire est sécurisé. UC signifie que l'hôtel vous a rejeté. NN signifie que la demande est en attente — ne promettez rien encore. NO signifie qu'aucune action n'a été prise. Ces codes font la différence entre une chambre réservée et un voyageur laissé en plan, et la plupart des systèmes de voyage par IA ne les analysent même pas.

Pour le détail technique complet de notre gestion des codes de statut et de notre architecture de vérification, consultez notre document de recherche.

Comment un agent IA gère-t-il « la chambre vient d'être vendue » ?

C'est là que les systèmes agentiques prouvent leur valeur. L'écart « Look-to-Book » est endémique dans le voyage — vous cherchez, vous voyez une disponibilité, vous cliquez pour réserver, et la chambre a disparu. Cela arrive constamment en haute saison. Une IA de type wrapper n'a aucun vocabulaire pour cette situation. Elle dit soit « Je l'ai réservée ! » (faux), soit « Ça a échoué » (inutile). Elle ne peut pas dire « Elle était là il y a une seconde, mais quelqu'un d'autre l'a prise — voici votre meilleure option suivante ».

Nos agents le peuvent. Quand une réservation renvoie UC, le système déclenche automatiquement une nouvelle recherche de disponibilité pour le même hôtel. Si une chambre ou un tarif différent est disponible, il présente l'option : « Le tarif précédent est épuisé, mais j'ai trouvé une chambre similaire pour 10 $ de plus. » Si rien n'est disponible, il extrait le meilleur hôtel suivant des résultats de recherche initiaux et le propose à la place. Cela exige que l'agent maintienne un état — une mémoire de ce qu'il a déjà cherché, de ce que l'utilisateur a déjà refusé, de ce qu'étaient les alternatives. Les wrappers sont sans état. Ils ne peuvent pas faire cela. Ils repartent de zéro à chaque fois, ou ils hallucinent une continuité.

Le problème de normalisation dont personne ne parle

Une chose qui m'a surpris — vraiment surpris — était à quel point les structures de données diffèrent entre Amadeus et Sabre. Amadeus renvoie les prix décomposés en base, total et taxes dans un JSON strictement imbriqué. Sabre inclut parfois la taxe, parfois non, selon le plan tarifaire. Les noms de champs diffèrent. amount dans un système devient totalPrice dans un autre.

Si vous fournissez les deux réponses brutes à un LLM et lui demandez de comparer des hôtels, il va s'embrouiller. Il pourrait citer le prix hors taxe d'Amadeus et le prix toutes taxes comprises de Sabre, faisant paraître l'hôtel Amadeus 50 $ moins cher alors qu'il est en réalité 20 $ plus cher. Nous avons vu cela se produire lors des tests, et c'est le genre d'erreur presque impossible à repérer pour un utilisateur.

Nous avons donc construit un travailleur de normalisation — une couche de code déterministe qui prend les JSON disparates des deux systèmes et les convertit en un schéma standardisé unique. L'orchestrateur ne voit jamais les données GDS brutes. Il voit des champs propres et cohérents : nom, prix total taxes comprises, classement en étoiles, distance par rapport au point d'intérêt de l'utilisateur. Le LLM présente ces données normalisées. Il n'interprète pas les réponses d'API brutes. Il traduit des faits sélectionnés.

« Il suffit d'utiliser GPT » — et autres choses que disent les investisseurs

Les gens me demandent sans cesse pourquoi nous n'utilisons pas simplement la génération augmentée par récupération — verser les données d'hôtels dans une base de données vectorielle et laisser le LLM y chercher. Ou affiner un modèle sur des données de voyage. Ou simplement ajouter un meilleur prompt système.

Un investisseur m'a dit, sans détour : « Utilisez simplement GPT avec un bon prompt. Le modèle est assez intelligent. » Je respecte cet instinct — c'est la solution la plus simple, et les solutions simples ont généralement raison. Mais pas ici. Pas quand le mode de défaillance est une famille dormant dans un aéroport.

Le RAG aide pour les connaissances statiques — « Quelle est la politique de visa pour la Thaïlande ? » — mais il ne peut pas vous dire si le vol AA123 a des sièges disponibles en ce moment même. L'affinage aide pour le ton et le vocabulaire du domaine, mais il ne connecte pas le modèle à l'inventaire en direct. Un meilleur prompt système aide pour la mise en forme, mais il n'empêche pas le modèle de générer un nom d'hôtel qui n'existe dans aucun GDS.

La seule chose qui empêche l'hallucination dans le voyage, c'est ancrer la sortie de l'IA dans des données en temps réel, vérifiées, issues du système de référence. Ce système, c'est le GDS. Tout le reste n'est que décoration.

La créativité sans contrainte est le chaos. Dans le voyage, la contrainte est la réalité — le siège d'avion qui existe ou non, la chambre d'hôtel qui est disponible ou non. Il n'y a pas d'entre-deux, et l'IA doit cesser de prétendre qu'il y en a un.

Et la question de la lenteur ?

Je ne vais pas prétendre que les systèmes agentiques sont rapides. Une seule requête d'utilisateur peut déclencher quatre appels d'outils — recherche, vérification de prix, vérification de politique, synthèse de la réponse. Cela peut prendre 10 à 15 secondes. Dans le e-commerce, c'est une éternité.

Nous gérons cela de trois façons. D'abord, nous diffusons le raisonnement de l'agent à l'utilisateur : « Recherche de vols sur Amadeus… » « Vérification de la politique de voyage d'entreprise… » Montrer le travail réduit considérablement la latence perçue. Ensuite, nous exécutons les travailleurs en parallèle — le travailleur Vols et le travailleur Hôtels cherchent simultanément plutôt que séquentiellement, réduisant le temps d'attente total d'environ la moitié. Enfin, nous mettons en cache les résultats de disponibilité pendant 15 minutes dans Redis. Si l'utilisateur dit « Montre-moi à nouveau ce deuxième hôtel », nous ne sollicitons pas de nouveau le GDS. Nous puisons dans le cache.

Est-ce aussi rapide qu'un wrapper qui invente une réponse en deux secondes ? Non. Est-ce aussi rapide qu'il le faut pour un utilisateur qui veut une vraie réponse ? Oui.

Le passage où j'admets ce que nous ne savons pas encore faire

Aucun système d'IA ne gère tous les cas. Les itinéraires complexes à plusieurs escales avec dépendances de visa, les alliances aériennes obscures, les réservations de groupe qui exigent des tarifs négociés — tout cela fait encore déraper les choses. Nous le savons parce que nous avons construit une détection pour cela. Quand l'agent tourne en boucle sans résoudre, ou quand l'analyse de sentiment signale une frustration de l'utilisateur, le système bascule vers ce que nous appelons le « mode copilote ». Il alerte un agent de voyage humain, lui transmet le contexte structuré complet de la conversation, et l'humain finalise la réservation à l'aide des outils que l'agent a préparés.

Les gens me demandent si c'est un échec. Je pense que c'est l'inverse. L'IA la plus dangereuse est celle qui ne sait pas quand s'arrêter. Connaître ses limites et passer la main avec élégance est une fonctionnalité, pas un défaut. L'agent qui dit « Laissez-moi vous mettre en relation avec un spécialiste » est plus digne de confiance que celui qui continue à deviner avec assurance.

Vers où cela nous mène ensuite

Ce que nous construisons aujourd'hui est la fondation, pas le plafond. Nous en sommes à ce que j'appellerais le niveau 3 d'autonomie — l'agent exécute des tâches précises, mais l'utilisateur confirme avant que l'argent ne bouge. La voie à suivre inclut des agents de négociation qui ne se contentent pas de réserver les prix affichés mais interrogent les API des hôtels pour obtenir des remises sur volume, des moteurs d'assemblage dynamique qui regroupent vols et hôtels en produits sur mesure à marges maîtrisées, et une gestion proactive des perturbations — des agents qui surveillent le statut des vols en permanence et qui, en cas d'annulation, réservent déjà un siège sur la meilleure option suivante avant même que le voyageur ne sache que quelque chose a mal tourné.

Rien de tout cela n'est possible avec un wrapper. Rien de tout cela ne fonctionne si le système hallucine. Chacune de ces capacités exige l'architecture avec état, vérifiée et ancrée dans les outils que nous construisons.

Le secteur du voyage est à un point d'inflexion. La première vague d'adoption de l'IA — les wrappers, les chatbots, les expériences du type « il suffit d'ajouter GPT » — a créé quelque chose de séduisant et de dangereux : des systèmes qui parlent comme le meilleur agent de voyage que vous ayez jamais rencontré mais qui ne peuvent pas réellement réserver une chambre. La prochaine vague sera définie par une question plus difficile et moins glamour : non pas « L'IA peut-elle rédiger un bel itinéraire ? » mais « L'IA peut-elle confirmer que chaque élément de cet itinéraire existe réellement, en ce moment, au prix qu'elle a annoncé ? »

Cette famille au Costa Rica méritait mieux qu'une fiction magnifiquement écrite. Chaque voyageur le mérite. L'ère de l'IA qui devine est révolue. Ce qui vient ensuite, c'est l'IA qui vérifie — et qui ne parle que lorsqu'elle sait.