Automatisation documentaire chez LCL : l’IA classique tient mieux la route que l’IA générative

L'IA générative montre ses limites dans le traitement documentaire chez LCL

Les cas d’usage de l’IA classique sont infinis, comme le démontre LCL. La banque a ainsi automatisé le traitement des documents liés aux successions, depuis l’acte de décès jusqu’au paiement de la facture des pompes funèbres. Un domaine où l’IA générative Gemini de Google – partenaire de la banque – testée par LCL doit encore faire ses preuves.

Axel Cypel, responsable des projets d’IA chez LCL, le reconnaît : l’ambition des métiers de la banque vis-à-vis des capacités d’automatisation est très élevée. De fait, l’IA a permis des avancées significatives en matière de reconnaissance des documents et d’extraction intelligente d’informations, si bien que l’automatisation de processus bancaires entiers devient possible, jusqu’à la mise en place du paiement automatique.

En l’occurrence, c’est le service de back office en charge des successions chez LCL qui s’est tourné vers Axel Cypel afin de mettre en œuvre l’IA dans ses processus internes. La banque traite de l’ordre de 60 000 dossiers de décès chaque année. « Lors d’un décès, le back office succession collecte de nombreux documents dans un contexte difficile pour les familles » explique le responsable.

Axel Cypel, responsable des projets d’IA chez LCL

Des contraintes réglementaires importantes à respecter


« La banque doit respecter des contraintes réglementaires et fiscales importantes et des deadlines » ajoute-t-il. Il devient important de tout faire « pour améliorer la satisfaction des clients, la rapidité des traitements ainsi que la charge des collaborateurs. » Dans 80 % des cas, les documents parviennent à la banque via l’agence bancaire auprès de laquelle les héritiers se présentent.

« Il y a autant de formats différents [pour les actes de décès] qu’il y a de mairies en France »

Les héritiers doivent remettre l’acte de décès, un document édité par les mairies. Or,  « il y a autant de formats différents [pour les actes de décès] qu’il y a de mairies en France » relève Axel Cypel. « Le conseiller met alors le compte à jour et relève la date de décès sur ce document officiel. Or, dans 15 % des cas, la date saisie est erronée. »

Généralement, la date de décès est écrite en toutes lettres, mais le document est aussi tamponné et daté, ce qui peut entrainer une confusion, notamment lorsque le défunt avait une assurance vie. « Quand la date de décès est saisie dans la base de données, cela déclenche un flux vers l’assureur du groupe, Predica. En retour, des données relatives au contrat sont ramenées dans le dossier. S’il y a une erreur de date dans le backoffice, il faut détoper l’acte, puis retoper, ce qui occasionne beaucoup de travail inutile. » De plus, une contrainte réglementaire est liée à cette date clé : la loi Eckert impose à la banque un délai de 15 jours pour écrire aux bénéficiaires, faute de quoi, elle peut être amenée à payer des pénalités.

Une application RAD/LAD dopée à l’IA

Un projet a été lancé pour mettre en place une application RAD-LAD (RAD pour Reconnaissance Automatique de Document et Lecture Automatique de Document), sur ces actes de décès, avec une reconnaissance et une lecture automatique du document. La lecture de la date de décès devait permettre dans un premier temps un simple contrôle de la saisie en agence et de déclencher une alerte en cas d’écart constaté.

« Le processus du backoffice doit tenir compte des cas où l’IA rate une lettre ou un chiffre »

L’une des difficultés du projet portait sur le taux de reconnaissance sur la dizaine de champs à extraire. « Tous les champs n’ont pas la même importance, mais il serait malvenu de se tromper trop souvent. L’IA fait des erreurs et le processus du backoffice doit tenir compte des cas où l’IA rate une lettre dans un prénom, ou un chiffre dans une date » recommande le responsable.

Autre contrainte forte, le système « front to back » est un système d’information fonctionnant en temps réel et il traite les données au fil de l’eau. Comme il serait trop coûteux de modifier l’application pour la faire fonctionner en batch, l’équipe IA a dû concevoir un process RAD/LAD fonctionnant aussi en temps réel.

Usage de la librairie de vision par ordinateur Donut

Pour la création des modèles, les Data Scientists de LCL ont eu recours à la librairie de Computer Vision Donut, capable de réaliser à la fois la classification des documents et l’extraction des champs par apprentissage machine (Machine Learning). « Nous avons réalisé l’extraction des données de nos systèmes de backoffice, mené l’apprentissage sur des machines dotées de GPU [Processeurs graphiques utilisés pour l’IA], puis les modèles ont été portés sur la solution Vertex AI de Google Cloud » décrit-il.  LCL travaille étroitement avec Google dans sa transformation vers l’IA.

« Un pipeline a été mis en place pour mettre à disposition une API [interface informatique] appelable par les systèmes du back-office. » Les taux de reconnaissance par l’IA révélés par Axel Cypel varient en fonction des champs de données. Ils sont supérieurs à 97 % pour la date de décès, de plus de 98 % pour la situation maritale. Le nom du défunt est reconnu avec succès dans 93 % des cas, le prénom à 92,24 % et le lieu de naissance à 85,49 %.

L’IA confrontée au règlement automatique de factures…

« Comme cela fonctionnait parfaitement, le backoffice Succession a eu l’idée d’élargir ses attentes à d’autres documents comme les factures de pompes funèbres et les actes de dévolution successorale » enchaine le responsable.

« Les entreprises de pompes funèbres ont un statut de créancier privilégié. Ils doivent être réglés sans l’accord des héritiers »

