Créer un concierge de voyage vocal avec Amazon Bedrock AgentCore, Managed Knowledge Base et Nova Sonic
Amazon Web Services publie un guide pour ajouter un concierge de voyage vocal à une application de compagnie aérienne, construit sur trois services managés. Amazon Bedrock AgentCore, plateforme de déploiement et d'exploitation d'agents IA, héberge l'agent dans son runtime avec une isolation par microVM pour chaque session. Amazon Nova Sonic, modèle voix à voix (la version utilisée est Nova 2.5 Sonic), assure la conversation en temps réel. Amazon Bedrock Knowledge Bases, service de génération augmentée par récupération, ancre les réponses dans les documents de la compagnie. Le voyageur peut consulter son itinéraire, changer de siège, mettre à jour une préférence de repas, poser une question sur la politique de la compagnie ou demander à parler à un conseiller humain, qui reçoit alors un numéro de référence et une estimation du temps d'attente. L'agent est développé avec le framework Strands Agents. Il accède au backend via le Model Context Protocol (MCP) et AgentCore Gateway, qui expose les points d'accès sous forme d'outils découvrables. Le déploiement repose sur AWS CDK. Il s'appuie sur Cognito pour l'authentification, API Gateway et Lambda pour la logique métier (itinéraires, plans de cabine, statut des vols, fidélité, escalade), DynamoDB pour les données, SES pour les e-mails et Amplify pour l'interface React.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
L'enjeu est d'ouvrir à la voix des tâches que les voyageurs effectuent déjà par écrans : vérifier un retard ou modifier un siège sans quitter l'application ni naviguer dans les menus. Le concierge fonctionne en parallèle des écrans existants et non à leur place, si bien que le voyageur alterne entre toucher et parler au sein d'une même session. Pour les équipes techniques, le principal intérêt tient à la séparation des couches. Le front, l'agent et le backend évoluent et montent en charge indépendamment, tandis que MCP maintient un couplage lâche entre l'agent et les systèmes existants. Les modules du projet sont réutilisables : une compagnie peut ne reprendre que les éléments adaptés à son infrastructure et exposer ses propres services comme outils. L'exemple repose sur un backend fictif et des données synthétiques, ce qui accélère l'adaptation à des systèmes réels. Les services à la demande absorbent aussi les pics de trafic, par exemple avant un week-end de vacances, sans que les équipes aient à gérer l'infrastructure.
Ce travail s'inscrit dans la course des fournisseurs de cloud à proposer des agents vocaux de production, où il faut diffuser l'audio dans les deux sens, conserver le fil d'une conversation sur de nombreux tours et se connecter aux systèmes existants sans les coupler étroitement à l'agent. AWS défend ici une approche modulaire, fondée sur un standard ouvert (MCP) et sur des services managés qu'il commercialise. Le guide décrit une architecture en quatre sections, couvrant le backend déployé par cinq piles CDK, la passerelle AgentCore, le runtime de l'agent et le front end. Les compagnies aériennes, qui cherchent à réduire la charge de leurs centres d'appels sans dégrader l'expérience client, constituent la cible naturelle. La suite dépendra de la facilité avec laquelle ce modèle se branchera sur des systèmes de réservation réels, souvent plus hétérogènes que l'exemple fourni.
Pas d'impact direct sur la France/UE