Meilleures pratiques

Approches recommandées pour l'adoption de ScreenPlay dans les workflows UI Automation nouveaux ou existants, et pratiques pour les maintenir rapides et rentables à grande échelle.

Approches recommandées pour adopter ScreenPlay, qu'il s'agisse de l'intégrer dans des workflows UIAutomation existants ou de créer de nouvelles automatisations pilotées par des agents, et pour que ces automatisations soient rapides et rentables une fois qu'elles s'exécutent à grande échelle.

Où ScreenPlay appartient à une automatisation

ScreenPlay est conçu pour exceller à des points de friction spécifiques à forte intensité, également appelés scénarios d'agence contrôlée, représentant de petits domaines critiques de l'automatisation dans lesquels les outils traditionnels sont les plus fragiles. Plutôt que de remplacer des workflows entiers, ScreenPlay apporte une exécution agentique aux parties qui en ont le plus besoin:

• Sélecteurs fragiles qui se cassent facilement.
• Structures complexes d’interface utilisateur et éléments dynamiques.
• Éléments difficiles d’accès de l’interface utilisateur, tels que fenêtres contextuelles, listes virtualisées, tableaux incorporés ou contrôles personnalisés.

Le complément est tout aussi important. Dans l'automatisation Unattended, vous devez faire confiance à une exécution que vous ne surveillez pas, et les parties déterministes d'un workflow sont les seules parties qui se comportent de manière identique à chaque fois. Elles sont également les plus rapides et les moins chères à exécuter, ce qui les rend viables sur des milliers d’exécutions.

L'objectif est un workflow maximalement déterministe et minimalement agentique: UI Automation classique où l'interface est stable et les étapes sont connues, et ScreenPlay où l'exécution agentique est le seul moyen de répondre de manière fiable aux besoins de l'entreprise.

Démarrage

Les chemins suivants sont disponibles en fonction de votre contexte.

Mise à niveau des automatisations problématiques

Vous pouvez utiliser les activités ScreenPlay pour résoudre les étapes problématiques de votre UIAutomation actuelle, telles que :

• Sélecteurs qui échouent à plusieurs reprises.
• Automatisations qui s’arrêtent après des modifications de l’interface utilisateur.
• Logique trop complexe écrite pour les tâches simples.

Définissez les actions que vous utilisez à l’aide de commandes en langage naturel au lieu de sélecteurs fragiles ou d’une longue logique personnalisée. Cela contribue à simplifier le développement et à rendre votre automatisation plus résiliente dans le temps.

Création d’une automatisation à partir de zéro avec granularité

Si vous démarrez une UIAutomation à partir de zéro, vous pouvez la créer entièrement à l'aide de ScreenPlay avec une granularité.

Chaque activité ScreenPlay doit correspondre à une petite étape bien ciblée de votre processus, idéalement deux ou trois étapes qui vont naturellement ensemble.

Cette approche granulaire présente les avantages suivants :

• Maximise la précision.
• Maintient l’agent concentré.
• Évite de surcharger le modèle avec trop de contexte.

En fonction de la complexité de chaque étape, vous pouvez choisir le modèle d’IA approprié, en équilibrant la rentabilité et les capacités.

Créer avec un agent de codage

Vous pouvez également créer l'automatisation avec un agent de codage d'IA à l'aide des compétences d'agent UiPath, qui apprenent à l'agent à créer, exécuter, tester et déployer des automatisations UiPath à partir de votre environnement de développement. Pour obtenir le catalogue et les instructions d’installation, consultez le Référentiel des compétences de l’agent UiPath.

Les compétences de création sont axées sur la génération de RPA, de sorte que ce que produit l’agent de codage est déterministe par défaut, c’est-à-dire la base de référence souhaitée. L'approche recommandée consiste à examiner le workflow généré et à ajouter des activités ScreenPlay aux points où l'approche agentique est requise.

Ces ajouts doivent rester délibérés et peu nombreux. Chacun est un endroit où le comportement n'est plus garanti et où le temps d'exécution et l'utilisation de jetons augmentent.

Concevoir pour optimiser la vitesse et les coûts à grande échelle

Une automatisation qui s'exécute une poignée de fois par jour et une automatisation qui s'exécute des milliers de fois ont des sciences financières très différentes. Les pratiques suivantes réduisent la latence et la consommation de jetons sans perdre la fiabilité.

