Je suis à VivaTech cette semaine, à titre personnel. 3 jours de salon à absorber ce qui se passe dans le numérique et l’IA. Ces articles "Vu à VivaTech" sont mes notes de terrain, publiées à chaud.
Passage sur le stand IBM où Alexandre Grancher, consultant Stratégie & Organisation chez Next Decision, présente le cas de la station de ski des Hautes-Alpes de Serre Chevalier. Le titre : « Repenser l’expérience client en station de ski avec l’IA ».
L’histoire commence par un problème connu par beaucoup d’acteurs du tourisme : un service client débordé en période de pointe. A Serre Chevalier, il peut y avoir jusqu’à 27 lignes simultanées à gérer, pour une équipe dimensionnée pour 5 en temps normal. Un premier chatbot avait été testé, basé sur un arbre de décision. Mais un coût pas anodin du tout (six chiffres a priori) et surtout un résultat décevant. Les visiteurs posaient leurs questions en dehors du script prévu et le système ne savait pas quoi répondre. L’expérimentation a été arrêtée.
Arrive Dana. Un agent IA développé sur IBM Watsonx Orchestrate, déployé sur le site serrechevalier-pass.com. La différence avec le chatbot précédent ? Dana ne suit pas un script, il comprend le langage naturel et, surtout, il n’est pas seul : c’est un agent orchestrateur qui coordonne des agents spécialisés. Quand on lui pose une question sur les prix des forfaits, il appelle l'agent Skipass. Quand c’est une question sur les activités ou les horaires, il appelle l'agent Documentation. Le visiteur voit un seul interlocuteur. Mais derrière, c’est bien une équipe d’agents IA.
Pour la gestion des prix, sujet sensible, impossible d’avoir un prix « halluciné » par l’agent. Et le configurateur de vente du site, celui qui calcule les prix des forfaits, n’était pas ouvert aux connexions extérieures. Impossible donc de le brancher directement à Dana. L’équipe a contourné le problème en récupérant les fichiers Excel de tarification et en demandant à l’IA de reconstruire toute la logique de calcul. Dana a pu alors donner un prix exact en temps réel, sans passer par le système d’origine.
Pour la documentation, deux approches coexistent : les documents stables (conditions générales...) sont indexés en base vectorielle dans Watsonx. Les contenus qui changent tous les jours (événements, horaires d’activités) sont scrappés automatiquement chaque nuit, convertis en fichiers Markdown et remplacés dans la mémoire de Dana. Résultat : il est toujours à jour le matin.
L’effet waouh, selon Alexandre Grancher, est venu le jour où ils ont connecté Dana à la « social box » de la station, une base de données temps réel qui agrège l’enneigement, l’état des pistes, la météo, les incidents. Cette connexion aurait été faite en une journée et a permis à Dana de répondre à des questions qu’aucun opérateur téléphonique n’aurait pu traiter aussi rapidement.
Les chiffres annoncés : -50% de coûts opérationnels dès la première année, 90% de taux de succès sur les questions hivernales, 30 jours de développement au total. Un POC validé en 9 jours ouvrés.
Après la présentation, je suis allé poser quelques questions à Alexandre Grancher.
La première : qu’est-ce qui n’a pas marché ?
Il cite deux choses. Il a fallu plusieurs allers-retours pour affiner la façon dont Dana comprend et répond aux questions. C’est le travail normal de mise au point de ce type d’agent, rien d’inhabituel. Mais surtout : l’accessibilité à la donnée. Exemple avec les canons à neige : les données de débit étaient disponibles et auraient permis de détecter des pannes en temps réel, voire…