Le traitement des factures des pompes funèbres qui sont envoyées directement à la banque est un autre cas d’usage traité par son équipe. « L’objectif est ici de gagner en réactivité. Toutefois, ces factures ont aussi un volet réglementaire, car les entreprises de pompes funèbres ont un statut de créancier privilégié. Ils doivent être réglés sans l’accord des héritiers à hauteur de ce qu’il y a sur le compte du défunt et les héritiers doivent régler le reliquat. »

Dans ce cas d’usage, le back office doit faire un règlement automatique sans erreur. Il doit reconnaître l’IBAN et il ne faut pas commettre d’erreurs sur la lecture du montant. Or, certaines factures présentent certaines bizarreries, avec un « Net à payer » à 0 alors que la facture doit être réglée. De même, l’IBAN est généralement dans la facture, mais parfois le backoffice le reçoit dans un RIB joint à la facture, donc dans un document séparé à traiter par l’algorithme.

Des taux de reconnaissance qui vont de 80% à 95%

Sur ce cas d’usage, les taux de reconnaissance LAD (Lecture Automatique de Document) sur ces factures sont de l’ordre de 93 % pour les IBAN dans la facture ou dans un RIB, de 95 % pour le nom du défunt, à 80 % pour le nom de l’entreprise de pompes funèbres.

« Le paiement automatique peut faire peur, mais il y a plusieurs garde-fous« 

« Le paiement automatique peut faire peur, mais il y a plusieurs garde-fous » veut rassurerAxel Cypel « Il y a un montant légal maximum exigé, et si le montant restant à payer atteint 58 000 €, on envoie une alerte au back office » dit-il.

« D’autre part, nous connaissons déjà les IBAN des principales entreprises de pompes funèbres. L’IT peut ainsi comparer les extractions automatiques avec cette base et croiser les données entre-elles pour fiabilisation » ajoute-t-il.

Un document notarial donne du fil à retordre

Une autre pièce officielle va donner plus de fil à retordre à l’équipe d’Axel Cypel, c’est l’acte de dévolution successorale. Il s’agit d’une pièce notariée qui nomme les héritiers et donc les personnes à qui doivent être faits les versements.

« Le back office souhaitait que notre RAD/LAD scanne ce document pour en extraire la liste des héritiers et leurs quotes-parts »

Les notaires envoient ce document qui compte parfois plusieurs dizaines de pages à l’adresse du service de back office qui le reroute en général vers un prestataire de numérisation. « La dévolution est certes une pièce normée, mais qui diffère d’une officine à une autre » reprend Axel Cypel. « Cette pièce n’indique pas seulement qui sont les héritiers, mais aussi quelle est leur quote-part dans la succession. Le back office souhaitait que notre RAD/LAD scanne ce document pour en extraire la liste des héritiers et leurs quotes-parts respectives » précise-t-il.

Cette tâche va s’avérer complexe à automatiser. « Le calcul de la quote-part est compliqué et implique un certain niveau de raisonnement » explique l’expert. « Le raisonnement pour une IA, c’est déjà compliqué, mais cela implique aussi des informations qui ne sont pas présentes dans la dévolution, dont le choix du conjoint survivant. »

Gemini de Google hallucine en lisant les dévolutions rédigées par les notaires

Face à ces documents verbeux, l’idée est lancée de tester l’IA générative et faire du RAG, un mode d’IA générative qui s’appuie sur les documents de l’entreprise afin de sourcer ses réponses. « Nous avons testé plusieurs LLM [grands modèles de langages], dont Gemini [IA générative de Google]. L’idée n’est plus d’entraîner un modèle, mais de rédiger des prompts pour une IA multimodale. »

« Gemini de Google peut donner le nom d’un héritier présent en page 6 dans un document qui n’en comporte que 5

L’idée va rapidement tourner court : Gemini de Google peut donner le nom d’un héritier présent en page 6 dans un document qui n’en comporte que 5. « Il nous faut revoir notre prompt ou repasser dans une approche plus classique » constate Axel Cypel.

Autre point clé à ne pas négliger, c’est le volet IT d’une telle automatisation. Le responsable souligne que si concevoir des modèles d’IA à haut niveau de performance représente la partie noble dans de tels projets d’automatisation, 80% de ces projets consiste en fait à intégrer les modèles d’IA dans l’informatique de production, notamment dans le cas du traitement des actes de décès qui fonctionne en temps réel.

Une conduite du changement assez simple

Si la partie conduite du changement fut assez simple, ces automatisations fournissant une aide précieuse aux métiers et ne changent en rien les traitements en place, c’était le volet industrialisation informatique qui était le plus critique dans ces projets.

Pour placer les données personnelles dans le Cloud de Google, les données sont chiffrées tant en transit qu’en stockage sur le Cloud

Un important travail préliminaire a été mené avec les CISO (Chief Information and Security Officer ou RSSI) et DPO (Data Protection Officer ou DPD) de LCL pour autoriser ce traitement de données à caractère personnel dans le Cloud public américain de Google. Outre la localisation des serveurs en Europe des garanties ont été prises quant à leur protection, notamment avec des clés de chiffrement stockées dans un coffre HSM dans le service Cloud Key Management Service (KMS) de Google. Les données sont chiffrées tant en transit qu’en stockage sur le Cloud Google.

 « Il faut intégrer le fait que l’IA peut commettre des erreurs et intégrer cette dimension dans les processus »retient Axel Cypel, responsable des Projets IA chez LCL.  « Nous avons mis en place cette notion de seuil de confiance sur les champs extraits, mais ce n’était pas simple à mettre en place. Nous avons décortiqué Donut [le modèle d’IA pour la reconnaissance de caractères] pour le forcer à restituer les probabilités par champs et non pas un taux de confiance global pour l’ensemble du document » conclut-il.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *