Automatisation du traitement des documents avec OpenClaw

Chaque entreprise fonctionne avec des documents. Factures, contrats, bons de commande, bons de livraison, rapports de conformité, notes de frais : le volume ne diminue jamais et le coût de leur traitement manuel est énorme. Des estimations prudentes estiment le coût moyen du traitement manuel des factures entre 12 et 16 dollars par document, avec des taux d'erreur compris entre 3 et 5 %. Multipliez cela par des milliers de documents par mois et les arguments en faveur de l’automatisation s’écrivent d’eux-mêmes.

Les agents de traitement de documents d'OpenClaw combinent l'OCR, l'extraction de données structurées, les règles de validation et l'intégration ERP dans un seul pipeline autonome. Le résultat est un système qui reçoit un document, comprend son type et son contenu, valide les données par rapport à vos règles métier et achemine les informations extraites vers la bonne destination, sans intervention humaine pour la majorité des documents.

Points clés à retenir

Les agents de documents OpenClaw gèrent les PDF, les images numérisées, les e-mails avec pièces jointes et les formats de fichiers structurés (CSV, XML, EDI) via un pipeline unifié.

Extraction IA des portes de notation de la qualité OCR : les analyses de faible qualité déclenchent une demande de nouvelle analyse avant la poursuite du traitement.

La couche d'extraction utilise une combinaison d'analyse de mise en page, de reconnaissance d'entités nommées et d'analyse basée sur LLM pour une précision maximale dans tous les formats de documents.

Les compétences de validation vérifient les données extraites par rapport aux enregistrements principaux des fournisseurs, aux numéros de commande, aux codes fiscaux et aux règles commerciales avant que les données n'atteignent votre ERP.

La gestion des exceptions achemine uniquement les documents véritablement ambigus vers les humains : l'agent fournit un formulaire pré-rempli avec sa meilleure estimation afin que l'humain se contente de confirmer plutôt que de ressaisir.

Le pipeline gère plus de 300 types de documents prêts à l'emploi ; des modèles personnalisés peuvent être ajoutés via un éditeur de schéma low-code.

La latence de bout en bout depuis la réception du document jusqu'à l'entrée dans l'ERP est en moyenne inférieure à 90 secondes pour les documents propres.

ECOSIRE construit et gère des pipelines de traitement de documents OpenClaw intégrés à Odoo, SAP, QuickBooks et des ERP personnalisés.

Présentation de l'architecture de traitement des documents

Un pipeline de traitement de documents OpenClaw de production se compose de six étapes, chacune implémentée comme une ou plusieurs compétences :

Document Ingestion
        ↓
[ Classifier Agent ]     — document type detection, routing
        ↓
[ Extraction Agent ]     — OCR + structured data extraction
        ↓
[ Validation Agent ]     — business rule validation, master data lookup
        ↓
[ Enrichment Agent ]     — GL coding, cost center assignment, approver lookup
        ↓
[ Integration Agent ]    — ERP/downstream system write
        ↓
[ Exception Agent ]      — handles ambiguous documents, requests human review

Chaque agent fonctionne indépendamment et communique via le bus de tâches. Les documents ayant échoué à n'importe quelle étape sont acheminés vers l'agent d'exception sans perdre le travail déjà effectué dans les étapes en amont.

Ingestion de documents : accepter tous les formats

Les documents arrivent via plusieurs canaux : pièces jointes aux e-mails, suppressions du système de fichiers, téléchargements d'API, passerelles fax-e-mail et portails des fournisseurs. La couche d'ingestion normalise tous ces éléments en une tâche documentaire standard.

