Pourquoi une application RPA compatible ?
La RPA (Robotic Process Automation) intègre les applications et automatise les processus sans modifier les applications. Mais bien que les outils de RPA soient performants, disposer d’applications qui facilitent le travail des robots améliore les performances et réduit les coûts.
En effet, les applications avec Interface Home Machine que nous concevons aujourd’hui ont une très grande probabilité d’être utilisées par un robot de RPA dans le court ou moyen terme. Donc préparons nous à cette éventualité : assurons que toute application est RPA compatible ! En plus ça ne coûte rien !
Dans ce cadre, nous avons mis au point des règles de conception des applications qui les rendent RPA compatibles. Nous proposons ici de vous les partager.
Règles de conception de la RPA compatibilité
Ce qui rend RPA compatible
Des identifiants uniques
Certains outils (UiPath notamment) utilisent l’arbre des objets graphiques affichés à l’écran pour sélectionner un objet en particulier. Il est nécessaire dans ce cas, que son « sélecteur », c’est à dire les éléments du chemin dans l’arbre soient les plus discriminants possibles. A la conception, on fera en sorte que chaque élément puisse être repéré aisément par un identifiant unique.
Des images uniques et discriminantes
Tous les outils de RPA ont des capacités de repérage d’image dans une fenêtre. C’est ainsi que l’on peut repérer un label, l’existence d’un champ… On choisira des images qui sont assez différentes les unes des autres pour éviter les ambiguïtés. De plus il est nécessaire de faire attention aux variations de reconnaissance en fonction de la résolution de l’écran sur lequel le robot travaille.
Des images de taille limitée
Les images lourdes sont simplement longues à vérifier. Mais elles sont souvent un bon discriminant que le concepteur a tendance à utiliser. Donc pour éviter des pertes de performance, les images doivent être assez légères.
Des labels et champs spatialement stables
Bien que certains outils soient particulièrement résistants à ce genre de problème (UiPath : The RPA challenge), il est préférable de faire en sorte que d’écran en écran, les labels et les champs associés soient placés de manière relative constante.
Des caractères simples pour l’OCR
On évite ce genre de police de caractères : L’OCR n’apprécie pas vraiment !
Des tests (de compatibilité) dès le développement
Plutôt que d’utiliser les outils de test IHM traditionnels du développeur, on passe aux outils de RPA qui font l’affaire. Non seulement on teste le logiciel en cours d’élaboration, mais de plus on valide la bonne compatibilité du logiciel avec la RPA. Nous recommandons d’intégrer la RPA à l’usine de développement.
Des tableaux de données structurés
Le travail dans des tableaux est très courant et plus les tableaux sont « propres » et comportent des patterns stables (noms de colonne discriminants, champs de type strictement identiques et format dans une même colonne…) plus l’usage par le robot est fiable. Une pagination clairement accessible est nécessaire.
Ce qui nuit à la RPA compatibilité
Des interfaces graphiques déportés évités
Les interfaces purement graphiques ne donnant pas l’accès à l’arbre des objets affichés exigent de l’OCR et de la reconnaissance d’image. Donc le robot est moins performant. On évitera dans la mesure du possible les interfaces à base de Terminal Server, les machines virtuelles…
Des objets fugitifs
Les robots ont du mal de saisir les objets fugitifs à l’affichage. Il faut éviter les fading out et autres animations.
Les commandes sonores
Les robots ne sont généralement pas équipés de reconnaissance sonore. Mais cela va sûrement évoluer !
Et le contraire de tout ce qu’il faut faire !!
Nous fournissons des prestations d’accompagnement à la conception des applications pour la RPA et l’intégration de la RPA dans les tests et l’usine de développement. N’hésitez pas à nous contacter : info@averatio.com – +33(0) 1 88 32 90 58
