ETL non structuré : l'approche d'intégration requise par l'IA d'entreprise

La plupart des données d'entreprise sont non structurées. La plupart des pipelines ETL ne les prennent pas en compte. Voici comment combler cette lacune.

Lorsque la plupart des équipes abordent le sujet de l'ETL, elles pensent généralement à des données relationnelles : tables, schémas, clés étrangères. Un système source, une étape de transformation, une destination « propre ». Il s'agit d'un problème bien connu, pour lequel il existe des solutions bien établies.

Les données non structurées constituent un problème à part. Fichiers PDF, contrats, fils de discussion par e-mail, tickets d'assistance, transcriptions audio, images, pages HTML, journaux au format libre… Ce type de contenu représente une part importante des données dont disposent réellement la plupart des entreprises, et pourtant, les outils ETL classiques ne tentent même pas de les traiter.

Ce manque de visibilité devient un frein. Les cas d'utilisation de l'IA dans lesquels les entreprises investissent aujourd'hui nécessitent un accès aux sources de données non structurées sur lesquelles repose réellement leur activité. Par exemple, peut-être :

• Le processus de traitement des informations contractuelles doit permettre la lecture de fichiers PDF
• L'IA dédiée au service client doit traiter les tickets et les enregistrements d'appels 
• Le système de contrôle de la conformité doit analyser les documents relatifs aux politiques et signaler les écarts.

Si votre couche d'intégration ne peut pas traiter ces données d'entrée, la couche d'IA (qui en dépend) ne peut pas fonctionner correctement.

En quoi consiste réellement l'ETL non structuré ?

L'ETL structuré relève d'un problème de pipeline. L'ETL non structuré est tout autre chose : un problème de compréhension sous-tendu par un pipeline.

L'étape d'extraction, à elle seule, n'est pas anodine. Un fichier PDF peut être une image numérisée, un document natif ou une combinaison des deux. Un contrat peut comporter des tableaux, des annotations manuscrites et des pièces jointes. Un fil de discussion par e-mail peut faire référence à un document stocké dans un système distinct. Avant toute transformation, le contenu brut doit être analysé, soumis à une reconnaissance optique de caractères (OCR) si nécessaire, puis segmenté en unités significatives.

Vient ensuite l'inférence de structure. Quel est le sujet de ce document ? À quelles entités fait-il référence ? Quels sont les champs clés qui intéressent les systèmes en aval ? Pour les données structurées, c'est le schéma qui répond à ces questions. Pour les données non structurées, la couche d'extraction doit en déduire les réponses, généralement en combinant des règles, la reconnaissance d'entités nommées et, de plus en plus, de grands modèles linguistiques.

Enfin, les résultats doivent être acheminés vers une destination utile : un magasin de vecteurs pour la recherche sémantique, une base de données relationnelle pour le reporting, ou encore une application en aval qui attend un format de données spécifique. Les étapes de transformation et de chargement sont bien connues, mais l’utilité des résultats dépend entièrement de la qualité des données issues de la couche de compréhension.

Les difficultés rencontrées par les entreprises : les modes de défaillance

Définir une stratégie pour l'ETL non structuré n'est que la moitié du chemin. C'est lors de son déploiement à grande échelle en production que la plupart des entreprises rencontrent des difficultés. Voici les causes d'échec les plus courantes qui compromettent les pipelines de données pour l'IA.

L'étalement des solutions ponctuelles

Le mode de défaillance le plus courant est la prolifération des solutions ponctuelles. Une équipe développe un script Python pour extraire des données de fichiers PDF. Une autre équipe utilise un outil différent pour le traitement des e-mails. Une troisième équipe gère manuellement l’ingestion des documents. Aucun de ces processus ne partage de mécanismes de surveillance, de gestion des erreurs, de traçabilité ou de contrôle de gouvernance. Il en résulte un ensemble de pipelines fragiles et invisibles qui tombent en panne sans crier gare et sont impossibles à auditer. Lorsqu’un modèle d’IA en aval produit un résultat erroné, remonter la piste jusqu’à un problème de qualité des données dans un script d’extraction non documenté relève d’un projet à part entière.

Sous-estimation du volume