En préservant la petite taille de l’agent

Il s'agit de la décision qui a le plus d'impact et elle est prise au moment de la conception plutôt que de être ajustée par la suite. Chaque étape pouvant être exprimée de manière déterministe est une étape qui ne coûte aucun appel de modèle, n'ajoute aucune latence et ne peut pas varier d'une exécution à l'autre.

La base de référence déterministe commence, avec des étapes agentiques ajoutées uniquement lorsqu'elles gagnent leur place.

Choisir le bon modèle pour chaque étape

Les modèles disponibles dans la liste déroulante Modèle continuent à être plus rapides et plus capables, de sorte que la vitesse et la qualité représentent beaucoup moins un compromis qu'auparavant.

Étant donné que chaque activité ScreenPlay entraîne sa propre sélection de modèle, vous pouvez faire correspondre le modèle à la difficulté de l'étape: un modèle rapide de niveau Basique pour les interactions de routine, un modèle de niveau Standard pour les étapes qui nécessitent réellement plus de raisonnement. Pour la liste complète des modèles disponibles, consultez ScreenPlay.

Si votre automatisation a été conçue à l'aide d'un modèle plus ancien, la révision de la sélection est l'une des améliorations de vitesse les moins chères disponibles.

Regrouper plusieurs actions sur le même écran

Le bundle agentique ScreenPlay peut exécuter plusieurs actions sur le même écran en un seul lot, plutôt qu'une action par appel de modèle. Un nombre plus faible d'allers-retours sur le modèle se traduit par une latence de bout en bout plus faible, et la différence est davantage visible sur les écrans denses en actions, tels que les formulaires longs.

Ce n'est pas le comportement par défaut. Par défaut, le bundle effectue une seule action à la fois, et le regroupement ne se produit que lorsque l'invite de tâche le demande explicitement. Le exploit respecte ces indications lorsque les actions ciblent le même écran.

Par exemple, au lieu de:

Fill in the customer details form.

utilisez:

Fill in the customer details form. Fill in all the fields visible on the screen in one go, then submit.

Le regroupement s’applique uniquement aux actions qui peuvent être effectuées sur l’écran actuellement visible. Les étapes qui nécessitent une navigation, une transition de page ou un changement d'application sont toujours exécutées de manière séquentielle, car le modèle doit observer le nouvel écran avant de décider de la suite des événements.

Quand arrêter l'optimisation

L'optimisation uniquement pour le temps d'exécution et l'utilisation de jetons peut vous amener vers des implémentations déterministes qui sont fragiles et coûteuses à maintenir actives. Un workflow chargé de sélecteur qui s'interrompt à chaque modification mineure de l'interface utilisateur peut coûter plus de sa durée de vie que les jetons qu'il a économisés.

Healing Agent réduit cet écart, mais ne le ferme pas. Ses stratégies de récupération sont un ensemble défini et limité, et elles fonctionnent toutes au niveau de l’identification à nouveau d’un élément cible pour une activité qui existe déjà:

• Attributs du sélecteur modifiés.
• Synchronisation.
• Position de l’ancre.
• Titres AppCard.
• Le sélecteur sémantique de secours en phase de conception.

Healing Agent applique également des stratégies basées sur l'IA pour:

• Fenêtres contextuelles obstruant l'élément cible.
• Des libellés reformatés sémantiques.
• Computer Vision.

Cela couvre une grande partie de la dérive quotidienne de l’interface utilisateur, mais ne peut pas filtrer les modifications de l’interaction elle-même, comme une nouvelle boîte de dialogue de confirmation, un ensemble d’écrans réorganisé, un champ qui passe à une autre étape ou un flux qui nécessite désormais une séquence différente d'actions.

L'activation de Healing Agent ne remplace pas une bonne conception du workflow et ne maintient pas une implémentation déterministe fragile active indéfiniment.

Pour les parties d'une application où vous vous attendez à ce type de changement, ScreenPlay est la meilleure réponse. Décrire le résultat en langage naturel et laisser l’agent définir l’interaction au moment de l’exécution supprime la charge de maintenance de ces étapes, au coût de l’appel du modèle. Décider quelles étapes valent la peine d’être révisées à mesure que les applications cibles évoluent.