Lorsque de nombreuses entreprises ne pensaient même pas aux comportements ou infrastructures agentic, Booking.com avait déjà "trébuché" dessus avec son système de recommandation conversationnel fait maison.
Cette expérimentation précoce a permis à la société de prendre du recul et d’éviter de se laisser emporter par l’engouement frénétique pour les agents d’IA. Au lieu de cela, elle adopte une approche disciplinée, en couches et modulaire pour le développement de modèles : des modèles petits et spécifiques au voyage pour des inférences rapides et peu coûteuses ; des grands modèles de langage (LLM) pour la raisonnement et la compréhension ; et des évaluations adaptées au domaine développées en interne lorsque la précision est cruciale.
Avec cette stratégie hybride, combinée à une collaboration sélective avec OpenAI, Booking.com a vu sa précision doubler dans les tâches clés de recherche, de classement et d’interaction avec les clients.
Comme l’a souligné Pranav Pathak, responsable du développement de produits IA de Booking.com, dans un nouveau podcast avec VentureBeat : "Voulez-vous le construire très spécialisé et sur mesure puis avoir une armée de cent agents ? Ou le gardez-vous suffisamment général et avoir cinq agents qui sont bons pour des tâches généralisées, mais ensuite vous devez beaucoup orchestrer autour d’eux ? C’est un équilibre que je pense que nous essayons encore de trouver, tout comme le reste de l’industrie."
Découvrez le nouveau podcast Au-delà du pilote ici, et continuez à lire pour les points forts.
Passer de la conjecture à la personnalisation profonde sans être "creepy"
Les systèmes de recommandation sont au cœur des plateformes orientées clients de Booking.com ; cependant, les outils de recommandation traditionnels étaient moins sur la recommandation et plus sur la conjecture, a concédé Pathak. Dès le départ, lui et son équipe se sont engagés à éviter les outils génériques : comme il l’a dit, le prix et la recommandation devraient être basés sur le contexte du client.
Les premiers outils IA pré-gén de Booking.com pour la détection d’intention et de sujet étaient un petit modèle de langage, ce que Pathak a décrit comme "l’échelle et la taille de BERT". Le modèle analysait les entrées du client autour de leur problème pour déterminer s’il pouvait être résolu en libre-service ou transmis à un agent humain.
"Nous avons commencé avec une architecture de ‘vous devez appeler un outil si c’est l’intention que vous détectez et c’est ainsi que vous avez analysé la structure", a expliqué Pathak. "C’était très, très similaire aux premières architectures agentic qui sont sorties en termes de raisonnement et de définition d’un appel d’outil."
Son équipe a depuis développé cette architecture pour inclure un orchestrateur LLM qui classe les requêtes, déclenche la génération augmentée par récupération (RAG) et appelle des API ou des modèles de langage plus petits et spécialisés. "Nous avons pu mettre en place ce système de manière assez efficace car il était très proche en termes d’architecture, et avec quelques ajustements, nous avons maintenant une pile agentic complète", a déclaré Pathak.
En conséquence, Booking.com constate une augmentation de 2X de la détection de sujets, ce qui libère la bande passante des agents humains de 1,5 à 1,7X. Plus de sujets, même complexes et précédemment identifiés comme "autres" et nécessitant une escalade, sont automatisés.
Cela soutient finalement plus d’auto-service, libérant les agents humains pour se concentrer sur les clients ayant des problèmes spécifiques uniques pour lesquels la plateforme n’a pas de flux d’outils dédiés – par exemple, une famille qui ne peut pas accéder à sa chambre d’hôtel à 2 heures du matin lorsque la réception est fermée.
Non seulement cela "commence vraiment à se cumuler", mais cela a un impact direct et à long terme sur la fidélisation des clients, a noté Pathak. "Une des choses que nous avons constatée, c’est que plus notre service client est bon, plus nos clients sont fidèles."
Un autre déploiement récent est le filtrage personnalisé. Booking.com propose entre 200 et 250 filtres de recherche sur son site Web – une quantité irréaliste pour tout être humain à parcourir, a souligné Pathak. Ainsi, son équipe a introduit un champ de texte libre dans lequel les utilisateurs peuvent taper pour recevoir immédiatement des filtres sur mesure.
"Cela devient un indice très important pour la personnalisation en termes de ce que vous recherchez dans vos propres mots plutôt qu’un flux de clics", a déclaré Pathak.
À son tour, cela permet à Booking.com de comprendre ce que les clients veulent réellement. Par exemple, les jacuzzis – lorsque la personnalisation des filtres a été lancée, les jacuzzis étaient l’une des demandes les plus populaires. Ce n’était même pas une considération auparavant ; il n’y avait même pas de filtre. Maintenant, ce filtre est en ligne.
"Je n’avais aucune idée", a noté Pathak. "Je n’avais jamais cherché de jacuzzi dans ma chambre honnêtement."
En ce qui concerne la personnalisation, cependant, il y a une ligne fine ; la mémoire reste compliquée, a souligné Pathak. Bien qu’il soit important d’avoir des souvenirs à long terme et des fils évolutifs avec les clients – retenir des informations comme leurs budgets typiques, leurs préférences en matière d’étoiles d’hôtel ou s’ils ont besoin d’un accès pour les personnes handicapées – cela doit se faire à leurs conditions et protéger leur vie privée.
Booking.com est extrêmement attentif à la mémoire, cherchant à obtenir le consentement afin de ne pas être "creepy" lors de la collecte d’informations sur les clients.
"Gérer la mémoire est beaucoup plus difficile que de construire réellement la mémoire", a déclaré Pathak. "La technologie est là, nous avons les compétences techniques pour la construire. Nous voulons nous assurer que nous ne lançons pas un objet mémoire qui ne respecte pas le consentement du client, qui ne semble pas très naturel."
Trouver un équilibre entre construire et acheter
Alors que les agents évoluent, Booking.com se trouve face à une question centrale qui se pose à l’ensemble de l’industrie : à quel point les agents doivent-ils devenir étroits ?
Au lieu de s’engager soit dans un essaim d’agents hautement spécialisés, soit dans quelques agents généralisés, l’entreprise vise des décisions réversibles et évite les "portes à sens unique" qui verrouillent son architecture dans des voies coûteuses à long terme. La stratégie de Pathak est la suivante : généraliser lorsque c’est possible, spécialiser lorsque c’est nécessaire et garder la conception des agents flexible pour aider à assurer une résilience.
Pathak et son équipe sont "très attentifs" aux cas d’utilisation, évaluant où construire des agents plus généralisés et réutilisables ou des agents plus spécifiques à la tâche. Ils s’efforcent d’utiliser le modèle le plus petit possible, avec le plus haut niveau de précision et de qualité de sortie, pour chaque cas d’utilisation. Tout ce qui peut être généralisé l’est.
La latence est une autre considération importante. Lorsque l’exactitude factuelle et l’évitement des hallucinations sont primordiaux, son équipe utilisera un modèle plus grand et beaucoup plus lent ; mais avec la recherche et les recommandations, les attentes des utilisateurs fixent la vitesse. (Pathak a noté : "Personne n’est patient.")
"Nous n’utiliserions par exemple jamais quelque chose d’aussi lourd que GPT-5 uniquement pour la détection de sujets ou l’extraction d’entités", a-t-il déclaré.
Booking.com adopte une approche similaire et élastique en ce qui concerne la surveillance et les évaluations : s’il s’agit d’une surveillance polyvalente que quelqu’un d’autre est meilleur pour construire et qui a une capacité horizontale, ils l’achèteront. Mais s’il s’agit de cas où les directives de la marque doivent être appliquées, ils construiront leurs propres évaluations.
En fin de compte, Booking.com mise sur l’"anticipation super", l’agilité et la flexibilité. "À ce stade, avec tout ce qui se passe avec l’IA, nous sommes un peu réticents à franchir des portes à sens unique", a déclaré Pathak. "Nous voulons que le plus grand nombre possible de nos décisions soient réversibles. Nous ne voulons pas nous retrouver dans une décision que nous ne pouvons pas inverser dans deux ans."
Ce que d’autres constructeurs peuvent apprendre du voyage IA de Booking.com
Le parcours IA de Booking.com peut servir de modèle important pour d’autres entreprises.
Avec le recul, Pathak a reconnu qu’ils avaient commencé avec une pile technologique "assez compliquée". Ils se trouvent maintenant dans une bonne position à ce sujet, "mais nous aurions probablement pu commencer quelque chose de beaucoup plus simple et voir comment les clients interagissent avec".
Dans ce contexte, il a offert ce précieux conseil : si vous débutez avec des LLMs ou des agents, les APIs prêts à l’emploi feront parfaitement l’affaire. "Il y a suffisamment de personnalisation avec les APIs pour que vous puissiez déjà tirer parti de beaucoup de choses avant de décider que vous voulez faire davantage".
D’un autre côté, si un cas d’utilisation nécessite une personnalisation non disponible via un appel API standard, cela plaide en faveur d’outils internes.
Cependant, il a souligné : ne commencez pas par des choses compliquées. Abordez le "problème le plus simple et le plus douloureux que vous pouvez trouver et la solution la plus simple et la plus évidente à cela".
Identifiez l’adéquation du produit sur le marché, puis explorez les écosystèmes, a-t-il conseillé – mais ne déchirez pas les anciennes infrastructures simplement parce qu’un nouveau cas d’utilisation exige quelque chose de spécifique (comme passer d’une stratégie cloud entière d’AWS à Azure juste pour utiliser le point de terminaison OpenAI).
En fin de compte : "Ne vous enfermez pas trop tôt", a noté Pathak. "Ne prenez pas de décisions qui sont des portes à sens unique jusqu’à ce que vous soyez très sûr que c’est la solution que vous voulez adopter".