Le deuxième risque réside dans la sous-estimation du problème lié au volume. Les données non structurées n’arrivent pas par lots à des intervalles prévisibles. Elles s’accumulent en continu. Les demandes d’assistance affluent 24 heures sur 24. Les contrats sont conclus en fonction des délais de négociation, et non des calendriers de l’équipe d’intégration. Une architecture de traitement qui fonctionne correctement avec 1 000 documents par jour risque de ne pas tenir la route face à 100 000 documents.

Négliger les autorisations

Le troisième type d’échec consiste à négliger l’importance des autorisations et des listes de contrôle d’accès (ACL). Tous ces documents sont soumis à des autorisations là où ils se trouvent, que ce soit dans un système de stockage de fichiers ou joints à un autre objet (un billet, un e-mail ou un enregistrement dans un CRM). Ces autorisations doivent être respectées et transmises avec les informations extraites du document, afin d’éviter que l’ingestion ne devienne une source de fuites de données censées être restreintes ou susceptibles d’être soumises à une réglementation.

Le configurer et ne plus s'en soucier 

La dernière source d'échec consiste à considérer l'ETL non structuré comme une opération ponctuelle. Les formats de documents évoluent. Les systèmes de messagerie sont remplacés. De nouvelles sources de données apparaissent. Pour garantir une capacité durable, il faut des pipelines résistants à ces changements, pouvant être mis à jour, testés et gérés par versions. Les scripts d'extraction ponctuels ne suffiront pas à long terme. 

À quoi ressemble une approche prête pour la production ?

Le point de départ consiste à considérer l'extraction non structurée comme un type de pipeline à part entière, et non comme une exception à gérer en dehors de la plateforme d'intégration principale. Cela signifie que les mêmes fonctionnalités de création visuelle, de surveillance, d'alerte, de logique de nouvelle tentative et de suivi de la traçabilité qui s'appliquent aux pipelines structurés s'appliquent également ici.

SnapLogic répond à cette exigence grâce à une combinaison de « Snaps » de traitement natif des documents, de pipelines d’extraction connectés à des modèles de langage de grande envergure (LLM) et d’une infrastructure de métadonnées qui transmet les informations de provenance de la source à la destination. Un pipeline chargé de l’ingestion des contrats peut extraire les dates clés, les parties, les obligations et les clauses pénales, valider le résultat par rapport à un schéma, puis acheminer ce résultat vers le système en aval approprié, le tout au sein de la même couche d’orchestration utilisée pour la réplication des bases de données et l’intégration des API.

L'avantage concret réside dans la cohérence opérationnelle. L'équipe chargée de surveiller votre pipeline de synchronisation Salesforce utilise le même tableau de bord pour surveiller votre pipeline d'ingestion des contrats. Les anomalies apparaissent en un seul et même endroit. Les requêtes de traçabilité fonctionnent aussi bien sur des sources structurées que non structurées. Les équipes chargées de la conformité peuvent auditer les flux de données sans avoir besoin de savoir quels scripts personnalisés s'exécutent et où.

Le rôle des modèles de langage à grande échelle (LLM) dans la couche d'extraction

Les grands modèles linguistiques ont révolutionné les possibilités en matière d'extraction de données non structurées. Des tâches qui nécessitaient auparavant une ingénierie de règles très poussée, telles que l'extraction de clauses à partir de contrats au format non standard ou la classification de l'intention de messages d'assistance rédigés en langage naturel, peuvent désormais être traitées par un modèle correctement configuré, intégré au pipeline.

La clé réside dans le fait de traiter les appels aux LLM comme des composants d’un pipeline, en appliquant la même rigueur opérationnelle qu’à n’importe quelle autre étape. Cela implique de définir des schémas d’entrée, de valider les résultats, de gérer les échecs de manière fluide et d’utiliser la mise en cache lorsque cela est approprié pour maîtriser les coûts. Une étape d’extraction via un LLM qui s’exécute sans validation ni logique de nouvelle tentative constitue un risque. En revanche, une étape correctement instrumentée représente une capacité durable sur laquelle les processus métier clés peuvent s’appuyer.

