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 trai­te­ment des don­nées mas­sives et hété­ro­gènes, comme on en trouve dans les orga­ni­sa­tions de sou­tien aux entre­prises. Encore faut-il avoir une idée pré­cise de ce qu’on cherche à faire et orga­ni­ser métho­di­que­ment la conduite du projet.

Quel que soit le sec­teur d’activité, les entre­prises traitent un grand nombre de docu­ments en back office (ser­vice d’appui) : les fac­tures, les com­mandes, les CV, les régle­men­ta­tions par exemple, mais éga­le­ment briefs clients, appels d’offres, etc. Non seule­ment la volu­mé­trie de ces docu­ments est crois­sante (et ali­gnée avec la crois­sance expo­nen­tielle des don­nées échan­gées, en 2025 il est atten­du un volume de 181 zet­ta­bytes), mais leur forme est tou­jours plus hété­ro­gène et le temps pour les trai­ter est tou­jours plus réduit. Com­ment extraire de la valeur de ces docu­ments pour en tirer un fond homo­gène, ana­ly­sable, exploi­table et dis­po­nible, avec un accès uni­fié, simple et intuitif ?

Des questions préalables

À l’échelle d’un pro­jet d’automatisation du trai­te­ment des docu­ments, il se pose plu­sieurs types de ques­tions préa­lables : quelles inter­faces pour récu­pé­rer, conso­li­der, éti­que­ter la don­née, quelles inter­faces et quels usages à des­ti­na­tion à la fois des équipes back office, des déci­deurs et de tout autre uti­li­sa­teur final qui pour­rait tirer de la valeur de ces don­nées ? Quels choix tech­niques pour trai­ter les docu­ments, les sto­cker, les trier ? L’objectif de cet article n’est bien sûr pas de répondre à 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érou­le­ment de pro­jet et d’identifier les acteurs et les déci­sions à prendre.

Pre­nons un exemple simple et concret : une entre­prise cherche à répondre à des appels d’offres. Com­ment fait-elle pour récu­pé­rer la liste des appels d’offres ouverts, reti­rer les dos­siers de consul­ta­tion, lire les dos­siers, pré­pa­rer une vue conso­li­dée pour déci­der de la réponse ou non à ces appels d’offres, pré­pa­rer les docu­ments admi­nis­tra­tifs com­muns, pré­pa­rer les élé­ments de réponse, dis­po­ser d’une base com­mer­ciale (et ali­men­ter le CRM – cus­to­mer rela­tion­ship mana­ge­ment – de l’entreprise) et pro­po­ser 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 pro­ces­sus par la suite ?

Deux étapes de traitement

La pre­mière par­tie consiste bien à conso­li­der 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écu­pé­rer les dos­siers de consul­ta­tion et ana­ly­ser les dos­siers selon des cri­tères propres à l’entreprise. Il faut éga­le­ment les sto­cker et les orga­ni­ser, les éti­que­ter, les indexer, leur attri­buer des règles (sécu­ri­té, confi­den­tia­li­té). On peut éga­le­ment avoir besoin de faire inter­ve­nir des algo­rithmes de machine lear­ning (appren­tis­sage auto­ma­tique), de l’OCR (recon­nais­sance optique de carac­tères) ou de la RPA (auto­ma­ti­sa­tion robo­ti­sée des pro­ces­sus) pour trai­ter les docu­ments, en extraire le conte­nu et le structurer.

Une fois la don­née acces­sible et conso­li­dée, il faut pou­voir l’exploiter. La struc­tu­rer est une étape indis­pen­sable afin que l’entreprise puisse prendre ou non la déci­sion de répondre à l’appel d’offres, en fonc­tion de cri­tères qui lui sont propres, ana­ly­ser les cahiers des charges pour pré­pa­rer la meilleure réponse, four­nir toutes les réponses sous le for­mat atten­du par l’entité adju­di­ca­trice. On peut éga­le­ment uti­li­ser cette don­née pour ali­men­ter le CRM de l’entreprise, la rendre acces­sible à toutes les direc­tions de l’entreprise (par exemple, pour iden­ti­fier de nou­veaux axes stra­té­giques de déve­lop­pe­ment). Cette deuxième par­tie d’exploitation consiste à créer les inter­faces et les flux pour tirer de la valeur de la don­née que nous avons ingérée.