export const DocumentIngester = defineSkill({
  name: "document-ingester",
  tools: ["email", "storage", "queue"],
  async run({ input, tools }) {
    let rawFile: Buffer;
    let mimeType: string;

    if (input.source === "email") {
      const attachment = await tools.email.getAttachment(input.emailId, input.attachmentIndex);
      rawFile = attachment.buffer;
      mimeType = attachment.mimeType;
    } else if (input.source === "storage") {
      rawFile = await tools.storage.get(input.storageKey);
      mimeType = detectMimeType(rawFile);
    }

    // Normalize to PDF for consistent downstream processing
    const normalizedPdf = mimeType === "application/pdf"
      ? rawFile
      : await convertToPdf(rawFile, mimeType);

    const storageKey = `incoming/${Date.now()}-${generateId()}.pdf`;
    await tools.storage.put(storageKey, normalizedPdf);

    return {
      storageKey,
      originalSource: input.source,
      originalMimeType: mimeType,
      pagCount: await getPdfPageCount(normalizedPdf),
    };
  },
});

L'étape de normalisation convertit les documents Word, les fichiers Excel, les fichiers image (JPEG, PNG, TIFF) et les corps HTML envoyés par courrier électronique au format PDF avant de les transmettre en aval. Les agents en aval ne reçoivent que des fichiers PDF, ce qui simplifie considérablement l'OCR et l'analyse de la mise en page.

Classification des documents : savoir ce que vous avez

Avant le début de l'extraction, l'agent classificateur identifie le type de document. La classification est importante car différents types de documents nécessitent différents modèles d'extraction : une facture ne ressemble en rien à un reçu de livraison.

Le classificateur utilise une approche en deux étapes :

Étape 1 — Analyse de la mise en page : la structure visuelle du document (positions du tableau, blocs d'en-tête, modèles de pied de page, placement du logo) est analysée pour restreindre la catégorie du document à un petit ensemble de candidats.

Étape 2 — Classification du contenu : les phrases clés et les modèles structurels dans le texte confirment le type de document spécifique. Le classificateur produit une étiquette de type et un score de confiance.

export const ClassifyDocument = defineSkill({
  name: "classify-document",
  tools: ["storage", "classification-model"],
  async run({ input, tools }) {
    const pdfBuffer = await tools.storage.get(input.storageKey);
    const layoutFeatures = await extractLayoutFeatures(pdfBuffer);
    const textContent = await performOcr(pdfBuffer, { mode: "fast" });

    const classification = await tools.classificationModel.classify({
      layoutFeatures,
      textContent: textContent.slice(0, 2000), // First 2000 chars for speed
    });

    if (classification.confidence < 0.70) {
      return {
        type: "unknown",
        confidence: classification.confidence,
        requiresManualClassification: true,
      };
    }

    return {
      type: classification.label,
      confidence: classification.confidence,
      requiresManualClassification: false,
      extractionTemplate: TEMPLATE_MAP[classification.label],
    };
  },
});

Les types de documents courants et leurs modèles d'extraction sont prédéfinis : factures fournisseurs, notes de crédit, bons de commande, bons de livraison, relevés bancaires, contrats, notes de frais et déclarations en douane. De nouveaux types de documents peuvent être ajoutés via l'éditeur de modèles sans modification du code.

OCR et extraction : extraire les données avec précision

L’agent d’extraction est l’endroit où réside l’essentiel de la complexité technique. Il combine la sortie OCR avec l'analyse de la mise en page et l'analyse basée sur LLM pour produire des données structurées à partir de documents non structurés.

La qualité de l’OCR est évaluée avant le début de l’extraction de l’IA. Si la confiance moyenne des caractères de l'OCR est inférieure à 0,80 (ce qui indique une numérisation floue, une faible résolution ou une page asymétrique), l'agent marque le document pour une nouvelle analyse plutôt que de poursuivre avec un texte peu fiable.

Pour les documents qui réussissent les contrôles de qualité OCR, l'extraction se déroule en trois étapes :

Pass 1 – Correspondance de modèle : pour les fournisseurs et les formats de documents connus, le modèle d'extraction fournit des positions de champ (coordonnées ou ancres d'expression régulière). La correspondance des modèles est rapide et précise pour les documents structurés provenant de sources connues.

Pass 2 — Reconnaissance d'entité nommée : NER identifie les montants, les dates, les adresses, les identifiants (numéros de facture, numéros de bon de commande, numéros de TVA) et les limites des éléments de ligne que la correspondance du modèle a manquée.

