S’agit-il de RPA ?

/ by
Reading Time: 6 minutes
L’automatisation des processus robotiques (RPA) est-elle de la science-fiction ou de la science réelle ?  A-t-elle un rôle à jouer dans l’histoire du CloudTrade ? Dans ce blog, le troisième de sa trilogie expliquant la solution de saisie de données CloudTrade, Richard Develyn, directeur technique de CloudTrade et passionné de films de science-fiction, met à nu les limites de la RPA, en exposant les défis très réels liés à la couverture, à la complexité et à l’étendue.

Dans le film de Fritz Lang de 1927, Metropolis, un ouvrier se tient devant une horloge de taille humaine et fait bouger les aiguilles de l’horloge pour indiquer différentes ampoules disposées à l’extérieur du bord de l’horloge. Toutes les quelques secondes, deux des ampoules s’allument, et il est clair que le travail de l’ouvrier consiste à déplacer les aiguilles pour indiquer ces ampoules particulières plutôt que n’importe laquelle des autres.

C’est ce que j’appelle un Processus Robotique.

Mais au fil du film, il devient évident que la tâche de l’ouvrier ne se limite pas à surveiller les ampoules allumées et à déplacer les aiguilles de l’horloge en conséquence. Sur le même panneau que l’horloge sont disposés plusieurs jauges et cadrans qui sont en quelque sorte affectés par ce que l’homme fait, et qui semblent avoir des seuils de sécurité déclenchés si quelque chose commence à mal tourner. À en juger par la réaction de l’homme lorsqu’il est fatigué et que les aiguilles des cadrans commencent à grimper de façon alarmante vers leurs zones rouges, c’est aussi son travail de garder ces cadrans sous contrôle, et il semble y avoir de très grands leviers sur le côté que nous supposons qu’il doit utiliser « en cas d’urgence ».

Fritz Lang fait un point important sur l’automatisation dans ces scènes, un point qui a imprégné notre vision des futurs dystopiques de la science-fiction depuis lors. Faire exécuter des processus robotiques aux humains peut être déshumanisant, mais remplacer les humains par des robots risque de provoquer une catastrophe si ces processus soi-disant robotiques commencent à se comporter de manière inattendue.

Ce problème n’est pas résolu par la RPA, car les « bots » RPA sont des sortes de robots particulièrement stupides. Les bots RPA n’obtiennent leurs avantages par rapport à d’autres formes de l’informatique, comme la programmation, que parce qu’ils apprennent ce qu’il faut faire en observant leurs homologues humains et en reproduisant ensuite leur comportement humain, soi-disant stupide.

Placez donc un bot RPA devant l’ouvrier de l’horloge de Metropolis, et ce bot va se heurter à trois problèmes assez fondamentaux.

Le premier est que, même en fonctionnement normal, le nombre de combinaisons possibles pour deux lumières autour de l’horloge est 2 116 (il y a 46 lumières autour de l’horloge, 43 étiquetées 1-43 plus trois autres étiquetées I, II et III), et certaines de ces combinaisons peuvent se produire très rarement. Un bot RPA ne peut pas être programmé (à proprement parler, mais voir plus loin) avec l’instruction « déplacer les aiguilles de l’horloge vers les ampoules allumées », tout ce qu’il peut faire est d’observer l’ouvrier de l’horloge humain et de copier, bêtement, ce que fait l’ouvrier humain. La base de connaissances du bot consistera donc en une série d’instructions du type « lorsque les ampoules 12 et 37 sont allumées, et aucune autre, déplacez les aiguilles de l’horloge sur les positions 12 et 37 ». Si cette combinaison particulière ne se produit pas lors de la formation, le robot ne saura pas quoi faire si cette combinaison se produit ensuite en « live ».

Je suppose que l’on pourrait classer ce problème comme une insuffisance de formation, mais le problème est plus profond que cela. Regarder un opérateur travailler sur une machine pendant une période déterminée ne constitue pas un plan d’apprentissage très judicieux. Que se passe-t-il si la moitié des ampoules ne s’allument qu’en hiver et que vous avez formé votre robot en été ? Ce problème devrait être appelé « Couverture », c’est-à-dire savoir quelle est la gamme des possibilités, par rapport à laquelle vous pouvez mesurer la suffisance. Si vous n’avez pas la maîtrise de la Couverture, vous n’avez aucune idée de la qualité de la formation de votre bot.

Le second problème se produit lorsque le processus robotique présente une certaine complexité sous-jacente que le bot ne peut pas percevoir, comme par exemple si l’ordre dans lequel l’opérateur déplace les aiguilles dépend d’une des jauges situées sur le côté que l’opérateur surveille. Le bot peut voir ce que l’opérateur voit et noter ce que l’opérateur fait en conséquence, mais il n’a aucune idée de la façon dont l’opérateur pense.

