Menu
Les analystes l’avaient annoncé, près de la moitié des grandes entreprises l’auraient mis en œuvre, et l’argent afflue vers les startups du domaine. Décidément le RPA a le vent en poupe !
Adressons-nous au spécialiste
Alors, parlons du RPA puisqu’il s’agit d’une tendance lourde, concrète et à la portée de (presque) tous (on ne peut pas en dire autant de l’IA par exemple !). Pour ne pas écrire de bêtises à ce propos, j’ai interrogé mon vieux camarade Pierre Col qui est le responsable de la communication pour le Robotic Process Automation chez SAP. En effet, le grand éditeur allemand a racheté le français Contextor en novembre 2018 (voir à https://www.journaldunet.com/solutions/cloud-computing/1418755-pourquoi-sap-rachete-contextor-star-francaise-de-la-robotic-process-automation/) où Pierre travaillait. Il fait de même désormais, mais avec l’étiquette SAP.
Cet échange avec Pierre a été très éclairant… le RPA est, en fait, l’amélioration la plus récente d’un procédé bien connu dans les années quatre-vingt-dix : le revamping.
Le revamping ou l’éternel retour
À cette époque-là, le client-serveur est au centre des attentions de toutes les DSI. Cette architecture permet enfin de tirer parti des PC en réseau sur le plan applicatif. En réalité, c’est surtout vrai quand on veut relier des applications clientes (avec interface graphique) à des serveurs modernes, ceux qui sont au cœur des réseaux locaux et qui hébergent des bases de données relationnelles qui sont bien taillées pour ce rôle. Mais si on veut moderniser les applications traditionnelles qui reposent sur mainframes, c’est tout de suite (beaucoup) plus délicat…
Pour pallier à cet obstacle majeur, le “revamping” a apparu. Cette technique astucieuse proposait d’ajouter une couche supplémentaire aux applications 3270 (ou autres) afin de masquer leur interface rudimentaire (pour ne pas dire pire) et d’apporter les joies de l’interface graphique aux utilisateurs. Ainsi, le tour de la modernisation était joué !
Sur le plan théorique, le revamping promettait d’apporter le meilleur des deux mondes aux DSI soucieuses d’aller vers le client-serveur sans devoir réécrire leurs applications pour mainframe. En pratique, cette “fusion idéale” n’a pas toujours donné les résultats espérés pour diverses raisons : consommation de ressources système importantes (quand il fallait condenser plusieurs écrans 3270 en un seul dialogue graphique), outil de “screen scrapping” (https://en.wikipedia.org/wiki/Data_scraping#Screen_scraping) pas assez matures ou encore désynchronisation du revamping dès que l’application mainframe évoluait, même légèrement.
Bref, le revamping était un peu tombé dans l’oubli, mais il revient en force désormais grâce au RPA !
Le RPA ou l’encapsulation d’applications
Pour automatiser les applications, les outils de RPA vont procéder un peu de la même façon que les outils de revamping naguère : on en analyse la surface (l’interface utilisateur) et on simule les actions de l’utilisateur avec une logique conditionnelle. Les applications prises en compte se retrouvent ainsi complètement enveloppées et enfouies au sein des serveurs pour une exécution automatique dans 80 à 95% des cas. Un exemple parlant avec cet automate dédié aux opérations de virement refusées. Le robot réalise l’opération à partir d’un fichier journalier de 800 à 1 000 lignes. Le processus est automatisé à 95%, seuls les 5% de cas restants nécessitant une validation humaine après coup.
Bien entendu, le RPA va plus loin que le revamping de naguère : en vue d’extraire les informations qui se trouvent parfois dans des documents non structurés, les spécialistes ont parfois recours à des outils de type IA. Contextor a noué des liens avec des acteurs de l’analyse sémantique (Expert System, ERDIL), de la reconnaissance optique de caractères (Itesoft, Moonoia), de la génération automatique de texte (Yseop), des chatbots (Inbenta) ou de la dématérialisation (Docapost).
Certains processus nécessitent des allers-retours permanents entre l’humain et la machine. Donc, l’encapsulation totale doit pouvoir faire place à un mode de fonctionnement qu’on pourrait appeler du « coworking ». Prenons l’exemple d’un service d’assistance qui propose la location d’un véhicule à un assuré en panne. L’opérateur devait initialement mettre les clients en attente pour consulter le site du loueur. Aujourd’hui, grâce à l’automate mis en place, il clique simplement sur un bouton. L’automate récupère les informations nécessaires (la géolocalisation de l’assuré, entre autres) puis ouvre la page du loueur avec les voitures qui conviennent. Une banque utilise les automates du RPA pour gérer l’ouverture de comptes bancaires. Un robot va balayer sept sites différents pour s’assurer que le nouveau client n’est pas interdit bancaire ou fiché par Interpol avant de valider (ou non) la création du compte.
Présents sur le poste de travail, les automates de éditeurs de RPA peuvent en profiter pour analyser l’activité réelle de l’utilisateur. Ils évoluent ainsi vers le « process mining », c’est-à-dire la capacité à déceler des leviers d’optimisation qui viendront soulager le travail d’un employé en mesurant le temps passé sur certaines applications, le nombre de clics ou le passage d’une application à une autre via le fameux raccourci clavier Alt + Tab.
Les automates RPA sont présents sur le poste de travail comme sur les serveurs. Dans ce dernier cas, ils permettent des automatisations poussées grâce à la “connexion” entre processus, un peu à la façon des “middlewares cloud” que nous avions déjà évoqués dans une précédente chronique (voir à https://www.redsen.com/chronique-alain-lefebvre/les-middlewares-cloud-pour-une-integration-no-code/).
Les bénéfices immédiats
On trouve plein d’exemples de processus ainsi largement automatisés avec un bénéfice évident à la clé : quand un processus quotidien (comme le traitement des virements bancaires rejetés au sein d’une grande banque nationale déjà évoqué plus haut) nécessitait cinq personnes à plein temps pour en valider les résultats, le RPA permet de faire tomber ce chiffre à une personne à temps partiel, une vraie économie !
On imagine facilement nombre de cas similaires et le recours au RPA se justifie facilement sur le plan financier. Mais, selon moi, ce n’est pas sur ce point que le potentiel du RPA est le plus intéressant…
Encapsulation des systèmes hérités
Des nouveaux outils sont en train de trouver leur place sur la marché. Il s’agit de logiciels qui permettent de placer le “mainframe sur le cloud” et de façon tout à la fois transparente mais aussi (c’est important) avec le minimum d’impact lors de ce “déplacement”…
Encapsulation sans impact au niveau applicatif
D’un côté, nous pouvons traiter ces anciennes applications sans avoir à y toucher grâce à l’arsenal du RPA. Bien sûr, on pense à l’automatisation, mais pas seulement : ce procédé d’encapsulation sans impact permet aussi d’adresser ces systèmes applicatifs “hérités” pour des besoins d’interconnexion toujours délicats, mais aussi de plus en plus nécessaires si on veut un traitement numérique tout au long de la chaîne.
Encapsulation sans impact au niveau système
D’un autre côté, nous pouvons même faire migrer ces mainframes autrefois inamovibles vers le cloud en toute transparence. Des éditeurs comme Lzlabs proposent des outils de migration et d’encapsulation permettant de placer tout le code (tout !) d’un mainframe dans un serveur Linux qui va ensuite fonctionner sur le cloud en se faisant oublier. On s’aperçoit que Lzlabs insiste sur le fait que le code source n’est PAS nécessaire et que ce transfert s’effectue sans avoir besoin de recompiler quoi que ce soit (voir à https://www.lzlabs.com/services/mainframe-modernization/). Tout ce qui tourne encore sur grands systèmes est concerné : CICS, Cobol & PL/1, bases de données relationnelles & hiérarchiques et même le batch !
Une ouverture avec des conséquences super-positives !
Avec des moyens pareils, on possède une opportunité concrète de moderniser le système d’information sans avoir à prendre des risques importants sur les plus anciennes couches tels qu’une toujours délicate recompilation… On va pouvoir faire tourner nos systèmes hérités sur des plateformes dernier-cri avec tous les avantages qui y sont liés. Cela permet d’envisager de s’appuyer sur ce patrimoine applicatif pour des développements futurs et limiter les projets cauchemardesques des DSI (le projet type de refonte technique sans ajouts fonctionnels). En effet, expliquer aux directions métier que, pendant plusieurs mois, on va dépenser de l’argent sans apporter de valeur métier est un exercice de style qui est toujours délicat. Voilà une bonne raison de plus de s’intéresser au RPA.
