UiPath : tester l’agent, le robot et la reprise après incident

Une automatisation réussie peut produire un résultat incorrect. Le robot a terminé son exécution, l’agent a répondu dans le format prévu, mais le dossier a été enregistré deux fois ou sous la mauvaise identité. Pour accepter une chaîne UiPath, je propose de partir de l’effet observable dans le système métier plutôt que du statut vert de chaque composant.

Cette recette s’adresse aux équipes qui relient un agent IA à des workflows RPA ou à des API. Elle complète mon accompagnement UiPath : une méthode de contrôle technique, de diagnostic et de préparation à l’exploitation. Les situations décrites ici sont des scénarios de test proposés, sans résultats de benchmark ni références clients implicites.

Le contrat décrit les données utilisables par le processus et les circonstances dans lesquelles aucune action ne doit suivre. Une réponse JSON valide ne suffit pas. Il faut définir les valeurs autorisées, les informations obligatoires et la façon de signaler une incertitude ou une demande hors périmètre.

Dans un exemple pédagogique de qualification de dossier, la sortie peut contenir un identifiant, une catégorie, une justification et les documents manquants. Le modèle ne doit pas inventer un identifiant pour satisfaire le schéma. Lorsque la preuve manque, le contrat prévoit un état de revue plutôt qu’une valeur artificiellement complète.

La documentation des évaluations UiPath permet de travailler avec des entrées, des sorties attendues et des évaluateurs. Je recommande d’y associer des assertions déterministes : identifiant issu de l’entrée, catégorie connue, absence de champ sensible non requis. Ces assertions vérifient ce que le processus consomme, indépendamment du caractère convaincant de la justification.

Le contrat devient versionné. Une nouvelle catégorie, un champ supprimé ou un changement de signification impose une décision de compatibilité. Sans cette discipline, un robot peut continuer à s’exécuter tout en interprétant différemment les réponses de l’agent.

Le processus décrit le parcours ; la recette vérifie que chaque action possède un propriétaire, un contexte et un résultat identifiable. La documentation d’architecture Maestro distingue la conception, l’exécution, le déploiement et les surfaces d’exploitation. Cette séparation aide à poser les questions au bon niveau.

Je distingue dans le dossier de recette la définition du processus, la configuration de l’environnement et l’instance effectivement exécutée. Une définition correcte peut être publiée avec une mauvaise connexion. Un environnement convenable peut exécuter une version ancienne. Une trace d’instance sans référence à la version ne permet pas de reproduire le constat.

Pour chaque test, conservez donc une référence au scénario, aux entrées, à la version du processus et au système cible. Les secrets restent hors du rapport. Le but est de retrouver les conditions de l’essai sans diffuser les identifiants d’accès. Ce principe rejoint le dossier de preuve d’une réponse IA, avec un prolongement vers les mutations métier.

Coupez la confirmation après l’action, puis relancez le traitement : le résultat attendu est une seule opération métier. Cette situation diffère d’une panne survenue avant l’envoi. Le système cible a pu accepter la demande, tandis que le workflow ignore encore son résultat.

Prenez une opération fictive de création de dossier. La demande porte une référence externe stable. Après son enregistrement, simulez une interruption avant le retour de confirmation. À la reprise, l’automatisation doit rechercher cette référence ou utiliser une capacité d’idempotence explicitement disponible. Une nouvelle création non contrôlée est un défaut, même si les deux exécutions apparaissent techniquement valides.

La documentation des queues et transactions fournit des mécanismes de suivi des traitements. Le test reste nécessaire : la présence d’une queue ne garantit pas, à elle seule, l’unicité d’une opération dans une application externe. L’identifiant de transaction interne et l’identifiant métier peuvent répondre à des usages différents.

Documentez aussi le résultat attendu lorsqu’une vérification d’existence échoue. Une base indisponible ne doit pas être interprétée comme la preuve qu’aucun dossier n’existe. Le traitement peut attendre ou passer en revue, mais il ne doit pas transformer l’absence de réponse en autorisation de répéter une action.

Testez une action permise et la même action avec un droit retiré, en contrôlant l’état final dans la cible. Un message d’erreur affiché par l’agent ne prouve pas qu’aucune modification n’a eu lieu. Il faut vérifier les enregistrements, les accès et les effets secondaires correspondant au scénario.

