Yuma AI lance Web Actions : un support IA qui travaille dans un vrai navigateur, sans API
Yuma peut désormais piloter un vrai navigateur Chrome pour accomplir une tâche sur n'importe quel site accessible à votre équipe : portails transporteurs, tableaux de bord 3PL, outils internes. Sans API, sans chantier d'intégration, sans coopération de l'éditeur.
Web Actions permet à Yuma de piloter un vrai navigateur Chrome pour accomplir une tâche sur un site, sans API, au fil d'un ticket.
Pas de code : vous vous filmez une fois en train de faire la tâche, et Yuma en déduit les étapes et les valeurs qui changent.
Avant de toucher un vrai ticket, chaque Web Action est testée jusqu'au bouton de validation, sans rien créer ni envoyer.
Les identifiants sont chiffrés, stockés à part et n'apparaissent ni dans les prompts, ni dans les journaux, ni dans les captures.
Chaque exécution garde un journal étape par étape ; les outils sur site ou derrière un VPN restent hors périmètre pour l'instant.
Web Actions permet à Yuma de piloter un vrai navigateur Chrome pour accomplir une tâche sur n'importe quel site accessible à votre équipe, dans le cadre de la résolution d'un ticket.
Pas une API. Un vrai navigateur, piloté comme le ferait l'un de vos agents.
Autrement dit, le travail qui n'a jamais eu d'intégration, le portail transporteur, le tableau de bord 3PL, l'outil interne pour lequel personne n'a jamais développé d'API, Yuma peut désormais le faire.
Voici ce que font les Web Actions, comment en configurer une, et comment Yuma vérifie son propre travail avant toute mise en service.
Une Web Action de bout en bout : Yuma ouvre le site, se connecte, remplit le formulaire et valide, au milieu d'un ticket.
Le travail qui n'a jamais eu d'intégration
Une partie du support n'est pas une conversation. C'est de la saisie.
Quelqu'un se connecte à un portail transporteur, saisit un numéro de suivi, une valeur de commande et un motif, joint le justificatif, enchaîne trois pages et valide. Puis il revient au ticket pour dire au client que c'est fait.
Toute cette partie centrale échappait à l'automatisation, non parce qu'elle est difficile, mais parce qu'il n'y avait aucune API à appeler, et aucune perspective réaliste d'en obtenir une. Vous n'obtiendrez pas d'un portail transporteur historique, ni de votre propre outil interne, qu'il livre une intégration à votre calendrier.
C'est donc resté manuel. Et c'est resté l'une des parties les plus lentes de la file, celle qui génère le plus d'escalades.
Yuma peut maintenant s'en charger elle-même, au milieu du traitement d'un ticket. Elle ouvre le site, se connecte, lit ce dont elle a besoin dans la commande, remplit le formulaire, joint un fichier issu de la conversation, valide, et rend compte de ce qui s'est passé.
Trois choses qu'elle fait déjà
Déclarer un litige transporteur
Elle ouvre le portail, récupère la valeur de la commande et le numéro de suivi, joint le justificatif, valide, et inscrit la référence du litige dans le ticket. C'est la moitié manuelle du workflow WISMO que l'automatisation n'avait jamais pu atteindre.
Corriger un stock dans votre back-office
Elle retrouve la référence dans un outil interne qui n'a jamais eu d'API, corrige la quantité et enregistre la modification. Seule condition : l'outil doit être accessible depuis un navigateur sur le web ouvert, sans VPN.
Faire ce que l'API ne fera pas
Elle suspend un abonnement avec le bon code motif et une note de rétention, directement dans l'interface.
Enregistrez-le une fois, c'est toute la configuration
Une Web Action ne se scripte pas. Vous décrivez la tâche, vous vous filmez en train de la faire une fois, et vous confiez la vidéo à Yuma.
Yuma la lit et en déduit les étapes, les valeurs qui changent à chaque exécution, et ce qu'elle doit rapporter une fois terminée. Vous relisez ensuite ce qu'elle a produit et corrigez ce qui ne convient pas.
Pas de code, pas de sélecteurs, pas de développeur. Si un enregistrement n'est pas praticable, une procédure écrite au format PDF fonctionne aussi.
Yuma en action
Voyez-le en action
Réservez une démonstration des nouveautés, sur votre propre configuration.
Avant qu'une Web Action ne touche un vrai ticket, Yuma l'exécute une fois à titre de test.
Elle vérifie que le site s'ouvre, que la connexion fonctionne et que chaque étape est atteignable, puis avance jusqu'au bouton de validation et s'arrête délibérément là. Rien n'est créé, modifié ni envoyé.
Si quelque chose la bloque, Yuma vous dit précisément quoi : une connexion en échec, une page qui n'a pas chargé, une étape introuvable.
L'action reste en brouillon tant qu'elle n'a pas réussi. Ainsi, rien de mal configuré ne s'exécute jamais sur le ticket d'un client.
Vos identifiants restent à part
Les identifiants de connexion ne figurent jamais dans les instructions. Ils sont enregistrés une fois comme identifiant, chiffrés, et utilisés uniquement au moment où l'action s'exécute.
Ils n'apparaissent ni dans les prompts, ni dans les journaux, ni dans les captures d'écran. Les instructions décrivent la tâche. Les identifiants portent l'accès.
Les sites qui envoient un code de vérification par e-mail fonctionnent également : la double authentification n'est pas un obstacle. Cette configuration demande un coup de main de notre équipe, alors signalez-la à votre account manager.
Chaque exécution, étape par étape
Chaque exécution conserve un journal complet : chaque étape dans l'ordre, son résultat, une capture de la page à cet instant, et les étapes qui ont demandé à l'IA de trancher.
Les exécutions renvoient à la conversation qui les a déclenchées, et la conversation elle-même montre ce que l'action a fait.
Quand vous voulez savoir ce qui s'est passé sur un ticket précis, vous pouvez donc regarder plutôt que deviner. Cela compte ici plus que partout ailleurs dans le produit : une action qui écrit dans un portail transporteur ou dans votre inventaire est une action dont vous voudrez garder une trace écrite.
Où cela fonctionne, et où cela ne fonctionne pas
Il n'y a aucune intégration à attendre et aucune coopération à obtenir de l'éditeur. Si votre équipe sait le faire sur un site web, c'est un candidat.
Les trois points de départ les plus fréquents : les portails transporteurs, les outils 3PL et d'entrepôt, et les systèmes de back-office internes.
Une limite pratique : l'outil doit être accessible depuis un navigateur sur le web ouvert. Tout ce qui est sur site ou derrière un VPN reste hors périmètre pour l'instant.
Mettre en place votre première Web Action
Déjà client Yuma ? Indiquez à votre account manager la tâche que vous souhaitez automatiser, avec un enregistrement d'écran prêt. Le plus simple est de vous filmer en train de la réaliser sur un cas réel, en navigation privée, de la page de connexion jusqu'à l'écran de confirmation. Une procédure écrite au format PDF fonctionne aussi.
Pas encore client ? Réservez une démo et apportez la tâche que personne n'a jamais réussi à automatiser. C'est celle dont il vaut la peine de parler.
BOSTON, 2 septembre 2026 : Yuma AI, la plateforme d'agents IA pour le service client e-commerce, annonce aujourd'hui Web Actions, une capacité qui permet à Yuma d'accomplir des tâches dans un vrai navigateur Chrome, sur n'importe quel site accessible depuis le web ouvert, dans le cadre de la résolution d'un ticket de support. Web Actions ne requiert aucune API, aucun chantier d'intégration et aucune coopération de l'éditeur de l'outil visé.
Les marchands configurent une Web Action en décrivant la tâche et en fournissant l'enregistrement d'écran de son exécution. Yuma analyse l'enregistrement pour en extraire les étapes, identifie les valeurs qui varient d'une exécution à l'autre, et valide l'action lors d'une exécution exploratoire en lecture seule avant toute publication.
À propos de Yuma AI
Yuma AI est une plateforme de service client IA conçue pour les marques e-commerce. Avec Yuma 2.0, un seul Handbook pilote chaque conversation client, sur tous les canaux, téléphone compris. Yuma résout les tickets de bout en bout en se connectant aux helpdesks, dont Gorgias, Zendesk, Kustomer, Gladly et Salesforce Service Cloud, et en menant de vraies actions dans Shopify et le reste de la stack du marchand, comme le ferait un agent humain. Yuma AI est soutenue par Y Combinator. Pour en savoir plus : yuma.ai.
Yuma peut-il travailler dans des outils sans API ?
Oui. Les Web Actions permettent à Yuma de piloter un vrai navigateur Chrome pour effectuer des tâches dans des outils sans API, ou avec une API limitée : déclarer un litige transporteur, corriger du stock dans un back-office interne, suspendre un abonnement avec le bon motif. Pour en créer une, il suffit de vous enregistrer une fois en train de faire la tâche. L'outil doit être accessible depuis Internet ; les systèmes sur site ou derrière un VPN ne sont pas pris en charge.
Les Web Actions, est-ce simplement de la RPA ?
Non. La RPA enregistre un seul parcours de clics, avec une seule façon de trouver chaque élément, et casse dès que la page change. Yuma apprend la tâche une fois grâce à l'IA, puis la rejoue rapidement et à faible coût, avec plusieurs façons de trouver chaque élément. Si une étape échoue malgré tout, un agent IA reprend à partir de cette étape et termine le travail. La mise en place, c'est un enregistrement d'écran, pas un projet de scripts.
Les Web Actions fonctionnent-elles derrière un VPN ?
Non. L'outil doit être accessible depuis un navigateur sur le web ouvert. Les systèmes sur site, accessibles uniquement par VPN ou réservés à certaines adresses IP sont hors périmètre par conception. La bonne question à se poser : pouvez-vous ouvrir l'outil depuis un navigateur en dehors du bureau, sans VPN ?
Comment Yuma gère-t-il les identifiants des Web Actions ?
Les identifiants sont enregistrés une fois, chiffrés, et utilisés uniquement au moment où l'action s'exécute. Ils n'apparaissent jamais dans les prompts, les logs ou les captures d'écran. Chaque Web Action est limitée aux domaines que vous déclarez, à chaque navigation, redirection, fenêtre pop-up et cadre intégré, et les adresses de réseaux privés sont bloquées.
