Traiter des PDF et en extraire des insights : concevoir un pipeline intelligent avec les services IA générative d'AWS

Construire un pipeline de traitement des dossiers de santé avec des agents IA sur Amazon Bedrock et AWS HealthLake

Amazon Web Services vient de dévoiler une architecture de traitement automatisé des dossiers de remboursement médicaux, combinant Amazon Bedrock Data Automation, Amazon Bedrock AgentCore et AWS HealthLake. Le pipeline cible le formulaire CMS-1500, le standard américain de facturation médicale en format papier ou PDF. Concrètement, lorsqu'un prestataire de santé dépose un formulaire dans un bucket Amazon S3, une fonction AWS Lambda déclenche une chaîne de traitement : Bedrock Data Automation extrait les données structurées via une combinaison de reconnaissance optique de caractères, de modèles de machine learning et d'IA générative, puis produit un JSON normalisé avec scores de confiance et coordonnées des champs détectés. Un agent IA basé sur le framework Strands Agents, hébergé sur AgentCore, prend ensuite le relais pour valider les données extraites contre les enregistrements patients et prestataires stockés dans HealthLake, et crée si validation réussie une ressource FHIR (Fast Healthcare Interoperable Resources) standardisée. Le résultat est transmis via Amazon SNS, avec un résumé technique pour les gestionnaires de dossiers et une version simplifiée pour le patient. Les dossiers rejetés partent dans une file morte (dead letter queue) pour traitement humain. L'enjeu est considérable : le traitement manuel des formulaires papier représente encore un poste de coût majeur dans le secteur de la santé aux États-Unis, avec des erreurs de saisie, des extractions imprécises et des délais de validation qui ralentissent les remboursements. Ce pipeline réduit l'intervention humaine aux seuls cas d'exception, tout en maintenant une traçabilité complète grâce aux scores de confiance générés par Bedrock Data Automation. Pour les assureurs et les établissements de santé, l'adoption du standard FHIR est également stratégique : il facilite l'interopérabilité entre systèmes et répond aux exigences réglementaires croissantes en matière d'échange de données de santé. Cette annonce s'inscrit dans une tendance de fond où les grands fournisseurs cloud cherchent à capturer les flux de traitement documentaire des secteurs très réglementés, santé en tête. AWS positionne ici AgentCore comme une couche d'orchestration agentique prête à l'emploi, capable de gérer des workflows multi-étapes avec appels d'outils (ici createfhirclaim et searchfhirresources) sans infrastructure LLM à maintenir. La concurrence avec Azure Health Data Services et Google Cloud Healthcare API est directe. La prochaine étape logique sera l'extension à d'autres formats de formulaires médicaux et l'intégration de contrôles de conformité réglementaire automatisés, notamment autour du HIPAA, la loi américaine de protection des données de santé.

Automatiser la génération de schémas pour le traitement intelligent de documents

