Que l'on parle de la ville de Milan ou de la mission data écossaise, le volume des processus traités, le nombre de services concernés ou encore la complexité des organisations conduisent les services publics à se tourner vers l'automatisation de leurs processus. La capitale lombarde, par exemple, compte 4 millions d'habitants auxquels il faut ajouter un peu plus d'un million d'usagers de la ville. Elle emploie 14 000 employés municipaux dans 22 services différents. Et son activité s'exécute au travers de quelque 300 processus. « C'est pour gérer cette complexité que nous avons créé le service Citizen expérience que je dirige », raconte Luca Curioni, à l'occasion d'une table ronde sur le sujet lors d'Appian Europe 2024, qui s'est tenu à Londres le 3 décembre. « Nous avons donc décidé de nous tourner vers plusieurs plateformes digitales afin de créer des services efficients orientés vers le citoyen, dont celle d'Appian ».

La problématique de Cambridge University Press and Assessment, l'entité d'édition et de certification de l'Université de Cambridge, est assez proche. De nombreux processus répartis dans une structure à l'organisation complexe. L'organisation a commencé dès 2020 par un PoC d'automatisation du processus d'intégration des étudiants américains avec la plateforme d'Appian. Après une progression régulière, l'entité de Cambridge University dispose déjà de 10 applications et d'une centaine de processus en RPA, qui concernent toute la structure. La majorité intéresse la partie académique, mais certains visent la finance, les RH, etc.

Capitaliser sur les premiers processus automatisés

Tous les intervenants s'accordent sur la nécessité d'avancer pas à pas dans ce type de démarche pour tester à la fois la technologie, les résultats, l'adhésion des métiers, etc. D'autant que les leçons tirées des premiers processus remis à plat permettent une progression de plus en plus rapide. Milan a, par exemple, choisi de se lancer avec des systèmes à faible niveau de risque. « Nous avons débuté avec les services de parking pour les personnes handicapées, détaille Luca Curioni. Nous avons livré le produit en 6 semaines et, depuis, nous poursuivons les développements en nous appuyant sur les ensembles de processus déjà développés et réutilisables ». La progression a été rapide, puisque Milan dispose désormais de 24 processus et de pipelines de développement d'applications dans 8 domaines différents. Autre facteur de rapidité, la municipalité a choisi de conserver son organisation data en place pour éviter une migration des données vers les nouveaux systèmes, et se sert de la plateforme Appian pour l'orchestration de celles-ci.

« Nous avons signé avec Appian l'an dernier, précise de son côté Hugh Wallace, CIO de Research Data Scotland. Nous avons mis entre 4 et 5 mois pour livrer le premier MVP (minimal viable product) et pour mettre en place les bases de l'automatisation. » Une démarche qui a permis, comme à Milan, de capitaliser sur ce premier développement pour passer plus rapidement à l'échelle ensuite. Le gouvernement écossais a créé Research Data Scotland en 2021 afin de donner à ses citoyens un accès plus rapide et simple à la data publique, en particulier pour des sujets de recherche, à travers un parcours digitalisé de bout en bout.

Ne pas digitaliser l'inefficacité

Tout comme dans le secteur privé, l'automatisation des processus passe cependant par leur remise à plat préalable et leur rationalisation. Un véritable défi pour beaucoup de services publics face à des métiers et des utilisateurs qui ne sont pas toujours prêts pour cette aventure. Pour le directeur de la Citizen expérience de Milan, avec l'important volume de services et de processus sur lesquels son équipe doit travailler, pas question d'automatiser les processus sans les avoir étudiés et 'nettoyés'. « Digitaliser l'inefficacité ne sert qu'à créer de l'inefficacité digitalisée. Il faut absolument éviter cela. C'est d'autant plus important dans notre cas, celui du service public, car l'utilisateur final aussi est actif ».

A l'Université de Cambridge, l'équipe de Mark Lloyd comprend des analystes capables d'explorer ces processus. « Nous sommes formés à 6Sigma, indique-t-il ainsi. Nous appliquons la méthode lean à nos processus avant de les automatiser ». Selon lui, il reste essentiel d'écouter les utilisateurs, de ne pas prendre leurs explications sur le fonctionnement des processus à la légère, même si au sein d'une même équipe elles ne sont pas toujours cohérentes. Pour autant, il faut en profiter pour rationaliser, même si cela crée des mécontentements, au démarrage en particulier. « C'est aussi une démarche continue », insiste de son côté David Bates, Head of IT and data de Social Work England, régulateur du travail social en Angleterre. « Des changements adviennent en permanence dans les processus, et on ne peut pas se permettre de ne pas les prendre en compte », ajoute-t-il.

Des métiers trop enthousiastes

Quand il s'agit d'automatisation, les craintes des employés de se voir déclassés, voire privés de leur emploi, restent importantes. Et le service public n'échappe pas au phénomène. Reste que la rapidité de mise à disposition de services ou d'applications via la RPA, voire le no code ou low code, peuvent parfois provoquer des réactions contre-intuitives. Mark Lloyd évoque ainsi, avec une certaine émotion, le débord d'enthousiasme qu'inspirent parfois ces solutions. « Ce sont des périodes intéressantes, constate-t-il, un brin d'ironie dans la voix. Tout le monde vient nous voir pour nous dire : j'ai cette idée, c'est une opportunité d'application ! Et nous sommes malheureusement obligés de répondre : on se calme ! »

Ce que le responsable en conclut néanmoins, c'est que le déploiement d'Appian a ouvert l'appétit des utilisateurs. Et cela nécessite un modèle fédéré avec des relais chez ces derniers ainsi que davantage de ressources pour son équipe. « Mais je ne veux pas non plus trop de francs-tireurs [dans les métiers] qui développeront des outils voués à aboutir 6 mois plus tard sur mon bureau, parce que plus personne ne saura les maintenir », précise-t-il.