Je vais vous raconter l’histoire (pas si) banale d’IFACT.

IFACT est un jeune bot, issu de la technologie RPA, dynamique et organisé. Depuis 3 ans il parcourt les écrans de notre client, lance et exécute sans relâche, et sans pause-café, le processus de saisie de demandes de remboursement santé liée aux domaines de l’imagerie médicale et de la médecine douce.

Je vous remets dans le contexte : En tant que bénéficiaire d’une complémentaire santé, lorsque vous engagez de frais de santé auprès d’un professionnel, une prise en charge supplémentaire s’ajoute à celle de la Sécurité sociale. Pour obtenir le remboursement de la mutuelle, vous devez envoyer les documents justificatifs correspondants (ordonnance et/ou facture), soit par courrier, soit par courriel, soit en ligne depuis votre espace client. Une fois votre demande de remboursement reçue, votre mutuelle traite la requête, vérifie les informations et procède au paiement dans un délai moyen de 5 ou 6 jours.

Dans le cas spécifique de notre client, en un coup de souris et trois clics, l’assuré se connecte sur le portail de la mutuelle, MYPORTAIL, pour y joindre les documents justificatifs. Les informations envoyées sont ensuite recueillies dans une GED (solution de Gestion Electronique de Documents) pour traitement.

Afin de respecter le délai stipulé, derrière cette interface numérique, une armée d’agents s’active et traite les requêtes reçues par ordre d’arrivée. Ces actions, menées manuellement, se répètent au grand dam de l’agent tout au long de la journée, jour après jour… Vous voyez le tableau ? Cependant aussi fastidieuse, répétitive et chronophage qu’elle puisse paraître, cette tâche est nécessaire au bon fonctionnement du processus, au respect du contrat et à la satisfaction client.

IFACT, un bot pour soulager les agents

IFACT a été créé en 20 jours par l’équipe de développement de la Bot Factory d’Aldemia via la RPA (Robotic Process Automation). Aujourd’hui 4 instances de ce bot tournent quotidiennement pendant les heures de présence des agents (8 heures par jour) et traitent entre 8 000 et 10 000 activités par jour. C’est l’équivalent de 15 agents à temps plein (toujours sans la pause-café).

Le travail de ce bot permet de traiter les demandes lorsqu’il n’y a pas de complexité dans la saisie de données ni de vérification dans la base de données, et soulage les agents dans le traitement d’activités sans difficulté majeure.

Cette histoire aurait pu en finir ici. Or un évènement imprévu est arrivé au début de l’automne : Notre bot IFACT s’est arrêté de travailler.

Pour cause, les informations saisies sur MYPORTAIL ne « circulaient » pas correctement entre le portail et la GED. Le travail d’IFACT, comme toute autre intelligence artificielle capable d’automatiser (RPA), se base sur la préparation, la vérification, l’analyse et le traitement des données numériques structurées.

Que deviennent les demandes rejetées par le bot ?

Si ces données ne sont pas renseignées, ordonnées et stockées correctement dans la GED, le bot se retrouve face à un dilemme de « jugement humain » dont il n’a pas les capacités de résoudre ou de contourner.

Certains cas de rejet sont prévus (par exemple, la saisie d’un bénéficiaire qui n’existe pas dans le contrat ou une facture déjà remboursée à l’assuré). Dans ce contexte, les demandes non traitées par le bot repartent dans la corbeille de l’agent pour un traitement manuel.

Dans l’histoire qui nous occupe, les demandes affectées à IFACT et, à notre surprise, rejetées par le robot, se sont retrouvées dans la corbeille des agents sans affectation pendant 3 jours. Pour rappel, nous avions libéré nos agents de ces tâches sans valeur ajoutée pour qu’ils puissent en effectuer d’autres plus intéressantes ou prioritaires.

On parle d’environ 13 000 activités non effectuées ! Dans l’hypothèse d’un traitement des demandes de façon manuelle, une sous-unité spéciale d’une vingtaine d’agents aurait dû être mise à disposition pour récupérer et rattraper le travail non effectué, au détriment d’autres tâches. En termes de coût, cela représente environ 30 000 €.

Comme expliqué précédemment, lorsqu’un bot rencontre une étape inattendue dans son processus, il a pour consigne de re router les activités qui lui sont confiées dans la corbeille de l’agent. Il n’y a pas de rupture du service mais il faut compter un délai supplémentaire dans le traitement des demandes. La collecte et la saisie manuelle de ces 13 000 activités non effectuées viennent s’ajouter aux activités courantes prévues par les agents. Etant donné que la priorité est donnée au traitement des demandes du jour, celles qui ont déjà pris du retard et qui n’étaient pas prévu se retrouveront « en bas » de la corbeille.

Résultat : un retard dans le remboursement des factures, une surcharge de travail pour les agents, un coût supplémentaire pour la compagnie et un mécontentement assuré de la part des bénéficiaires qui comptent sur le respect des délais impartis.

Incident résolu en un temps record

Nos soupçons se sont avérés après une analyse exhaustive du parcours réalisé par IFACT. L’origine du problème, purement technique, a été identifiée rapidement : Un échec dans la communication entre l’application portail et la GED avait provoqué une erreur dans le déroulement des tâches du robot. Des échanges rapides et efficaces entre le métier et les développeurs, ont permis le réajustement du bot. Il a suffi d’une heure de travail à l’équipe de la Bot Factory pour mettre à jour et livrer une nouvelle version du bot. C’est ainsi qu’IFACT a reçu une nouvelle consigne : recueillir les informations manquantes via une nouvelle séquence de parcours métier. L’incident résolu, les 13 000 activités en retard ont été traitées en un temps record de 2 jours, au lieu des 7 jours estimés par les agents en chair et en os. De plus l’incident n’a pas eu d’impact majeur sur le délai de remboursement moyen prévu dans le contrat client.

UIPATH est la solution d’automatisation low code (RPA) choisie et utilisée par nos équipes. L’expérience nous prouve qu’il n’y a pas de difficulté technique insurmontable avec la RPA. En cinq ans de collaboration, notre client a employé 18 bots. Parmi eux, 15 bots sont toujours actifs pour répondre à deux objectifs prioritaires pour ce client :

• Contourner des problèmes techniques liés aux difficultés d’interaction entre les applications d’un SI (dans 30 à 40% des cas). C’est l’exemple décrit dans cet article. Ces bots à durée déterminée sont utilisés dans des architectures avec des systèmes vieillissants ou complexes, en attendant qu’une nouvelle version ou une nouvelle application remplace le système vétuste et améliore la communication entre les applications.
• Couvrir des périodes de pic d’activité sans modifier la charge de travail ni solliciter un nombre d’agents important pour renforcer un dispositif. Ces bots persistants sont réutilisés lorsqu’il existe une activité cyclique. C’est le cas du bot ATTESTORAPIDO qui est responsable du traitement et de l’envoi du renouvellement des attestations mutuelle à chaque fin d’année lors de l’existence d’un contrat en cours.

Et voilà une histoire qui finit bien.

Vous aussi, améliorez vos processus avec la RPA (Robotic Process Automation) et gagnez en qualité des services (moins d’erreurs et plus de disponibilité), en employabilité (des tâches à forte valeur ajoutée pour vos salariés), en sécurité et en conformité (paramétrage et respect des normes).