Travailler efficacement

Un agent de codage est un collaborateur rapide, pas un développeur autonome. Vous définissez la direction et évaluez les résultats; l'agent effectue le travail. Bien travailler avec l’une d’entre elles est une compétence en soi, et les bonnes pratiques séparent un brouillon que vous rejetez d’un résultat que vous pouvez expédier.

Fonctionnement d'un agent de codage et votre rôle

Un agent de codage prend un objectif et l'exécute étape par étape, vérifiant le résultat de chaque action et s'ajuste au fur et à mesure, tout comme une application de navigation se réacheminant après un tour manqué. Le fait de résoudre un problème à mi-parcours et de le récupérer, c'est le système qui fonctionne comme prévu, et non une panne.

Votre rôle reste central tout au long de la procédure. Vous définissez l'objectif, observez le travail, détectez les problèmes et approuvez tout ce qui change de l'état. Un agent plus capable augmente les enjeux de cette supervision plutôt que de la supprimer: l’agent vous aide et vous décidez.

Configuration de la réussite

De bons résultats résultent de trois éléments fonctionnant ensemble, et non d’une formulation intelligente:

• Une requête claire.
• Une configuration solide.
• Le bon contexte.

L’agent travaille à partir d’une mémoire de travail limitée, de sorte que ce qui est pertinent et actuel compte plus que le volume.

• L’agent fait le meilleur avec les fichiers, les objectifs et les normes spécifiques dont une tâche a besoin, plutôt que tout ce dont vous disposez.
• La compétence UiPath appropriée doit être disponible, car les compétences ne sont pas toujours sélectionnées automatiquement. Le fait de nommer la compétence pour la tâche, telle que uipath-rpa pour le travail d’automatisation des processus robotisés et de confirmer qu’elle est chargée, conserve l’agent sur les modèles de la page. Voir Vue d’ensemble des compétences.
• Une nouvelle session pour chaque nouvelle tâche empêche le contexte obsolète de s’activer.
• Les conventions que vous répétez à chaque session appartiennent à un fichier que l'agent charge automatiquement. Consultez Donnez à votre agent un contexte de projet.

Cinq pratiques qui fonctionnent

• Vous êtes l'architecture. Vous devez apporter une intention et une structure claires, y compris ce que vous souhaitez, les entrées et les contraintes.
• La sortie est un brouillon. Le travail généré vaut la peine d’être examinés avant que vous ne vous y basez, et n’est pas destiné à être livré sans révision.
• La validation surpasse la confiance. Les propres vérifications d'UiPath, telles que l'Analyseur de workflow (Analyser le projet) et une exécution locale, sont plus fiables que le message « Terminé» de l'agent.
• C'est également un réviseur. Un agent est capable de repérer les problèmes de sécurité, les lacunes et le code inconnu, et pas seulement de l’écrire.
• Fermeture de la boucle de composants. Une brève note sur ce qui a fonctionné, après une session importante, est payante, à mesure du développement des connaissances de l’équipe.

Rédiger des invites qui fonctionnent

La qualité de votre requête est le facteur le plus important dans le déroulement d'une session. Une invite forte inclut:

• Un livrable clair: le fichier ou le projet exact à produire et son emplacement.
• Entrées et sorties nommées, avec leurs types.
• Le comportement attendu, de bout en bout.
• Contraintes explicites: les activités ou packages à utiliser et ceux à éviter.
• Tout contexte dont l'agent a besoin, tel que les dépendances existantes.

Une requête vague coûte plus d'itérations à corriger qu'une requête spécifique. Par exemple, « créer UploadInvoice.xaml qui lit in_FilePath (String), le télécharge dans SharePoint, et renvoie out_Url (String)» fonctionne mieux que « créer quelque chose qui télécharge des fichiers».

Commencer à partir d’un PDD ou d’un SSD

L'entrée la plus forte d'une automatisation non triviale est une spécification structurée. Un document de conception de processus (Process Design Document, DDP) ou un document de conception de solution apporte déjà la plupart des éléments dont une bonne requête a besoin:

• les étapes
• les entrées
• les systèmes impliqués
• les chemins d'exception

Le fait de transmettre cela à l’agent, plutôt que de décrire le processus à partir de la mémoire, produit un premier résultat plus proche avec moins d’allers-retours.

Pour un travail plus important, l'agent peut transformer un DDP en un SDD et un plan de développement, puis le parcourir élément par élément au lieu de tout créer à partir d'un document brut en une seule fois. Attention: un PDD ou un SDD peut contenir de vraies données client, il est donc important de les supprimer avant que le document n'atteigne l'agent, car l'agent a besoin de la structure, et non des valeurs réelles.

Planifier d’abord et itérer sur le plan

Votre agent de codage peut proposer un mode de plan: avant de changer quoi que ce soit, l’agent rédige un plan de ce qu’il a l’intention de faire, pour votre examen. Un plan prend moins de temps à être révisé que le code, donc l'itération en corrigeant l'approche, la mise en page du fichier ou l'ordre du travail est payée avant qu'une seule ligne ne soit écrite. L'approbation du plan uniquement une fois qu'il est lu correctement maintient le développement sur la bonne voie et empêche une architecture incorrecte d'apparaître en retard.

Un plan examiné et accepté est la différence entre une session guidée et une session qui dérive.

La boucle Générer, Vérifier et affiner

La plupart des tâches non triviales s’exécutent en deux ou trois cycles: l’agent génère, vous vérifiez, puis vous affinez ou régénérez. Le fait de vérifier après chaque étape significative, plutôt qu’à la fin uniquement, isole le premier problème et est globalement plus rapide, même lorsqu’il semble plus lent. Pour les projets UiPath, le contrôle est concret: l’agent exécute l’analyseur de workflow et le développement, résout chaque problème et confirme une exécution locale avant que tout ce soit comptabilisé comme terminé.

Itérer quand	Reprendre quand
Le problème est localisé et vous pouvez nommer le correctif	L’agent fonctionne en boucle sur les variations de la même sortie interrompue
La structure est correcte	La structure elle-même est incorrecte
Vous êtes dans un correctif ou deux	Vous en êtes à votre troisième ou quatrième tentative de correction

Partir de zéro n'est pas un échec; il a tendance à être le chemin le plus rapide. Ce que vous apprenez de la formulation est formulé dans une meilleure invite suivante.

Rester sous contrôle

Un agent de codage peut entreprendre des actions difficiles à annuler. Quelques règles garantissent la sécurité du travail:

• Les actions qui modifient un système partagé, telles que la publication ou le déploiement dans Orchestrator, méritent d’être approuvées explicitement.
• Les secrets restent en dehors des invites; stockées en tant que ressources UiPath ou dans un magasin d'informations d'identification, elles sont référencées par nom à la place.
• Les données client réelles n’appartiennent pas à une requête, car l’agent a besoin de la structure, et non des valeurs.
• Chaque modification de package vaut la peine d’être examinée, avec les versions épinglées dans project.json.

L’agent agit sous votre identité UiPath, avec vos autorisations et votre piste d’audit, de sorte que ses actions vous appartiennent effectivement. Pour savoir comment cela s'applique à votre organisation, consultez la section Gouvernance et confiance. Pour ce qu'il faut rechercher dans le travail généré, consultez Examen et validation de la sortie.