Du propre aveu de la DSI de La Poste, choisir de mettre en œuvre une RPA (robotisation de processus) à base de briques open-source n'avait absolument rien d'évident. Les offres d'éditeurs sont en effet tout à fait matures, disposent en standard de tous les connecteurs pertinents et bénéficient de possibilités de formation bien balisées, parfois même gratuites. Pourtant, il y a un an, La Poste a fait le choix de développer sa propre plate-forme de RPA à base de briques open source, baptisée sans trop d'imagination OpenRPA. A l'heure du bilan, le choix s'avère judicieux.

Le premier critère qui a poussé La Poste à s'intéresser à l'open-source est, évidemment, la question du coût. En effet, les scripts à créer étaient très divers et extrêmement répartis. Dans un tel contexte, les solutions d'éditeurs sont vite très onéreuses, ayant en général un modèle économique basé sur le nombre d'environnements d'exécution. La Poste voulait multiplier librement les cas d'usages sans avoir à se préoccuper d'une facture qui risquait d'exploser.

Un contexte particulièrement favorable

Mais les solutions d'éditeurs disposent de nombreux connecteurs et sont aisés à intégrer. A l'inverse, les solutions open-source nécessitent souvent un travail qui représente évidemment un coût. Or le SI de La Poste se présente essentiellement sous la forme d'applications en mode web. Et les quelques applications lourdes (SAP, Tableau...) étaient bien prises en compte naturellement par les scripts choisis. L'inconvénient du choix de l'open-source était donc inexistant au sein du groupe.

Un frein ordinaire au déploiement de solutions un peu exotiques est la question des compétences. Trouver les bons informaticiens expérimentés peut être une gageure. Or il se trouve que, si les solutions éditeurs proposent des formations bien balisées et accessibles, les compétences disponibles sur le marché sont limitées. Les informaticiens sont par ailleurs peu motivés pour s'investir dans l'acquisition de compétences sur une solution propriétaire aux perspectives forcément limitées. A l'inverse, les scripts choisis dans OpenRPA sont en langage Python et il n'y a aucune difficulté à trouver les compétences nécessaires, ni, le cas échéant à les monter en compétences.

Un assemblage de briques

« Nous avons mis en oeuvre une architecture OpenRPA capable de proposer un niveau de service et d'expérience utilisateur au moins équivalent à celui des solutions éditeur sous la forme d'un assemblage de différentes briques open-source éprouvées » a précisé Eric Lechevallier, responsable de l'offre de service RPA au sein du groupe La Poste. Si les scripts sont développés en Python, ils animent des modules open-source dédiés chacun à un environnement : Selenium pour les interfaces web, Pywinauto pour les clients lourds en environnement Windows, OpenPyxl pour les fichiers Excel, etc. L'usage du Python permet aussi des interactions avec les couches basses (bases de données...) ou les API du système d'information. Accessibles au travers d'un portail dédié, les robots développés s'exécutent dans des machines virtuelles Windows afin que leur environnement de fonctionnement soit bien maîtrisé. Certaines bibliothèques ont cependant posé trop de problèmes et ont dû être écartées (par exemple Tesseract pour l'analyse d'images).

Malgré tout, le choix fait a rencontré des obstacles insurmontables sur des applications techniquement obsolètes (applications web dédiées à IE6/ActiveX, certains modules SAP...). A l'inverse, les métiers ont été très satisfaits des possibilités offertes et du niveau de facilité. Il reste à mettre en œuvre une exploitation des logs générés par les scripts en environnement ElasticSearch/Logstash/Kibana pour faciliter le pilotage et la supervision des robots.