Nous allons uti­li­ser cet exemple tout au long de l’article pour décrire les construc­tions des deux inter­faces, col­lecte et conso­li­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 lan­cer dans un pro­jet data de trai­te­ment de docu­ments est celle, comme pour tout autre pro­jet, notam­ment IT, de son uti­li­té et de sa mise en œuvre : la volu­mé­trie est-elle suf­fi­sante pour jus­ti­fier de s’engager dans un pro­jet data ? Existe-t-il des solu­tions sur le mar­ché qui per­mettent de cou­vrir tout ou par­tie du pro­jet (la ques­tion du make or buy, faire ou ache­ter) ? Est-il pos­sible d’externaliser une par­tie de la prestation ?

Dans notre exemple, nous pou­vons déjà consi­dé­rer les appels d’offres publics qui consti­tuent une volu­mé­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 pas­sés par les entre­prises pri­vées, en fonc­tion de la seg­men­ta­tion géo­gra­phique, le mul­ti­pli­ca­teur est énorme. La volu­mé­trie, la varia­bi­li­té des docu­ments et les contraintes tem­po­relles (vitesse), ces trois fac­teurs (les 3 V tradi­tion­nels du big data) nous placent dans le bon contexte d’un pro­jet data.

Les questions initiales une fois le projet lancé

Une fois que nous avons déci­dé de trai­ter ce pro­jet et que nous avons conve­nu du péri­mètre que nous allons nous-mêmes trai­ter (par exemple, il paraît utile d’utiliser des solu­tions d’agrégation sur le mar­ché plu­tôt que d’en écrire une), il convient de s’intéresser aux condi­tions maté­rielles pour héber­ger la don­née : où va-t-elle être sto­ckée ? Y a‑t-il des contraintes liées à l’organisation de l’entreprise pour le sto­ckage des don­nées (cloud, on-pre­mise), doit-on la sto­cker ou pou­vons-nous tra­vailler en col­lec­tant et trai­tant direc­te­ment la don­née, est-il pos­sible de la trai­ter via un sys­tème de base de don­nées stan­dard ou la volu­mé­trie et la varié­té sont telles que nous allons nous diri­ger vers des bases NoS­QL et du big data ? Va-t-on la croi­ser avec d’autres don­nées (ce qui jus­ti­fie­rait de la pla­cer dans un data lake par exemple) ? Sommes-nous sou­mis à des règles de confi­den­tia­li­té, d’anonymisation, de tra­ça­bi­li­té (RGPD) ; s’agit-il de don­nées per­son­nelles, a for­tio­ri sen­sibles, est-il néces­saire de pré­voir un pro­ces­sus de purge ?

Toutes ces ques­tions sont à prendre en amont et sol­li­citent plu­sieurs ser­vices de l’entreprise : la DSI et son urba­nisme pour pro­po­ser une solu­tion de sto­ckage, le RSSI char­gé de la sécu­ri­té 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­gne­ment de l’équipe pro­jet et de l’ensemble des équipes IT char­gées de la réa­li­sa­tion et de l’exploitation.

Lire aus­si : Défi­nir le cadre nor­ma­tif d’une IA de confiance dans les entreprises

Les canaux d’alimentation

Ensuite, il faut défi­nir les moda­li­tés de col­lecte de la don­née, pré­pa­rer les ouver­tures de flux, éven­tuel­le­ment extraire la don­née et la trans­for­mer pour l’étiqueter, l’organiser, la struc­tu­rer et la cata­lo­guer, le tout en res­pec­tant la poli­tique de sécu­ri­té de l’entreprise et les contraintes citées ci-des­sus, y atta­cher 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 couvrent pas exac­te­ment le même péri­mè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 trai­te­ment de la don­née qui est du res­sort des équipes data et qui dans notre exemple peut inté­grer des algo­rithmes de machine lear­ning, de l’OCR ou de la RPA pour récu­pé­rer et struc­tu­rer la don­née de manière homo­gène et per­mettre 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­po­sons d’une don­née fraîche, struc­tu­rée, sécu­ri­sée et orga­ni­sée dans l’infrastructure que l’on sou­haite, on peut alors l’exposer pour la rendre dis­po­nible aux uti­li­sa­teurs, aux déci­deurs et à des appli­ca­tions tierces. Une par­tie impor­tante du pro­jet va être de défi­nir quel usage va être fait de cette don­née. La pre­mière pra­tique va être de four­nir une inter­face de search (recherche) pour celle-ci, afin de per­mettre aux consom­ma­teurs de cette don­née de trou­ver les élé­ments qui les intéressent.