La recette comporte au moins un compte autorisé, un compte restreint et une connexion arrivée à expiration. Les comptes ne reçoivent que les droits nécessaires au test. Évitez d’utiliser un administrateur pour tous les essais : il masquerait précisément les défauts que la mise en production peut rencontrer.

Une demande hors périmètre doit également être refusée. Par exemple, si le processus peut créer une demande de revue, il ne peut pas se transformer en outil de suppression à partir d’une instruction contenue dans un document. Mon article sur l’injection de prompt indirecte propose des cas adverses à intégrer au jeu d’essai.

Le retrait d’un accès doit être testé après une exécution réussie. Cela permet de vérifier que la reprise ne réutilise pas un contexte ancien d’autorisation. Le rapport indique le délai observé et les limites de l’environnement. Il ne conclut pas à une révocation instantanée sans l’avoir effectivement mesurée.

Oui : si la proposition, les données ou l’action changent après approbation, la validation initiale ne couvre plus nécessairement l’opération suivante. Je recommande de relier l’approbation à une version précise de la proposition, et de rejeter une exécution dont le contenu a divergé.

Un test simple consiste à faire approuver un dossier, puis à modifier une donnée importante avant le passage au robot. Le résultat attendu doit être défini avec le métier : bloquer, demander une nouvelle revue ou appliquer une règle documentée. Une approbation générique et sans date laisse ce comportement indéterminé.

La recette doit aussi simuler l’absence du valideur, le refus, l’expiration et une réponse reçue deux fois. Une demande en attente doit rester identifiable par l’équipe de support. L’opération ne devient pas autorisée simplement parce qu’un délai a expiré ; une règle d’escalade ne doit pas être confondue avec un accord automatique.

Conservez les cas qui exposent une frontière du système : données manquantes, ambiguïté, droits insuffisants, interruption et reprise. Une collection de demandes ordinaires mesure surtout la conformité au scénario nominal. Elle ne prouve pas la maîtrise des situations qui coûtent le plus cher en exploitation.

Je propose un socle de cas bornés : document lisible, document incomplet, deux sources contradictoires, identifiant absent, catégorie inconnue, instruction malveillante, cible indisponible et confirmation perdue. Chaque cas possède un résultat attendu observable. Le nombre de tests s’ajuste au périmètre, pas à une formule universelle.

Un test automatisé peut vérifier un schéma ou l’absence de doublon. Un jugement humain reste utile pour apprécier une synthèse. Un évaluateur utilisant un modèle peut aider à trier des sorties, mais son accord n’est pas une preuve indépendante absolue. Les cas graves doivent posséder un critère explicite que l’équipe comprend et peut reproduire.

Lorsqu’un incident réel apparaît, ajoutez une version expurgée au jeu de non-régression. Conservez ce qui explique le défaut sans recopier inutilement les données personnelles du dossier. L’intérêt est de prévenir sa réapparition lors d’un changement de prompt, de modèle, de connexion ou de processus.

La décision doit porter sur un périmètre testé et sur la capacité à exploiter ses échecs. Un bon score moyen peut cacher une action indésirable grave. Je recommande de séparer les échecs bloquants, les cas acceptés sous revue et les défauts de confort.

Un défaut qui crée une opération non autorisée ou un doublon peut bloquer le lancement du parcours concerné. Une demande renvoyée en revue selon la règle prévue peut être un comportement correct. Un délai plus long que souhaité constitue un autre type de problème. Les regrouper dans un pourcentage unique retire l’information nécessaire à l’arbitrage.

Avant le lancement, vérifiez que l’équipe sait retrouver un dossier, suspendre le parcours, reprendre un incident et joindre le responsable métier. Un audit IA peut établir ces preuves et classer les corrections. Il ne transforme pas une fonctionnalité en préversion en garantie de service, et ne remplace pas une qualification des obligations propres à votre usage.

La première mise en service peut rester limitée à une catégorie et à un volume borné. Les cas exclus suivent le traitement existant. L’extension est décidée à partir des résultats observés et de la capacité du support, pas parce que la démonstration initiale a été convaincante.

Documentation consultée le 8 octobre 2026. Les critères de recette et les scénarios sont une proposition méthodologique d’Anand Candassamy. Les capacités doivent être confirmées dans la version et l’environnement effectivement utilisés.