Pass 3 — Raisonnement LLM : pour les champs ambigus ou lorsque les deux premières passes produisent des valeurs de faible confiance, un LLM analyse le contexte du texte environnant pour en déduire la valeur correcte.

export const ExtractInvoiceData = defineSkill({
  name: "extract-invoice-data",
  tools: ["storage", "ocr-service", "llm"],
  async run({ input, tools, memory }) {
    const buffer = await tools.storage.get(input.storageKey);
    const ocrResult = await tools.ocrService.extract(buffer, { enhanceScannedPages: true });

    if (ocrResult.averageConfidence < 0.80) {
      return { success: false, reason: "LOW_OCR_QUALITY", ocrConfidence: ocrResult.averageConfidence };
    }

    // Pass 1: Template matching
    const templateFields = applyTemplate(ocrResult, input.extractionTemplate);

    // Pass 2: NER for missing fields
    const nerFields = await extractWithNer(ocrResult.text, { fieldTypes: ["amount", "date", "id"] });

    // Pass 3: LLM for remaining low-confidence fields
    const lowConfidenceFields = mergeAndFindGaps(templateFields, nerFields, { minConfidence: 0.85 });
    const llmFields = lowConfidenceFields.length > 0
      ? await tools.llm.extractFields(ocrResult.text, lowConfidenceFields)
      : {};

    const extracted = mergeExtractions(templateFields, nerFields, llmFields);
    await memory.working.set("extractedData", extracted);

    return { success: true, data: extracted, fieldConfidences: getFieldConfidences(extracted) };
  },
});

Validation : détecter les erreurs avant qu'elles n'atteignent votre ERP

Les données brutes extraites ne sont jamais écrites directement dans votre ERP. L'agent de validation vérifie chaque champ par rapport à vos règles métier et à vos données de base avant que quoi que ce soit ne soit publié.

Les contrôles de validation d'une facture fournisseur comprennent :

Le fournisseur existe : le nom du fournisseur et le numéro de TVA correspondent à un enregistrement dans la fiche fournisseur.
Correspondance du bon de commande : le numéro du bon de commande sur la facture correspond à un bon de commande ouvert et les montants sont dans les limites de tolérance (généralement ± 5 % pour la flexibilité de facturation).
Détection de doublons : Le numéro de facture de ce fournisseur n'a pas été traité au cours des 180 derniers jours.
Calcul des taxes : le total des éléments de ligne plus les taxes est égal au total de la facture, dans les limites de la tolérance d'arrondi.
Devise et taux de change : Les factures en devises sont validées par rapport au taux de change en vigueur à la date de facturation.
Période GL : La date de facture tombe dans une période comptable ouverte.

export const ValidateInvoice = defineSkill({
  name: "validate-invoice",
  tools: ["erp", "vendor-master"],
  async run({ input, tools }) {
    const errors: ValidationError[] = [];

    // Vendor validation
    const vendor = await tools.vendorMaster.findByVatNumber(input.data.vendorVat);
    if (!vendor) errors.push({ field: "vendorVat", code: "VENDOR_NOT_FOUND" });

    // PO match
    if (input.data.poNumber) {
      const po = await tools.erp.getPurchaseOrder(input.data.poNumber);
      if (!po) errors.push({ field: "poNumber", code: "PO_NOT_FOUND" });
      else if (Math.abs(po.totalAmount - input.data.totalAmount) / po.totalAmount > 0.05) {
        errors.push({ field: "totalAmount", code: "PO_AMOUNT_MISMATCH" });
      }
    }

    // Duplicate check
    const isDuplicate = await tools.erp.invoiceExists({
      vendorId: vendor?.id,
      invoiceNumber: input.data.invoiceNumber,
    });
    if (isDuplicate) errors.push({ field: "invoiceNumber", code: "DUPLICATE_INVOICE" });

    return {
      valid: errors.length === 0,
      errors,
      validatedData: errors.length === 0 ? input.data : null,
    };
  },
});