Ce problème devrait être appelé celui de la Complexité, qui est reconnue et insidieuse dans le monde de la RPA. On découvre plus tard que des opérations qui semblent simples sont plus complexes que l’on ne le pensait au départ. La situation empire s’il s’avère que les opérateurs eux-mêmes ont une sorte d’état interne que le bot doit découvrir, comme celui porté dans l’instruction : « si le cadran entre dans la zone rouge trois fois en une heure, alors inversez ce que vous faites avec les aiguilles ». Si les opérateurs font preuve de jugement ou de compétence dans ce qu’ils font, le problème s’aggrave encore, comme par exemple dans : « Assurez-vous que cette jauge se trouve entre ces deux lignes de sécurité ; si elle descend en dessous de la ligne inférieure, déplacez les aiguilles plus rapidement, si elle monte au-dessus de la ligne supérieure, déplacez les aiguilles plus lentement ».

Bien sûr, vous pouvez augmenter la complexité du bot lui-même pour qu’il saisisse ces choses et les apprenne, mais très vite, vous vous demanderez si vous n’auriez pas dû écrire un programme au départ.

Le troisième problème survient si, par exemple, une des ampoules explose ou si les aiguilles se mettent à bouger toutes seules de manière inattendue. L’opérateur humain fera probablement quelque chose raisonnable, comme changer l’ampoule ou lâcher les aiguilles, même s’il n’a pas été auparavant formé pour le faire. Les systèmes créés pour être manipulés par des humains sont construits en partant du principe que ce sont des humains, et non des bots, qui vont s’asseoir devant eux. Parfois, tous les comportements de ces systèmes seront documentés, parfois non, mais on supposera toujours qu’un être humain raisonnable, avec un cerveau organique dans sa tête, sera capable de réagir de manière sensée à tout ce qui peut arriver. Hélas, les bots ne sont pas des êtres humains, et il ne sert à rien de faire semblant. Les bots ne peuvent pas penser par eux-mêmes, c’est pourquoi les interfaces informatiques sont construites d’une manière très différente des interfaces qui sont construites pour les humains.

Et puis il y a la question du contrôle du changement. Si Metropolis Central décidait d’améliorer ses machines à horloges de manière que, de temps en temps, un petit message apparaisse disant « éloignez-vous » suivi par le grésillement électrique des aiguilles de l’horloge, alors il ne fait aucun doute dans l’esprit de ses ingénieurs que les opérateurs de l’horloge comprendront assez rapidement ce qu’ils doivent faire. Les bots, cependant, seront sans cesse électrocutés.

Ce dernier problème est celui de l’Étendue. Un pauvre bot RPA ne saura pas quoi faire quand il se passera quelque chose en dehors des données saisies et des données de sortie dont il a été informé, même une fois qu’il aura dépassé le problème de la Couverture. Il ne peut pas lire le message « éloignez-vous » s’il ne l’a jamais rencontré auparavant, ce qui sera certainement le cas si le message n’a pas pu se produire lors de la formation du bot car Metropolis Central a ensuite modifié le fonctionnement des machines à horloges sans se préoccuper d’informer les vendeurs de bots RPA.

La seule façon de résoudre ces problèmes est de programmer les bots en utilisant une sorte de langage de script ou de programmation (et une spécification appropriée de contrôle des changements de Metropolis Central). Mais une fois que vous avez commencé à le faire, vous ne pouvez plus les appeler « bots RPA », car vous n’avez plus cette simplicité de bot RPA qui était la raison pour laquelle vous avez commencé à les utiliser en premier lieu.

La programmation nécessite l’analyse, la conception, le codage, les tests, la gestion, la planification du projet, la maintenance, des programmeurs récalcitrants, des logiciels bogués, des délais dépassés et tous ces autres petits problèmes auxquels vous avez tenté d’échapper en déployant vos bots RPA. Les bots RPA qui sont scriptés ne sont que des programmes prétendant être quelque chose qu’ils ne sont pas.

Si le problème que vous souhaitez résoudre nécessite de la programmation, il suffit de serrer les dents et de l’écrire, ou de demander à quelqu’un d’autre de l’écrire. Utilisez des bots RPA programmables si vous le souhaitez, mais acceptez toute la douleur que la programmation entraîne. Si vous pensez pouvoir vous passer de tout cela avec la RPA, assurez-vous à deux ou trois reprises que vous essayez vraiment d’automatiser un processus robotique avant de vous lancer.

Les véritables bots RPA, c’est-à-dire ceux qui ne sont pas programmés, ne peuvent apporter une solution qu’aux problèmes les plus simples. Malheureusement, les lois des vœux pieux semblent suggérer que si vous pensez avoir un problème simple et bon marché, vous vous convaincrez qu’il vous suffit d’une solution simple et bon marché, et ne réaliserez que vous avez fait une erreur coûteuse que lorsque vous aurez déployé vos bots RPA sur le terrain.

À propos, nous ne faisons pas de RPA à CloudTrade. Nos problèmes ne sont pas d’ordre robotique. Nous programmons.

Catégories : Blog