La couche d'intégration IA de SnapLogic fait des appels aux modèles de langage de grande envergure (LLM) des éléments à part entière des pipelines. Les modèles des principaux fournisseurs se connectent via des « Snaps », avec des fonctionnalités configurables de réessai, d'analyse des résultats et de routage en aval. Les équipes peuvent ainsi créer des pipelines d'extraction qui font appel à un LLM pour l'analyse, puis acheminent les résultats structurés vers n'importe quelle destination, sans avoir à écrire de code d'orchestration personnalisé.

Intégration OEM et embarquée : une opportunité pour les éditeurs de logiciels indépendants (ISV) et plateforme

L'ETL non structuré est une fonctionnalité tout aussi utile pour les services informatiques d'entreprise que pour les éditeurs de logiciels, qui peuvent l'intégrer directement dans leurs propres produits. Prenons l'exemple des secteurs d'activité où les workflows impliquant un volume important de documents les workflows monnaie courante. Citons notamment les technologies juridiques, l'assurance, la santé, les services financiers, les plateformes d'approvisionnement et la gestion du cycle de vie des contrats. 

Sur chacun de ces marchés, les clients demandent aux fournisseurs non seulement de stocker des documents, mais aussi d'en tirer parti de manière intelligente : extraire les termes clés, signaler les anomalies, remplir automatiquement les champs et mettre en évidence les clauses pertinentes.

Les fournisseurs capables de répondre à cette question grâce à une fonctionnalité native, et non en renvoyant l'utilisateur vers un outil tiers, bénéficient d'un avantage concurrentiel significatif. Et le moyen le plus rapide d'acquérir cette capacité consiste à intégrer une couche d'intégration et d'extraction éprouvée, plutôt que d'en développer une à partir de zéro.

Le programme OEM de SnapLogic permet aux éditeurs de logiciels d’intégrer l’ensemble des fonctionnalités d’intégration et d’ETL, y compris le traitement des données non structurées, directement dans leurs propres plateformes. L’expérience est proposée en marque blanche et déployée au sein de l’infrastructure propre à l’éditeur. Les clients interagissent avec une fonctionnalité native, et non avec un outil d’intégration distinct. L’éditeur contrôle l’interface, tandis que SnapLogic apporte la complexité technique.

Pour les équipes produit qui réfléchissent à la manière d’intégrer des fonctionnalités d’intelligence documentaire à leur plateforme, le choix entre « développer soi-même » et « intégrer une solution tierce » se résume généralement à une question de coûts de maintenance à long terme. Développer une pile d’extraction sur mesure implique d’assumer la responsabilité de la couche OCR, de l’orchestration des modèles de langage de grande envergure (LLM), de l’écosystème de connecteurs, de l’infrastructure de surveillance et des contrôles de conformité. 

L'intégration de SnapLogic permet de proposer ces fonctionnalités dès le premier jour et de consacrer les ressources techniques à ce qui fait la différence du produit, plutôt qu'à son infrastructure technique.

De la théorie à la mise en œuvre : pour commencer

Pour la plupart des équipes, la première étape concrète consiste à identifier deux ou trois types de documents très courants qui nécessitent actuellement un traitement manuel ou qui font l'objet de scripts peu fiables et disparates. Les contrats, les factures et les tickets d'assistance constituent souvent des points de départ courants. La mise en place d'un pipeline d'extraction régulé et surveillé pour ces sources permet de créer un modèle réutilisable qui s'étend au cas d'utilisation suivant sans avoir à repartir de zéro.

Pour les équipes produit, la question est de savoir quelles fonctionnalités d'IA de votre feuille de route dépendent de l'accès à des documents ou à des données non structurées, et si vous souhaitez développer ou intégrer la capacité nécessaire pour les prendre en charge.

Quoi qu'il en soit, le principe de base reste le même. les workflows basés sur l'IA les workflows efficaces que dans la mesure où la couche d'accès aux données qui les sous-tend l'est également. Mettre en place cette couche de manière adéquate, en intégrant à la fois des sources structurées et non structurées, est le travail qui rend tout le reste possible.

Prêt à le découvrir en action ? Suivez une visite guidée autonome du produit ou réservez une démonstration pour rencontrer un expert en intégration SnapLogic et discuter de l'ETL non structuré adapté à votre environnement ou à votre produit.