« Datalab Lift face à la concurrence : comment un extracteur à 9 milliards de paramètres, guidé par schéma, se compare à NuExtract3, LlamaExtract, Marker et Docling »

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.

Chroma lance Context-1 : un modèle de recherche à base d'agents de 20 milliards de paramètres pour la récupération multi-saut et la gestion du contexte

Chroma, l'entreprise derrière la base de données vectorielle open source du même nom, a lancé Context-1, un modèle de recherche agentique de 20 milliards de paramètres conçu pour résoudre l'un des problèmes les plus tenaces des systèmes RAG (Retrieval-Augmented Generation) modernes. Dérivé de l'architecture Mixture of Experts gpt-oss-20B et affiné par apprentissage supervisé combiné à du renforcement via CISPO, ce modèle ne joue pas le rôle d'un moteur de raisonnement généraliste : il agit comme un sous-agent de recherche ultra-spécialisé. Concrètement, face à une question complexe nécessitant plusieurs étapes de raisonnement, Context-1 décompose la requête en sous-questions ciblées, exécute des appels d'outils en parallèle — 2,56 appels en moyenne par tour — et parcourt itérativement un corpus documentaire via des outils comme searchcorpus (hybride BM25 + recherche dense), grepcorpus et readdocument, avant de transmettre les passages pertinents à un modèle frontier pour la réponse finale. L'innovation la plus significative de Context-1 est ce que Chroma appelle le "Self-Editing Context" : le modèle ne se contente pas de chercher, il gère activement sa propre fenêtre de contexte. Au fil de la recherche, les documents s'accumulent — beaucoup s'avèrent redondants ou hors sujet. Plutôt que de se noyer dans ce bruit, Context-1 a été entraîné avec une précision de pruning de 0,94 : il exécute proactivement une commande prunechunks pour éliminer les passages inutiles en cours de recherche. Ce mécanisme lui permet de maintenir une fenêtre de contexte de 32 000 tokens propre et efficace, là où les modèles généralistes "s'étranglent" sur des chaînes de raisonnement longues. Le découplage entre la logique de recherche — traditionnellement gérée par le développeur — et la génération de réponse représente un changement architectural majeur pour les équipes qui construisent des pipelines RAG en production. Pour entraîner et évaluer ce type de modèle, Chroma a également publié en open source son outil de génération de données synthétiques, context-1-data-gen. Ce pipeline produit des tâches multi-hop dans quatre domaines — recherche web, dépôts SEC (10-K, 20-F), brevets USPTO et corpus d'emails (Enron, fichiers Epstein) — selon un processus structuré en quatre étapes : Explorer, Vérifier, Distraire, Indexer. L'astuce centrale est l'injection de "distracteurs thématiques", des documents apparemment pertinents mais logiquement inutiles, qui forcent le modèle à raisonner plutôt qu'à faire du simple matching de mots-clés. Ce faisant, Chroma s'attaque à un angle mort bien connu des benchmarks statiques, et positionne Context-1 comme compétitif face à GPT-5 sur les tâches de recherche complexes — tout en étant nettement moins coûteux à faire tourner pour des volumes industriels.

Kore.ai lance la plateforme d'agents IA Artemis et intensifie la concurrence face à Microsoft et Salesforce

