Data et IA : clés du traitement automatique des données hétérogènes

L’intelligence arti­fi­cielle (IA) rend de nom­breux ser­vices pour le traite­ment des don­nées mas­sives et hétérogènes, comme on en trou­ve dans les organ­i­sa­tions de sou­tien aux entre­pris­es. Encore faut-il avoir une idée pré­cise de ce qu’on cherche à faire et organ­is­er méthodique­ment la con­duite du projet.

Quel que soit le secteur d’activité, les entre­pris­es trait­ent un grand nom­bre de doc­u­ments en back office (ser­vice d’appui) : les fac­tures, les com­man­des, les CV, les régle­men­ta­tions par exem­ple, mais égale­ment briefs clients, appels d’offres, etc. Non seule­ment la volumétrie de ces doc­u­ments est crois­sante (et alignée avec la crois­sance expo­nen­tielle des don­nées échangées, en 2025 il est atten­du un vol­ume de 181 zettabytes), mais leur forme est tou­jours plus hétérogène et le temps pour les traiter est tou­jours plus réduit. Com­ment extraire de la valeur de ces doc­u­ments pour en tir­er un fond homogène, analysable, exploitable et disponible, avec un accès unifié, sim­ple et intuitif ?

Des questions préalables

À l’échelle d’un pro­jet d’automatisation du traite­ment des doc­u­ments, il se pose plusieurs types de ques­tions préal­ables : quelles inter­faces pour récupér­er, con­solid­er, éti­queter la don­née, quelles inter­faces et quels usages à des­ti­na­tion à la fois des équipes back office, des décideurs et de tout autre util­isa­teur final qui pour­rait tir­er de la valeur de ces don­nées ? Quels choix tech­niques pour traiter les doc­u­ments, les stock­er, les tri­er ? L’objectif de cet arti­cle n’est bien sûr pas de répon­dre à toutes ces ques­tions qui sont dépen­dantes de l’usage et de la don­née, mais de don­ner des clés sur un déroule­ment de pro­jet et d’identifier les acteurs et les déci­sions à prendre.

Prenons un exem­ple sim­ple et con­cret : une entre­prise cherche à répon­dre à des appels d’offres. Com­ment fait-elle pour récupér­er la liste des appels d’offres ouverts, retir­er les dossiers de con­sul­ta­tion, lire les dossiers, pré­par­er une vue con­solidée pour décider de la réponse ou non à ces appels d’offres, pré­par­er les doc­u­ments admin­is­trat­ifs com­muns, pré­par­er les élé­ments de réponse, dis­pos­er d’une base com­mer­ciale (et ali­menter le CRM – cus­tomer rela­tion­ship man­age­ment – de l’entreprise) et pro­pos­er l’accès à cette don­née en mode self-ser­vice pour les dif­férentes direc­tions de l’entreprise, afin d’optimiser le proces­sus par la suite ?

Deux étapes de traitement

La pre­mière par­tie con­siste bien à con­solid­er les don­nées de dif­férentes sources : agréger et lis­ter les appels d’offres per­ti­nents à par­tir des dif­férentes sources, récupér­er les dossiers de con­sul­ta­tion et analyser les dossiers selon des critères pro­pres à l’entreprise. Il faut égale­ment les stock­er et les organ­is­er, les éti­queter, les index­er, leur attribuer des règles (sécu­rité, con­fi­den­tial­ité). On peut égale­ment avoir besoin de faire inter­venir des algo­rithmes de machine learn­ing (appren­tis­sage automa­tique), de l’OCR (recon­nais­sance optique de car­ac­tères) ou de la RPA (automa­ti­sa­tion robo­t­isée des proces­sus) pour traiter les doc­u­ments, en extraire le con­tenu et le structurer.

Une fois la don­née acces­si­ble et con­solidée, il faut pou­voir l’exploiter. La struc­tur­er est une étape indis­pens­able afin que l’entreprise puisse pren­dre ou non la déci­sion de répon­dre à l’appel d’offres, en fonc­tion de critères qui lui sont pro­pres, analyser les cahiers des charges pour pré­par­er la meilleure réponse, fournir toutes les répons­es sous le for­mat atten­du par l’entité adju­di­ca­trice. On peut égale­ment utilis­er cette don­née pour ali­menter le CRM de l’entreprise, la ren­dre acces­si­ble à toutes les direc­tions de l’entreprise (par exem­ple, pour iden­ti­fi­er de nou­veaux axes stratégiques de développe­ment). Cette deux­ième par­tie d’exploitation con­siste à créer les inter­faces et les flux pour tir­er de la valeur de la don­née que nous avons ingérée.

Nous allons utilis­er cet exem­ple tout au long de l’article pour décrire les con­struc­tions des deux inter­faces, col­lecte et con­sol­i­da­tion, et recherche et décision.

L’interface de collecte et de consolidation