Ensuite, on peut four­nir des inter­faces de data visua­li­za­tion qui vont expo­ser des indi­ca­teurs simples, ou même se bran­cher sur de l’IA qui aura pro­po­sé des recom­man­da­tions, par exemple. Puis ali­men­ter des appli­ca­tions tierces. Pour reprendre notre exemple des appels d’offres, on peut ima­gi­ner une inter­face qui per­mette de cher­cher dans un data­set (jeu de don­nées) des appels d’offres exis­tants en fonc­tion de cri­tères défi­nis par l’utilisateur. Des solu­tions de data­viz (visua­li­sa­tion de don­nées) sur le mar­ché per­mettent de répondre aux besoins d’interfaces, modu­lo le tra­vail réa­li­sé par des data ana­lysts pour pré­pa­rer cette visualisation.

La réponse aux besoins des utilisateurs

Ensuite, on peut – en fonc­tion des appels d’offres choi­sis par le déci­deur pour rece­voir une réponse – ima­gi­ner une inter­face qui per­mette de recom­man­der au déci­deur par la suite les appels d’offres aux­quels il est oppor­tun de répondre. Pour que cette recom­man­da­tion soit de qua­li­té, il faut implé­men­ter des boucles de feed­back régu­liè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 Science et les équipes infor­ma­tiques. Enfin, on peut appor­ter des couches sup­plé­men­taires d’outillage, une fois la don­née expo­sée : l’envoyer vers d’autres pla­te­formes pour com­mu­ni­quer avec des per­sonnes exté­rieures, ali­men­ter un CRM avec les don­nées des appels d’offres, déve­lop­per une IA qui per­met­trait d’automatiser les réponses aux appels d’offres, mettre en place une base documentaire.

L’équipe pro­jet va por­ter une bonne com­pré­hen­sion des besoins des uti­li­sa­teurs, afin de four­nir la bonne solu­tion pour ceux-ci. Un point fon­da­men­tal pour la bonne conduite du pro­jet et per­mettre une vraie adhé­sion des uti­li­sa­teurs est de s’assurer que l’usage atten­du est réa­liste (qu’il colle à une réa­li­té opé­ra­tion­nelle), que les par­ties pre­nantes sont ali­gnées sur les cri­tères de suc­cès du pro­jet (par exemple, être ali­gnés sur le pour­cen­tage de docu­ments traités).

Une mise en application réussie à La Poste

L’exemple choi­si pour illus­trer le fonc­tion­ne­ment de bout en bout d’un pro­jet big data et IA de trai­te­ment de docu­ments en back office est volon­tai­re­ment simple et indé­pen­dant du contexte de l’entreprise, mais il a le mérite de décrire le fonc­tion­ne­ment tech­nique du pro­jet. À cela, il faut ajou­ter dans le contexte notam­ment d’une grande entre­prise les com­plexi­tés sup­plé­men­taires liées au silo­tage des busi­ness units (domaines d’activités stra­té­giques), des dif­fé­rents dépar­te­ments SI (sys­tèmes d’information) et data par­ties pre­nantes dans l’entreprise, et les matu­ri­tés hété­ro­gè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 choi­si d’investir mas­si­ve­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.

Paral­lè­le­ment, afin de favo­ri­ser l’appropriation des sujets data par les uti­li­sa­teurs finaux, La Poste a mis en place des équipes opé­ra­tion­nelles (IT et Data) ain­si que des équipes de conduite du chan­ge­ment et de valo­ri­sa­tion des don­nées. C’est cette struc­ture solide qui a per­mis à l’entreprise de por­ter des usages nova­teurs et à fort retour sur inves­tis­se­ment dans le trai­te­ment des docu­ments en back office ; un pre­mier usage en pro­duc­tion per­met déjà de trai­ter les fac­tures entrantes de manière auto­ma­ti­sée et de sou­la­ger les équipes comp­tables de tâches de saisie.

La demande pour des usages du data lake a consi­dé­ra­ble­ment aug­men­té : nous comp­tons 200 usages en cours de réa­li­sa­tion pour les années 2022 et 2023. Indé­pen­dam­ment des ROI de ces usages, les nom­breuses demandes expri­mé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­patt / Adobe Stock

---

Articles similaires :

La voi­ture auto­nome : pro­grès tech­niques et perspectives Défi­nir le cadre nor­ma­tif d’une IA de confiance dans les entreprises Accul­tu­rer l’entreprise à l’intelligence arti­fi­cielle : l’efficacité du jeu sérieux His­toire de l’IA : phi­lo­so­phie, épis­té­mo­lo­gie, science et fantasmes Appa­rie­ment des don­nées : le poten­tiel de l’IA dans le par­cours de soins