Kore.ai a lancé mercredi la plateforme Artemis, une refonte complète de sa technologie centrale destinée aux entreprises qui souhaitent concevoir, déployer et optimiser des agents d'intelligence artificielle. Fondée par Raj Koneru, PDG et fondateur, la société mise sur un principe résumé ainsi : "vous faites de l'IA avec de l'IA, vous concevez avec l'IA, vous construisez avec l'IA, vous testez avec l'IA, vous déployez avec l'IA." Au coeur technique de la plateforme se trouve l'Agent Blueprint Language (ABL), un langage déclaratif compilé basé sur YAML qui standardise la façon dont les agents IA, les workflows et les systèmes multi-agents sont définis, validés et gouvernés. L'ABL embarque son propre analyseur syntaxique, compilateur et environnement d'exécution, et supporte six modèles d'orchestration natifs : superviseur, délégation, transfert, distribution parallèle, escalade et fédération agent-à-agent. La plateforme intègre également Arch, un système IA qui traduit des objectifs métier formulés en langage naturel en code ABL prêt pour la production, en sélectionnant automatiquement la topologie multi-agents adaptée, en générant les données de test et en assurant le déploiement puis le suivi en production. L'enjeu principal est de compresser ce qui prenait traditionnellement des mois de travail d'ingénierie en quelques jours. En s'appuyant sur des artefacts YAML stockables dans GitHub et intégrables aux pipelines CI/CD, Kore.ai permet aux développeurs, aux équipes métier et aux directions informatiques de travailler sur un standard commun, sans avoir à choisir entre une plateforme no-code rigide et un framework pro-code complexe. L'optimisation en boucle fermée constitue l'atout différenciant le plus concret : si un agent déployé atteint seulement 30% d'automatisation alors que l'objectif est de 50%, Arch analyse les écarts, régénère et redéploie automatiquement une version améliorée du code ABL en se basant sur les données d'usage réelles. Koneru illustre l'impact : "grâce à ce cycle d'optimisation, on fait monter l'aiguille à 50% en ajustant l'application sur la base du comportement effectif." La sortie d'Artemis s'inscrit dans une course effrénée entre les grands éditeurs de logiciels d'entreprise pour devenir l'infrastructure de référence des agents IA : Microsoft, Salesforce, Google et ServiceNow investissent massivement dans ce segment. Face à ces géants, la stratégie de Kore.ai repose sur la neutralité technologique et sur le comblement d'un vide identifié par Koneru entre la génération de code et son exécution réelle en production, avec la gestion des versions, la gouvernance et l'observabilité que cela requiert. L'ABL se positionne comme une couche intermédiaire universelle entre les instructions en langage naturel des utilisateurs et l'infrastructure de production, un pari sur la standardisation plutôt que sur l'intégration verticale propriétaire qui caractérise les offres concurrentes.

Mistral lance OCR 4, un outil d'extraction documentaire taillé pour l'IA en entreprise

Mistral AI a lancé mardi OCR 4, sa quatrième génération de technologie de reconnaissance optique de caractères en à peine quinze mois. Ce modèle de traitement documentaire dépasse la simple extraction de texte brut : il retourne une représentation structurée complète de chaque document, avec des boîtes de délimitation précises pour chaque bloc, une classification par type de contenu (titre, tableau, équation, signature) et des scores de confiance mot par mot. Le modèle supporte 170 langues, accepte les formats PDF, DOC, PPT et OpenDocument, et peut être déployé en conteneur autonome sur l'infrastructure interne d'une organisation. Il est disponible immédiatement via l'API Mistral, Document AI dans Mistral Studio, Amazon SageMaker et Microsoft Foundry, avec une intégration Snowflake annoncée prochainement. La tarification débute à 4 dollars pour 1 000 pages, ramenée à 2 dollars via l'API batch. Lors d'évaluations humaines indépendantes, les annotateurs ont préféré les sorties d'OCR 4 dans 72 % des cas face aux solutions concurrentes. Le changement central d'OCR 4 est architectural. Plutôt que de produire un flux plat de texte extrait, le modèle génère une carte sémantique du document : chaque bloc est localisé, typé et scoré. Cette traçabilité répond à une friction majeure des équipes qui construisent des pipelines RAG (retrieval-augmented generation) ou des workflows de conformité, où la question "d'où vient ce chiffre, sur quelle page ?" exige une réponse auditable. La classification des blocs permet en outre d'orienter automatiquement un tableau vers un pipeline de données structurées, un titre vers un découpage sémantique, ou une signature vers un workflow de caviardage. Packager ces sorties directement dans le modèle OCR supprime une couche d'analyse de mise en page que les équipes devaient jusqu'ici construire et maintenir séparément. Les scores de confiance permettent quant à eux de router programmatiquement les extractions incertaines vers des relecteurs humains, sans qu'une personne n'ait à vérifier chaque page de chaque document. Ce lancement intervient dans un contexte particulièrement porteur pour Mistral. La startup française, dont la proposition de souveraineté numérique européenne n'a jamais été aussi commercialement pertinente, cible explicitement les entreprises des secteurs réglementés, finance, santé, juridique, qui ne peuvent pas faire transiter leurs documents sensibles par des API cloud sous juridiction américaine. La capacité de déploiement on-premise en conteneur unique est le principal levier de différenciation face à des acteurs comme Google Document AI ou AWS Textract. Pour les développeurs, l'enjeu est aussi économique : dans les systèmes de production, l'OCR n'est que la première étape d'un pipeline plus large, et la reconstruction manuelle de la structure documentaire consomme souvent plus de temps d'ingénierie que la logique IA en aval. OCR 4 vise à éliminer cette étape, et si le modèle tient ses promesses, les gains se mesurent autant en heures d'ingénierie économisées qu'en coût d'extraction.