La pre­mière ques­tion qui se pose avant de se lancer dans un pro­jet data de traite­ment de doc­u­ments est celle, comme pour tout autre pro­jet, notam­ment IT, de son util­ité et de sa mise en œuvre : la volumétrie est-elle suff­isante pour jus­ti­fi­er de s’engager dans un pro­jet data ? Existe-t-il des solu­tions sur le marché qui per­me­t­tent de cou­vrir tout ou par­tie du pro­jet (la ques­tion du make or buy, faire ou acheter) ? Est-il pos­si­ble d’externaliser une par­tie de la prestation ?

Dans notre exem­ple, nous pou­vons déjà con­sid­ér­er les appels d’offres publics qui con­stituent une volumétrie d’environ 900 par jour ouvré, soit pas loin de 250 000 appels d’offres publics par an. Si l’on ajoute à ceux-ci les appels d’offres passés par les entre­pris­es privées, en fonc­tion de la seg­men­ta­tion géo­graphique, le mul­ti­pli­ca­teur est énorme. La volumétrie, la vari­abil­ité des doc­u­ments et les con­traintes tem­porelles (vitesse), ces trois fac­teurs (les 3 V tradi­tion­nels du big data) nous pla­cent dans le bon con­texte d’un pro­jet data.

Les questions initiales une fois le projet lancé

Une fois que nous avons décidé de traiter ce pro­jet et que nous avons con­venu du périmètre que nous allons nous-mêmes traiter (par exem­ple, il paraît utile d’utiliser des solu­tions d’agrégation sur le marché plutôt que d’en écrire une), il con­vient de s’intéresser aux con­di­tions matérielles pour héberg­er la don­née : où va-t-elle être stock­ée ? Y a‑t-il des con­traintes liées à l’organisation de l’entreprise pour le stock­age des don­nées (cloud, on-premise), doit-on la stock­er ou pou­vons-nous tra­vailler en col­lec­tant et trai­tant directe­ment la don­née, est-il pos­si­ble de la traiter via un sys­tème de base de don­nées stan­dard ou la volumétrie et la var­iété sont telles que nous allons nous diriger vers des bases NoSQL et du big data ? Va-t-on la crois­er avec d’autres don­nées (ce qui jus­ti­fierait de la plac­er dans un data lake par exem­ple) ? Sommes-nous soumis à des règles de con­fi­den­tial­ité, d’anonymisation, de traça­bil­ité (RGPD) ; s’agit-il de don­nées per­son­nelles, a for­tiori sen­si­bles, est-il néces­saire de prévoir un proces­sus de purge ?

Toutes ces ques­tions sont à pren­dre en amont et sol­lici­tent plusieurs ser­vices de l’entreprise : la DSI et son urban­isme pour pro­pos­er une solu­tion de stock­age, le RSSI chargé de la sécu­rité de l’informatique, le DPO (délégué à la pro­tec­tion des don­nées) sont en pre­mière ligne à ce stade, en accom­pa­g­ne­ment de l’équipe pro­jet et de l’ensemble des équipes IT chargées de la réal­i­sa­tion et de l’exploitation.

Lire aus­si : Définir le cadre nor­matif d’une IA de con­fi­ance dans les entreprises

Les canaux d’alimentation

Ensuite, il faut définir les modal­ités de col­lecte de la don­née, pré­par­er les ouver­tures de flux, éventuelle­ment extraire la don­née et la trans­former pour l’étiqueter, l’organiser, la struc­tur­er et la cat­a­loguer, le tout en respec­tant la poli­tique de sécu­rité de l’entreprise et les con­traintes citées ci-dessus, y attach­er une super­vi­sion pour s’assurer de la com­plé­tude de la col­lecte et de la fraîcheur des don­nées. Deux sous-étapes impor­tantes, qui ne cou­vrent pas exacte­ment le même périmètre fonc­tion­nel : la mise en place et la super­vi­sion des canaux d’alimentation de la don­née (par des flux froids ou chauds) par les équipes infor­ma­tiques, ain­si que le traite­ment de la don­née qui est du ressort des équipes data et qui dans notre exem­ple peut inté­gr­er des algo­rithmes de machine learn­ing, de l’OCR ou de la RPA pour récupér­er et struc­tur­er la don­née de manière homogène et per­me­t­tre l’organisation de cette don­née par nature hétérogène.

L’interface de recherche et de décision

Une fois que nous dis­posons d’une don­née fraîche, struc­turée, sécurisée et organ­isée dans l’infrastructure que l’on souhaite, on peut alors l’exposer pour la ren­dre disponible aux util­isa­teurs, aux décideurs et à des appli­ca­tions tierces. Une par­tie impor­tante du pro­jet va être de définir quel usage va être fait de cette don­née. La pre­mière pra­tique va être de fournir une inter­face de search (recherche) pour celle-ci, afin de per­me­t­tre aux con­som­ma­teurs de cette don­née de trou­ver les élé­ments qui les intéressent.