Les échecs de validation sont acheminés vers l’agent d’exception plutôt que de supprimer silencieusement le document. L'agent d'exception crée une tâche de révision pré-remplie avec les données extraites et les erreurs de validation spécifiques, afin qu'un humain puisse corriger uniquement les champs signalés.

Enrichissement : ajout d'un contexte commercial

Des données propres et validées nécessitent toujours un contexte commercial avant de pouvoir être publiées dans un ERP. L'agent d'enrichissement ajoute les informations que les documents ne contiennent pas : codes de compte GL, affectations de centres de coûts, codes de traitement fiscal, affectations de workflow d'approbation et conditions de paiement.

Les règles d'enrichissement sont définies dans un magasin de stratégies et peuvent faire référence aux attributs du fournisseur, aux descriptions d'éléments de ligne, au département, aux codes de projet et aux seuils de montant. La plupart des règles d'enrichissement sont des recherches déterministes ; pour les cas ambigus (éléments de ligne avec des descriptions pouvant correspondre à plusieurs comptes GL), le LLM fournit une liste de suggestions classées avec des explications.

Intégration ERP : écriture de données avec précision du premier coup

L'agent d'intégration publie des données validées et enrichies dans votre ERP. Il utilise des appels API idempotents avec un ID de corrélation dérivé du hachage du document d'origine : si l'écriture ERP est réessayée (en raison d'un délai d'attente du réseau), les enregistrements en double sont évités.

export const PostToErp = defineSkill({
  name: "post-to-erp",
  tools: ["erp"],
  async run({ input, tools }) {
    const correlationId = hashDocument(input.storageKey);

    const result = await tools.erp.createVendorBill({
      correlationId, // ERP uses this for idempotency
      vendorId: input.enrichedData.vendorId,
      invoiceNumber: input.enrichedData.invoiceNumber,
      invoiceDate: input.enrichedData.invoiceDate,
      lineItems: input.enrichedData.lineItems,
      taxLines: input.enrichedData.taxLines,
      paymentTerms: input.enrichedData.paymentTerms,
      glCodes: input.enrichedData.glCodes,
    });

    return {
      erpRecordId: result.id,
      erpRecordUrl: result.url,
      posted: true,
    };
  },
});

Après publication, le document original est lié à l'enregistrement ERP et archivé dans votre système de gestion documentaire avec des métadonnées complètes. La piste d'audit est complète : de la pièce jointe à l'e-mail ou du fichier déposé en passant par chaque étape de traitement jusqu'à l'entrée finale dans l'ERP.

Gestion des exceptions : humain dans la boucle quand cela compte

Tous les documents ne seront pas traités proprement. L'agent d'exception gère quatre catégories d'exceptions :

Échecs de classification : Le type de document n'a pas pu être déterminé avec suffisamment de confiance.
Échecs d'extraction : les champs critiques (montant total, identifiant du fournisseur, numéro de facture) n'ont pas pu être extraits.
Échecs de validation : les données extraites ne réussissent pas les vérifications des règles métier.
Échecs d'intégration : l'ERP a rejeté la comptabilisation (par exemple, période comptable clôturée, compte verrouillé).

Pour chaque exception, l'agent crée une tâche de révision dans votre service d'assistance ou votre système de flux de travail avec un formulaire pré-rempli indiquant la meilleure tentative de l'agent et l'erreur spécifique. L'humain corrige uniquement les champs défaillants et approuve ; l'agent gère la resoumission.

Questions fréquemment posées

Quelle résolution de document est requise pour une OCR précise ?

Pour les documents imprimés, 150 DPI est le minimum pour des résultats OCR acceptables ; 300 DPI sont recommandés pour une extraction fiable. Pour les documents manuscrits ou les documents comportant de très petites tailles de police, une résolution de 400 DPI ou plus est préférable. La compétence d'évaluation de la qualité OCR signale les documents en dessous du seuil avant le début de l'extraction, déclenchant automatiquement une demande de nouvelle analyse.

Comment le système gère-t-il les documents de plusieurs pages ?

