Une démo de RPA est satisfaisante : le robot ouvre un écran, copie une valeur, clique et passe au dossier suivant. Techniquement, il pilote l’interface par sélecteurs, accessibilité, clavier ou image. Il imite le chemin humain sans posséder nécessairement un contrat stable avec l’application.

Un orchestrateur planifie les travaux et remet des identifiants à des robots. Chaque robot obtient ses secrets, ouvre les applications, traite un dossier et retourne résultat et logs. Une file garde prêt, en cours, réussi, exception métier ou exception technique.

Automatiser un dossier incomplet

Pour saisir une facture :

1. lire le PDF et extraire fournisseur, numéro, date et montant;
2. valider les champs et détecter le doublon;
3. ouvrir l’ERP avec un compte de robot;
4. chercher le fournisseur;
5. saisir entête et lignes;
6. enregistrer et capturer le numéro AX;
7. déplacer le fichier dans traité;
8. envoyer les rejets dans une file humaine.

Une facture illisible n’est pas un plantage. Elle est une exception métier avec image et champs manquants. Un écran introuvable ou un timeout est technique et peut être repris. Mélanger les deux crée une boucle qui tente vingt fois un fournisseur inexistant.

Le robot porte un identifiant idempotent. Si AX a enregistré avant que l’écran bloque, la reprise cherche le numéro de facture avant de recréer. Chaque étape garde un point de contrôle; un traitement de mille dossiers ne recommence pas à zéro.

L’interface est un contrat fragile

Un bouton renommé, une résolution différente ou une fenêtre surgissante casse un sélecteur. Les API sont préférables lorsqu’elles existent. Pour l’interface, on utilise identifiants stables, attentes sur conditions plutôt que délais fixes et environnement contrôlé. Une suite de tests s’exécute avant une mise à jour applicative.

Les comptes de robot ont le moindre privilège, secrets dans un coffre, sessions verrouillées et actions auditées. Un robot capable de saisir mille factures est un compte puissant. La séparation des tâches peut exiger qu’un humain approuve le paiement.

Le tableau d’exploitation suit débit, âge de file, taux d’exception, étape d’échec et temps humain économisé. Si 30 % des dossiers partent en correction, corriger la source ou le processus vaut mieux qu’ajouter des robots.

Tester le robot avec une fausse application lente

Je construirais un environnement qui peut retarder un écran, renommer un champ, afficher une fenêtre et perdre la réponse après l’enregistrement. Le robot traite un lot connu et doit produire exactement un résultat par identifiant. Les captures et logs indiquent sélecteur, étape et version de l’application. Une mise à jour du poste n’entre pas en production avant ce test. Le scénario mesure aussi la pression sur l’ERP : cent robots lancés ensemble peuvent saturer une interface conçue pour dix humains. Un ordonnanceur limite concurrence et respecte les fenêtres. Cette épreuve révèle la robustesse sans manipuler de vraies factures ni attendre la prochaine panne.

Je choisirais un processus stable, fondé sur règles et avec volume mesurable. Avant la production, je ferais passer doublon, fichier vide, session expirée, fenêtre changée et panne après enregistrement. La RPA est utile lorsqu’elle automatise aussi la preuve et la reprise, pas seulement les clics.