Ensuite, on peut fournir des inter­faces de data visu­al­iza­tion qui vont expos­er des indi­ca­teurs sim­ples, ou même se branch­er sur de l’IA qui aura pro­posé des recom­man­da­tions, par exem­ple. Puis ali­menter des appli­ca­tions tierces. Pour repren­dre notre exem­ple des appels d’offres, on peut imag­in­er une inter­face qui per­me­tte de chercher dans un dataset (jeu de don­nées) des appels d’offres exis­tants en fonc­tion de critères défi­nis par l’utilisateur. Des solu­tions de dataviz (visu­al­i­sa­tion de don­nées) sur le marché per­me­t­tent de répon­dre aux besoins d’interfaces, mod­u­lo le tra­vail réal­isé par des data ana­lysts pour pré­par­er cette visualisation.

La réponse aux besoins des utilisateurs

Ensuite, on peut – en fonc­tion des appels d’offres choi­sis par le décideur pour recevoir une réponse – imag­in­er une inter­face qui per­me­tte de recom­man­der au décideur par la suite les appels d’offres aux­quels il est oppor­tun de répon­dre. Pour que cette recom­man­da­tion soit de qual­ité, il faut implé­menter des boucles de feed­back régulières afin d’entraîner le mod­èle de recom­man­da­tion. Il est néces­saire d’avoir une coor­di­na­tion solide entre les équipes de Data Sci­ence et les équipes infor­ma­tiques. Enfin, on peut apporter des couch­es sup­plé­men­taires d’outillage, une fois la don­née exposée : l’envoyer vers d’autres plate­formes pour com­mu­ni­quer avec des per­son­nes extérieures, ali­menter un CRM avec les don­nées des appels d’offres, dévelop­per une IA qui per­me­t­trait d’automatiser les répons­es aux appels d’offres, met­tre en place une base documentaire.

L’équipe pro­jet va porter une bonne com­préhen­sion des besoins des util­isa­teurs, afin de fournir la bonne solu­tion pour ceux-ci. Un point fon­da­men­tal pour la bonne con­duite du pro­jet et per­me­t­tre une vraie adhé­sion des util­isa­teurs est de s’assurer que l’usage atten­du est réal­iste (qu’il colle à une réal­ité opéra­tionnelle), que les par­ties prenantes sont alignées sur les critères de suc­cès du pro­jet (par exem­ple, être alignés sur le pour­cent­age de doc­u­ments traités).

Une mise en application réussie à La Poste

L’exemple choisi pour illus­tr­er le fonc­tion­nement de bout en bout d’un pro­jet big data et IA de traite­ment de doc­u­ments en back office est volon­taire­ment sim­ple et indépen­dant du con­texte de l’entreprise, mais il a le mérite de décrire le fonc­tion­nement tech­nique du pro­jet. À cela, il faut ajouter dans le con­texte notam­ment d’une grande entre­prise les com­plex­ités sup­plé­men­taires liées au silotage des busi­ness units (domaines d’activités stratégiques), des dif­férents départe­ments SI (sys­tèmes d’information) et data par­ties prenantes dans l’entreprise, et les matu­rités hétérogènes des dif­férentes équipes métiers.

“Les nombreuses demandes exprimées par les équipes métiers sont l’illustration de la réussite de la démarche.”

La Poste a choisi d’investir mas­sive­ment à la fois dans ses infra­struc­tures et dans l’accompagnement com­plet de ces pro­jets data & IA. Le groupe s’est ain­si doté d’un data lake (lac de don­nées) unique pour la mai­son mère, com­plété par deux infra­struc­tures big data – une pour la Banque et une pour la CNP.

Par­al­lèle­ment, afin de favoris­er l’appropriation des sujets data par les util­isa­teurs fin­aux, La Poste a mis en place des équipes opéra­tionnelles (IT et Data) ain­si que des équipes de con­duite du change­ment et de val­ori­sa­tion des don­nées. C’est cette struc­ture solide qui a per­mis à l’entreprise de porter des usages nova­teurs et à fort retour sur investisse­ment dans le traite­ment des doc­u­ments en back office ; un pre­mier usage en pro­duc­tion per­met déjà de traiter les fac­tures entrantes de manière automa­tisée et de soulager les équipes compt­a­bles de tâch­es de saisie.

La demande pour des usages du data lake a con­sid­érable­ment aug­men­té : nous comp­tons 200 usages en cours de réal­i­sa­tion pour les années 2022 et 2023. Indépen­dam­ment des ROI de ces usages, les nom­breuses deman­des exprimées par les équipes métiers sont pour moi l’illustration de la réus­site de la démarche et la preuve que celle-ci répond à une vraie attente de nos équipes.

Image de cou­ver­ture : © tip­pa­p­att / Adobe Stock

---

Articles similaires :

Intel­li­gences arti­fi­cielles : à quoi ressem­blera le futur ? Défense : quelle coopéra­tion humain-IA sur les bâti­ments de combat ? Définir le cadre nor­matif d’une IA de con­fi­ance dans les entreprises Accul­tur­er l’entreprise à l’intelligence arti­fi­cielle : l’efficacité du jeu sérieux His­toire de l’IA : philoso­phie, épisté­molo­gie, sci­ence et fantasmes L’IA à la Bib­lio­thèque nationale de France : la pat­ri­mo­ni­al­i­sa­tion 4.0