Les documents de plusieurs pages sont traités avec détection des limites de page. Pour les factures, l'agent identifie la page d'en-tête, les pages d'éléments de ligne et toutes les pages de suite. Les éléments de ligne s'étendant sur les sauts de page sont correctement reconstruits par la couche d'analyse de mise en page. Pour les autres types de documents (contrats, rapports), l'agent traite toutes les pages et agrège les champs extraits de chaque page.

Le système peut-il apprendre des corrections apportées par les humains ?

Oui. Lorsqu'un humain corrige un document d'exception, la correction est renvoyée à l'agent de connaissances. Si le même modèle de correction apparaît plus de trois fois (par exemple, un nouveau fournisseur formate toujours sa facture de manière non standard), le système propose automatiquement un nouveau modèle d'extraction pour ce fournisseur. Un administrateur examine et approuve le modèle proposé, et le système l'applique à partir de ce moment sans examen humain pour ce fournisseur.

Comment les documents manuscrits sont-ils traités ?

Les documents manuscrits constituent la catégorie la plus difficile. La couche OCR utilise un modèle spécialisé de reconnaissance de l'écriture manuscrite pour ces documents, et le seuil de confiance pour passer à l'extraction par l'IA est plus élevé (0,90 contre 0,80 pour les documents imprimés). En pratique, la plupart des flux de documents d'entreprise peuvent éliminer les documents manuscrits grâce à des changements de processus (portails de soumission électronique, flux de signature numérique). Pour les organisations qui doivent traiter des documents manuscrits, ECOSIRE recommande une approche hybride avec révision humaine pour les documents à forte écriture manuscrite.

Quelles langues sont prises en charge pour l'extraction ?

Le traitement des documents d'OpenClaw prend en charge plus de 40 langues pour l'OCR, avec des modèles d'extraction validés pour les principaux formats de documents commerciaux en anglais, allemand, français, espagnol, arabe, chinois (simplifié et traditionnel), japonais et portugais. Pour d'autres langues, l'OCR fonctionne mais la qualité du modèle d'extraction dépend de votre ensemble d'échantillons de documents. La couche de raisonnement LLM gère de nombreux langages de manière native.

Comment la confidentialité des documents est-elle assurée ?

Les documents sont chiffrés en transit (TLS 1.3) et au repos (AES-256). Chaque document est traité dans un contexte isolé : aucun contenu de document n'est partagé entre les organisations. Pour les documents très sensibles (contrats juridiques, états financiers), vous pouvez configurer le pipeline pour utiliser un LLM sur site pour la couche de raisonnement, conservant ainsi le contenu du document entièrement dans le périmètre de votre réseau.

Quel est le taux d'exactitude typique pour le traitement des factures ?

Pour les factures structurées de fournisseurs connus avec correspondance de modèles, la précision au niveau du champ dépasse généralement 99,5 % après l'étalonnage du modèle. Pour les factures non structurées provenant de nouveaux fournisseurs, l'exactitude est généralement de 95 à 98 % dès la première tentative, et s'améliore à mesure que le système apprend le format du fournisseur. La mesure clé à suivre est le taux d’exceptions : des pipelines bien configurés voient des taux d’exceptions inférieurs à 5 % du volume total de documents.

Prochaines étapes

Le traitement manuel des documents est un centre de coûts qui n’ajoute aucune valeur concurrentielle. L'automatisation du traitement des documents OpenClaw le convertit d'une opération à forte intensité de personnel en un pipeline automatisé qui gère plus de 95 % de votre volume de documents sans intervention humaine.

L'équipe de mise en œuvre d'OpenClaw d'ECOSIRE est spécialisée dans la création de pipelines de traitement de documents intégrés à Odoo, SAP, QuickBooks et ERP personnalisés. Nous gérons la conception de modèles de classification de documents, l'étalonnage OCR, la configuration des règles de validation, l'intégration ERP et la configuration du flux de travail d'exception, fournissant ainsi un système prêt pour la production en six à huit semaines.

Contactez ECOSIRE pour débuter par un audit du traitement documentaire de votre opération actuelle.

Document Processing Automation with OpenClaw