Voici un retour d’expérience RPA (Robotique Processs Automation) pour ceux que le sujet intéresse … Récemment, nous avons assisté un de nos clients dans la collecte et la préparation de données extraites d’un grand nombre de dossiers. Ces dossiers devaient être traités dans un temps très court. En effet, afin de recevoir un agrément auprès de cet Etablissement Public Administratif (EPA), les demandeurs devaient déposer en ligne un certain nombre de documents, et l’EPA devait rendre un avis sur cette demande avant une échéance légale. Devant la somme de dossiers à traiter (un peu plus de 900) et le temps imparti (environ 5 semaines), nous avons proposé de recourir à une combinaison de RPA, d’API, d’OCR… et d’Excel. Après un premier article de mon collègue Amr la semaine dernière, penchons-nous aujourd’hui plus spécifiquement sur la RPA.

RPA : retour d’expérience sur un traitement flash et en masse de dossiers administratifs

L’EPA devait décider avant échéance des suites à donner à chaque demande d’agrément (acceptation / refus / demande de complément d’information). Il était donc nécessaire que les collaborateurs chargés de l’analyse des dossiers disposent d’un certain nombre d’informations : identité de l’ensemble des demandeurs (pour chaque organisation déposant une demande), croisement des identités des demandeurs avec celles des entreprises prestataires de ces demandeurs, conformité minimale à des attentes de l’EPA pour certains des documents déposés.

Il fallait donc :

  1. extraire des données des documents déposés (en format pdf),
  2. collecter d’autres données sur un site web d’information légale, juridique et financière sur les entreprises,
  3. croiser certaines données issues de ces 2 sources,
  4. préparer l’ensemble de ces données pour les transformer en information, et ainsi aider notre client dans son activité de décision.

RPA, API, OCR… ou comment transformer automatiquement la donnée en information

Afin d’accélérer et d’optimiser nos traitements, nous avons eu recours à des technologies différentes selon le type de besoin :

  • de l’OCR pour « lire » les pdf ; en effet, la majorité des pdf déposés n’étaient pas « consultables », car scannées ;
  • de la RPA pour extraire les données des documents « lus » et les rassembler dans des tableurs ; mais également afin de vérifier l’exhaustivité et l’exploitabilité de pièces déposées (ce qui a permis de retenir 750 sur plus de 900 dossiers initiaux) ;
  • des API pour collecter les données sur le site d’information des entreprises grâce à des développements en Python ; en effet, cette solution permettait de ne pas apparaître comme une tentative de piratage auprès du site d’information, contrairement au recours à la RPA (qui venait beaucoup trop régulièrement et méthodiquement chercher des informations pour que ce soit le fait d’un être humain !) ;
  • de l’Excel pour centraliser les données collectées, vérifier leur adéquation aux besoins formalisés par le client, tester la présence/absence des expressions recherchées, et enfin de présenter les résultats d’une manière synthétique et immédiate.
RPA retour d'expérience - Enchaînement des technologies OCR, RPA, API

Enchaînement des technologies OCR, RPA, API

RPA or not RPA, telle est la question

Nous avons proposé à notre client de recourir à la RPA. Afin de vérifier si la RPA était adaptée au besoin, un certain nombre de critères ont été évalués, et nous ont semblé a priori remplis.

La tâche est-elle manuelle et répétitive ?

Oui, il s’agissait d’examiner systématiquement des dossiers (environ 900) comportant chacun trois types de document :

  • ouvrir tous les documents fournis (sous forme de pdf)
  • en extraire les informations pertinentes (nom de naissance, nom d’usage, prénom et fonction de l’équipe des demandeurs pour un certain type de document, des SIRET dans un autre, des expressions dans un 3ème)
  • proposer une analyse permettant de prendre des décisions quant aux suites à donner

Ces tâches étaient jusqu’alors effectuées par des assistants/assistantes, mais les échéances imposaient une accélération de l’analyse des dossiers. Donc les tâches pouvaient être réalisées manuellement, mais elles étaient TRÈS répétitives et chronophages.

La tâche est-elle basée sur des règles ?