Amazon Web Services vient d'enrichir son IDP Accelerator, solution open-source et serverless dédiée au traitement automatisé de documents, d'une nouvelle fonctionnalité baptisée "multi-document discovery". Jusqu'ici, exploiter le traitement intelligent de documents (IDP) exigeait de constituer manuellement un schéma de configuration pour chaque type de document à analyser : définir les classes, identifier des exemples représentatifs, spécifier les champs à extraire. Une contrainte rédhibitoire dès lors qu'une organisation se retrouve avec des milliers de documents non étiquetés et aucune visibilité sur les catégories qui les composent. La nouvelle fonctionnalité répond directement à ce problème : elle analyse une collection de documents inconnus, les regroupe automatiquement par type, puis génère les schémas de configuration prêts à l'emploi. Le pipeline repose sur AWS Step Functions pour l'orchestration, AWS Lambda pour le calcul serverless, Amazon S3 pour le stockage, et les modèles disponibles via Amazon Bedrock pour la génération des schémas, dont le modèle d'embeddings Cohere Embed v4 utilisé par défaut. L'intérêt opérationnel est considérable pour les équipes qui traitent des volumes documentaires hétérogènes. Là où le module Discovery existant nécessitait de connaître ses classes de documents à l'avance et de fournir un exemple par classe, la nouvelle approche supprime ce prérequis. Le système génère d'abord un embedding visuel pour chaque document, en se basant sur la première page uniquement pour les documents multi-pages, puis utilise le score de silhouette pour déterminer automatiquement le nombre de clusters pertinents. Un agent construit avec Strands Agents et un LLM Bedrock analyse ensuite chaque cluster pour identifier le type de document et produire un schéma. Une étape de "réflexion" finale compare l'ensemble des schémas générés pour détecter les chevauchements et incohérences avant validation humaine. Cette approche réduit drastiquement le travail préparatoire qui, à grande échelle, pouvait représenter des semaines de labelling manuel. Le choix des embeddings visuels plutôt que textuels, via OCR, est une décision technique délibérée : la mise en page, le formatage et la structure visuelle d'un document permettent de distinguer des types documentaires même lorsque leur contenu textuel se ressemble. Ce positionnement s'inscrit dans la stratégie plus large d'AWS de faire de Bedrock un socle central pour les workflows d'IA en entreprise, en y adossant des briques comme Strands Agents pour la partie agentique. La solution reste open-source, disponible sur GitHub, ce qui permet aux équipes de l'adapter à leurs propres collections. L'enjeu sous-jacent est de rendre accessibles les initiatives IDP à des organisations qui ne disposent pas des ressources pour classifier manuellement leur patrimoine documentaire avant même de commencer à en extraire de la valeur.

Comment créer des pipelines de génération de graphes de connaissances à partir de texte avec kg-gen, NetworkX et des visualisations interactives

Une équipe de chercheurs de l'Université Stanford a publié un tutoriel complet présentant kg-gen, une bibliothèque Python open source permettant de générer automatiquement des graphes de connaissances à partir de texte non structuré. Le workflow décrit s'appuie sur trois outils principaux : kg-gen pour l'extraction des entités et relations, NetworkX pour l'analyse des structures de graphes, et PyVis ainsi que Matplotlib pour la visualisation interactive. Le processus repose sur un modèle de langage configuré via LiteLLM, une couche d'abstraction qui permet de brancher indifféremment GPT-4o-mini d'OpenAI, Claude d'Anthropic, Gemini de Google ou des modèles locaux via Ollama. À partir d'un texte simple, « Linda est la mère de Josh, Ben est son frère, Andrew son père, Josh étudie à Stanford », kg-gen identifie automatiquement les entités (Linda, Josh, Ben, Stanford) et les relations sémantiques qui les lient sous forme de triplets sujet-prédicat-objet. Pour les passages plus longs, la bibliothèque intègre un mécanisme de découpage par chunks de 800 caractères et un algorithme de clustering qui regroupe les entités synonymes, évitant ainsi les doublons lorsqu'un même concept apparaît sous plusieurs formes dans le texte source. L'intérêt concret de cet outil réside dans sa capacité à transformer des corpus textuels volumineux et désordonnés en structures de données navigables et interrogeables. Pour les équipes data, les chercheurs ou les développeurs travaillant sur des bases documentaires, cela représente un gain significatif : là où il fallait annoter manuellement les relations entre concepts, kg-gen automatise l'extraction en quelques lignes de code. Le graphe résultant peut ensuite être analysé avec NetworkX pour identifier les nœuds les plus connectés, détecter des communautés thématiques, ou mesurer la centralité de certains acteurs dans un corpus. La visualisation interactive via PyVis permet de naviguer dans le graphe directement dans un notebook Jupyter ou un navigateur, ce qui ouvre des usages en veille technologique, en analyse de réseaux d'influence ou en construction de bases de connaissances pour des systèmes RAG. kg-gen a été développé à Stanford et s'appuie en interne sur DSPy, un framework de programmation déclarative pour les LLM, pour garantir des sorties structurées et reproductibles. LiteLLM, qui sert de couche de routage, supporte une quarantaine de fournisseurs de modèles, ce qui rend le pipeline indépendant d'un prestataire unique. Ce tutoriel s'inscrit dans une tendance plus large visant à combiner les grands modèles de langage avec des représentations symboliques du savoir, à mi-chemin entre les approches purement neuronales et les systèmes expert classiques. Plusieurs grandes entreprises tech explorent cette direction pour améliorer la fiabilité des réponses de leurs IA, notamment en réduisant les hallucinations en ancrant le raisonnement dans un graphe de faits vérifiables. La prochaine étape naturelle du projet consiste à fusionner des graphes issus de sources multiples, un problème d'alignement d'entités que kg-gen aborde également dans les sections avancées du tutoriel.

