Philippe Bovy, Associate Partner, IT Advisory – KPMG Luxembourg

Séduisantes sur papier et souvent très bien vendues par les sociétés qui les proposent, les solutions RPA (Robot Process Automation) doivent toutefois être intégrées avec beaucoup de soin pour pouvoir produire les résultats attendus. « Nous constatons que beaucoup de clients viennent vers nous lors de la mise en production de la technologie RPA pour nous dire qu’ils rencontrent des problèmes, explique Philippe Bovy, Associate Partner, IT Advisory, chez KPMG Luxembourg. Les proofs of concept sont en effet le plus souvent développés, en silo, par un centre d’expertise qui se charge de les déployer une fois que les principes de l’automatisation ont été démontrés et validés par le métier. Mais la confrontation à la réalité est parfois délicate, avec des exceptions dans les processus qui n’ont pas été prises en compte, les contraintes d’un environnement technique de production pas complètement appréhendé, une mauvaise intégration de la chaîne de sécurité qui pose des problèmes d’accès, etc. »

Architecture technique et monitoring

La cause de ces problèmes éventuels est multiple. Tout d’abord, l’environnement technique dans lequel le robot RPA sera finalement intégré est bien plus complexe que celui dans lequel le POC a été testé. « L’architecture technique du proof of concept est souvent réduite à sa plus simple expression, poursuit Philippe Bovy. Le danger est de procéder à un simple “scaling” : la mise en production du POC entraînant une charge supplémentaire de 50% liée à son utilisation, par exemple, il suffirait d’augmenter l’infrastructure du même pourcentage. Mais les choses ne sont pas aussi simples. »

Les contraintes de monitoring sont aussi souvent sous-estimées. Le fait que les robots RPA soient souvent considérés – à tort – comme étant infaillibles peut également être la source de soucis lors de la mise en production. En effet, les vérifications effectuées sur le POC auront tendance à être moins poussées par rapport aux développements applicatifs traditionnels, limitant de ce fait l’analyse et le traitement des exceptions.  Les failles du robot sauteront par contre aux yeux au moment de la mise en production, sans que des procédures de reprises manuelles ou automatiques n’aient été prévues.

L’utilité d’une bonne gouvernance

Comment éviter ces différents biais pour pouvoir compter sur une solution RPA efficace en conditions réelles ? Pour Philippe Bovy, cela passe d’abord par une bonne gouvernance. « Au sein des organisations, il faut éviter de travailler en silo sur la mise en place d’un robot RPA. Il est au contraire crucial d’impliquer non seulement les collaborateurs du métier, mais aussi ceux de l’IT. Ce sont en effet ces derniers qui sont capables de mettre en place les bonnes procédures en cas d’incident.  et de capitaliser sur l’architecture et les outils de monitoring adaptés. En étant impliqué dès le début du cycle de vie du robot, l’IT sera mieux à même de gérer les problèmes éventuels ou d’identifier l’absence de composant (tel le monitoring) dans la chaîne de valeur des services IT qui sont critiques pour la gestion du RPA. Un centre d’expertise transversal est donc nécessaire quand on se lance dans ce genre de projet. »

Si les arguments commerciaux en faveur de la RPA soulignent régulièrement la rapidité de l’implémentation et la simplification de la maintenance, il est préférable de considérer cet outil comme n’importe quelle autre application. « Il s’agira donc d’identifier les besoins de l’organisation et les processus qui pourront être pris en charge par un robot RPA, construire la solution et la tester consciencieusement, détaille Philippe Bovy. Une fois mise en production, il ne faudra pas non plus faire l’impasse sur sa maintenance et son monitoring. » Enfin, l’Associate Partner de KPMG Luxembourg rappelle que la RPA n’est pas l’unique solution pour les organisations qui veulent introduire des innovations à travers leurs outils informatiques. « La RPA n’est qu’un robot qui fait tourner des applications existantes. On peut aussi prendre le parti d’interagir avec les outils applicatifs en place à l’aide de logiciels ‘low code’ qui permettent de développer des solutions sans passer par le codage, ou en le limitant fortement. » Selon Philippe Bovy, cette solution pourrait s’avérer tout aussi efficace, en fonction des besoins de l’entreprise.