Oui, tous les dossiers devaient être analysés, chaque dossier comportait les trois mêmes types de documents, chaque type de document répondait à un certain formalisme. Les tâches devaient donc être traitées systématiquement, toujours de manière identique.

La tâche possède-t-elle des données d’entrée structurées ?

Oui, en particulier les documents de type 1, desquels devaient être extraits les noms de naissance, noms d’usage, prénom et fonction. Ces documents de type 1 consistaient en des formulaires pdf dont le modèle était disponible en téléchargement sur le site de notre client. Les autres documents étaient de type spécifique tel que demandé sur le site de notre client, et donc contenaient les éléments recherchés. Donc, oui, les données étaient majoritairement structurées.

La tâche possède-t-elle des taux d’exception faibles ?

Oui, les demandeurs déposaient leurs documents sur le site du client, et le type de document déposé était clairement spécifié sur le site : chaque pièce déposée ne pouvait être que d’un des types demandés, type à choisir dans une liste déroulante.

En fait, la réalité était un peu différente…

Une partie des document n’était pas immédiatement exploitable par RPA

Dans les faits, ces critères n’étaient pas tout à fait respectés ! En effet, l’adéquation à la demande des documents déposés dépendait fortement des déposants. Nous avons ainsi traité :

  • des documents dont le type réel ne correspondaient pas au type déclaré (document déclaré de type 1, mais de fait de type 99) ;
  • des documents scannés à l’envers ou de travers : difficile pour l’OCR de reconnaître des caractères dans ces conditions ;
  • des documents du bon type mais ne correspondant pas au modèle sur lequel s’appuie le développement du robot. En effet, afin d’extraire des données, on s’appuie sur des expressions pivot censées se trouver obligatoirement dans le document (exemple : chaîne de caractère comprise entre « expression 1 « et « expression 2 ». Si ces expressions ne se trouvent pas dans le texte, le robot renvoie une erreur ;
  • des documents remplis à la main donc non typographiés, ce qui complique le travail de l’OCR car moins lisibles et déchiffrables ;
  • des documents remplis avec une certaine logique « floue » (nom d’usage rempli, mais pas nom de naissance ; nom de naissance indiqué « néant » ou « idem » ; date de naissance renseignée à la place du nom de naissance ; etc). Le robot ne pouvait pas savoir si la chaîne de caractère extraire correspondait à un « vrai » nom/prénom (il ne fait qu’extraire des caractères) et les formules Excel détectaient des faux négatifs.

Des adaptations de paramétrage ont permis d’augmenter la qualité des informations

Un premier traitement par la RPA a donné des résultats avec une confiance globale dans la reconnaissance des identités égale à 41 %. C’était assez peu, pas suffisant quoi qu’il en soit pour répondre aux attentes de notre client. Après analyse, une solution partielle rapide est apparue. Les tests Excel associés à l’indice de confiance des données extraites (l’outil d’OCR utilisé fournit un « niveau de confiance » exprimé en pourcentage : plus le niveau de confiance est élevé, plus la probabilité que le mot reconnu correspond au mot initial est grande) pouvaient être assouplis. Il a en particulier été décidé en accord avec le client que lorsque le nom d’usage était renseigné et pas le nom de naissance, ces noms étaient confondus. Un 2ème outil d’OCR a été utilisé pour renforcer les résultats obtenus initialement. Le taux de confiance est alors passé à 75 %.

RPA retour d'expérience - Graphique présentant les étapes d'un projet RPA

Amélioration de la qualité des données par itérations successives

Certaines données ont été vérifiées en partie humainement

Les 25 % de données restantes étaient réparties en données complètement « illisibles » (11 %) et données incertaines « à vérifier visuellement » (14 %). Ces données provenaient de documents mal scannés et/ou mal remplis et/ou non conformes. Il a donc été décidé d’effectuer une saisie humaine (pour les données « illisibles ») et une vérification humaine (pour les autres). Une société spécialisée dans la saisie en masse de données a été retenue afin de réaliser cette tâche, et un certain nombre de documents lui ont été transmis afin de réaliser cette saisie. La qualité des retours a été si peu satisfaisante que nous avons proposé de réaliser nous même ces opérations. Afin de réduire les coûts de cette opération, nous nous sommes faits assister par des robots.

Ainsi, le robot ouvrait automatiquement à la bonne page les documents à vérifier, et un nom/prénom était proposé par l’OCR. Une boîte de dialogue permettait une fois les éventuelles modifications faites dans les documents, d’enregistrer le document, de le fermer, de le transférer dans un répertoire « Vérifié » en un simple et unique clic. Ce mode hybride a permis de diviser par 5 environ le temps de traitement « humain », tout en assurant l’exhaustivité et la qualité des données recueillies.

RPA retour d'expérience - Exemple de texte difficilement lisible reconnu par RPA

OCR + RPA facilite le déchiffrage de caractères manuscrits ; ici, prénom difficilement lisible mais reconnu par l’OCR

Le taux final de confiance pour les identités a finalement été de… 97 %

La RPA complétée par une intervention humaine à la marge a ainsi permis de « lire » et de traiter 97 % des identités. Sur les 3 % restants, 1,5 % consistaient en des documents non exploitables, même par un être humain (documents vides ou de type erroné). Les derniers 0,5 % nécessitaient l’expertise et la connaissance des collaborateurs de l’EPA afin de confirmer les résultats proposés.

Il s’agissait là des documents d’un type particulier, un formulaire parfois rempli à la main, dans lesquels il s’agissait de chercher des chaînes de caractères de longueur variable (tous les noms/prénoms n’ont pas la même structure !). Dans le cas des documents de type 3, documents uniquement typographiés dans lesquels il fallait identifier la présence et l’éventuelle concomitance d’expressions données (toujours les mêmes), la confiance a été supérieure à 99 %, sans intervention humaine.

Les points d’attention à retenir dans ce retour d’expérience RPA

Travailler en mode Agile

Nous avons travaillé en mode « Agile » : nous avons adapté notre système d’automatisation au fur et à mesure de la découverte du contexte réel ; le client a ainsi pu affiner ses demandes jusqu’à un stade avancé du projet (jusqu’à la 4ème semaine sur 5 semaines de projet), en parallèle des développements. Cela a permis de préciser les attentes, et de tester différentes demandes. Toutefois, le temps global de traitement de la masse de données n’a pu être optimisé. Même s’il ne fallait en définitive qu’environ 4,5 minutes de traitements par dossier, cela représentait tout de même plus de 56 h uniquement pour l’exécution des robots ! Moins de contrainte temporelle aurait permis de revenir sur les développements, de les améliorer, et donc de disposer de plus de temps pour tester d’autres demandes.

Générer consciemment de la dette technique

Le développement des robots a été rapide, en mode « quick and dirty« . Il est important de souligner que « dirty » ne reflète pas la qualité du résultat. Ce terme reflète le fait que pour aller vite, des raccourcis techniques sont pris qui génèrent de la dette technique. Dans le contexte, l’impact était limité, car les robots développés n’avaient pas pour but d’être réutilisés ou mis en production.

Traiter des sources de données hétérogènes

Par ailleurs, l’hétérogénéité des documents en entrée a eu un impact important. La variété des cas de figure a imposé le développement de conditions multiples. Ces conditions ont alourdi le développement, mais également le temps d’exécution, et ce de manière non linéaire assez rapidement. Nous avons donc préconisé au client d’imposer à l’avenir à ses demandeurs des formats plus structurants et plus homogènes, afin de faciliter le traitement des données.

Temps de développement et d'exécution en fonction du nombre de conditions dans un robot RPA

On observe empiriquement que 1) les temps de build et de run ne sont pas linéairement proportionnels au nombre de conditions et 2) le temps de run est encore plus fortement allongé que le temps de build quand le nombre de conditions augmente

La mission s’est achevée ainsi dans les temps, avec des informations de qualité mises à disposition de notre client pour étayer ses décisions d’agrément. La RPA a ainsi confirmé son rôle de digital assistant plutôt que de digital worker. Si vous voulez en savoir plus, n’hésitez pas à nous contacter sur notre page dédiée !