#

Points clés

• AWS a publié une étude de cas sur le helpdesk AiDaH de U Mobile.

• La plateforme a été construite avec le partenaire Axrail et utilise Amazon Bedrock AgentCore et Knowledge Bases.

• Huit agents spécialisés couvrent plus de 150 scénarios opérationnels documentés.

• Une conception de routage à trois niveaux gère les demandes avec différents degrés d'automatisation.

• Les agents de support humains confirment toujours les actions avant que des modifications n'atteignent un compte en production.

Ce qu'AWS a décrit

AWS a publié une étude de cas le 4 novembre 2026 sur AiDaH, le helpdesk agentique piloté par l'IA de U Mobile. L'étude de cas indique que U Mobile est un opérateur de télécommunications malaisien. Elle précise également que la plateforme a été construite avec AWS et le partenaire Axrail sur Amazon Bedrock AgentCore.

Le système couvre plus de 150 scénarios opérationnels documentés dans six domaines. Il utilise huit agents spécialisés. Le personnel interagit avec le helpdesk via Microsoft Teams et un portail web. Le déploiement est hébergé dans la région Asie-Pacifique de Singapour.

Comment l'architecture est organisée

L'étude de cas décrit une architecture en couches. Elle combine l'exécution AgentCore, la mémoire, l'identité, les passerelles et l'observabilité. La récupération est assurée via Amazon Bedrock Knowledge Bases. La conception utilise également le Model Context Protocol pour exposer les outils backend via des passerelles.

Les agents coopèrent via Agent2Agent. Cela suggère que le système est conçu pour une gestion coordonnée des tâches plutôt que pour un flux de travail monolithique unique. La source présente cela comme faisant partie de la conception de la plateforme, et non comme une revendication produit distincte.

Routage et flux de contrôle

AWS indique qu'AiDaH utilise une conception de routage à trois niveaux. La correspondance déterministe par mots-clés traite environ 70 % des demandes. Un classificateur léger en traite 20 %. L'orchestrateur complet prend en charge les 10 % restants, selon l'étude de cas.

Cette répartition du routage montre un équilibre délibéré entre rapidité et profondeur d'orchestration. Les demandes simples peuvent être traitées avec une logique plus légère. Les demandes plus complexes peuvent être transmises à l'orchestrateur lorsque cela est nécessaire.

L'étude de cas indique également que les contrôles d'accès basés sur les rôles et les identités authentifiées limitent l'accès aux outils. Il s'agit d'une protection opérationnelle importante. Elle limite les agents ou utilisateurs pouvant atteindre des outils backend spécifiques.

Supervision humaine dans le flux de travail

Dans un flux de support illustré, le système enquête sur un problème d'abonné et propose une remédiation. Un agent de support confirme ensuite les actions avant que toute modification n'atteigne un compte en production. Ce détail est important car il montre que la plateforme n'est pas entièrement autonome dans cet exemple.

La source indique également que l'objectif à plus long terme d'opérations auto-réparatrices reste un objectif de feuille de route. Cela signifie que l'étude de cas présente l'auto-réparation comme une direction visée, et non comme un état déjà atteint. Le flux de travail actuel inclut toujours une validation humaine pour les modifications en production.

Mesures opérationnelles rapportées

Les mesures internes de U Mobile entre janvier et septembre 2026 montrent des baisses dans plusieurs catégories de tickets. Les tickets mensuels de provisioning et de réseau ont diminué de 84,5 %. Les demandes générales ont diminué de 81,6 %. Les tickets de facturation et de tarification ont diminué de 48,7 %.

L'étude de cas présente ces chiffres comme des mesures rapportées par le client dans une étude de cas AWS. Elle n'établit pas une comparaison causale vérifiée de manière indépendante. Ces chiffres doivent donc être lus comme des résultats internes rapportés dans le matériau source.

Lecture éditoriale de l'étude de cas

Le signal le plus fort dans la source est la combinaison du routage, du contrôle d'accès et de la confirmation humaine. Ces éléments suggèrent un déploiement contrôlé plutôt qu'un remplacement entièrement automatisé du support. L'architecture semble conçue pour acheminer efficacement les tâches courantes tout en gardant les actions sensibles sous examen.

La source met également l'accent sur l'ampleur opérationnelle. Plus de 150 scénarios documentés dans six domaines représentent une surface de support importante. Huit agents spécialisés et un routage par couches semblent soutenir cette ampleur.

Ce que la source permet d'affirmer, et ce qu'elle ne permet pas d'affirmer

L'étude de cas permet de décrire AiDaH comme un helpdesk agentique construit sur des services AWS. Elle confirme l'utilisation d'Amazon Bedrock AgentCore, de Knowledge Bases, de l'exposition d'outils basée sur MCP et de la coopération Agent2Agent. Elle confirme également les baisses de tickets rapportées et le flux de travail avec intervention humaine.

Elle ne permet pas d'affirmer des éléments plus larges au-delà du déploiement décrit. La source présente les mesures comme internes et rapportées par le client. Elle présente aussi l'auto-réparation comme un objectif de feuille de route, et non comme une capacité achevée. Ces distinctions sont importantes lorsqu'on lit l'étude de cas comme un exemple de produit et d'exploitation.