Conception d'un pipeline d'extraction de factures guidé par schéma avec lift-pdf, pour la validation et la génération de grand livre en comptabilité fournisseurs

Une équipe de développeurs a publié un tutoriel démontrant comment construire un pipeline complet d'extraction de factures fournisseurs à l'aide de la bibliothèque lift-pdf, associée à un schéma JSON structuré définissant les champs à extraire. Le système traite des factures PDF synthétiques générées pour l'occasion, avec des champs comme l'identité du vendeur, le tiers facturé, le numéro de bon de commande, les lignes de produits, la taxe, le montant total et le statut de paiement. La configuration par défaut fixe le traitement à trois documents (N_DOCS=3), avec des options pour forcer une précision complète du modèle ou une quantification en 4 bits, prévisualiser la première page du PDF généré, ou tester le pipeline sur un vrai document. L'installation repose sur des bibliothèques comme reportlab et pypdfium2 pour la génération et le rendu des PDF, pandas et matplotlib pour l'analyse, ainsi que lift-pdf avec son extension Hugging Face, bitsandbytes et accelerate pour l'inférence. Un détail technique notable: Pillow est volontairement figé à la version 11.3.0 pour contourner un problème de compatibilité connu entre cette bibliothèque, torchvision et Transformers sur Google Colab. Le script vérifie aussi la présence d'un GPU CUDA compatible, recommandant une carte A100 tout en acceptant des modèles L4 ou T4. L'intérêt de cette approche dépasse la simple reconnaissance de texte: au lieu d'un OCR brut, le modèle doit comprendre la structure et la logique métier d'une facture. Le tutoriel intègre volontairement des pièges réalistes rencontrés par les équipes comptables, comme la distinction entre l'adresse de facturation et l'adresse de livraison, la séparation entre le sous-total et le montant final après taxes, le renvoi d'une valeur nulle quand une information est absente, ou encore la classification correcte d'une facture partiellement payée comme non soldée tant qu'un solde reste dû. Cette rigueur rend l'extraction directement exploitable pour générer automatiquement des registres comptables fiables, un enjeu concret pour les équipes de comptabilité fournisseurs qui traitent des volumes importants de documents hétérogènes. Ce projet s'inscrit dans une tendance plus large de l'intelligence documentaire guidée par schéma, où les modèles de langage ne se contentent plus de lire du texte mais produisent des données structurées directement utilisables par des systèmes en aval. L'utilisation de la quantification en 4 bits via bitsandbytes permet de réduire les besoins en mémoire GPU, rendant ce type de pipeline accessible sur du matériel plus modeste comme les GPU L4 ou T4, et pas uniquement sur des cartes haut de gamme. Le choix de documents synthétiques comme base de test contrôlée, avec la possibilité d'étendre l'expérience à de vraies factures PDF, illustre une méthodologie de validation progressive avant déploiement en conditions réelles.

💬 Ce qui compte ici, ce n'est pas l'extraction de texte, c'est que le modèle doit piger qu'une facture partiellement payée reste une facture ouverte. Selon Le Fil IA, l'IA documentaire passe d'un problème d'OCR à un problème de logique métier, et c'est ça qui va décider si les équipes compta y touchent un jour. Après, le pipeline tourne sur un GPU L4 dans un tutoriel avec trois factures bidon, donc reste à voir si ça encaisse le bazar d'une vraie pile de PDF scannés de travers.