Factures fournisseurs : contrôler l’extraction IA avant l’import dans le POS

Article d’archive. Texte préparé le 3 novembre 2026, mis en ligne le 7 novembre 2026.

Un montant bien présenté peut être erroné. Avant d’envoyer des factures extraites par IA dans un POS, il faut vérifier les pièces, les quantités et les totaux, puis décider quels cas doivent revenir à un opérateur.

L’objectif est donc de construire une chaîne contrôlée : document original, extraction proposée, vérifications, validation puis import. Les annonces récentes sur l’extraction documentaire donnent un point de départ, mais le critère décisif reste la qualité obtenue sur les documents réellement traités.

Ce que les publications récentes apportent

Le 29 octobre 2026, LlamaIndex présente Extract V2.6 « Max Effort », un réglage de sa formule agentic_plus pouvant mobiliser davantage de calcul sur les documents difficiles, avec une facturation variable. Cette annonce commerciale ne démontre pas qu’un réglage plus coûteux sera préférable pour toutes les factures. Elle invite surtout à comparer qualité, coût et temps de correction sur un échantillon représentatif.

Dans ExtractBench Pro, publié le 15 octobre 2026, Boyang Zhang et Justin Xu décrivent des difficultés allant des règles d’interprétation aux agrégations conditionnelles. Les documents du jeu sont synthétiques, inspirés de situations complexes. Ce sont des publications originales du fournisseur, également évaluateur de ses produits ; elles ne sont pas présentées ici comme des études indépendantes évaluées par les pairs. Le protocole suivant est une proposition pratique, pas une reproduction de leurs résultats.

Définir les champs et leurs preuves

Commencez par un périmètre limité : fournisseur, numéro de facture, date, devise, montants HT, taxe et TTC, puis lignes d’articles. Pour chaque champ, conservez la valeur brute, la valeur normalisée et une référence de preuve : page et zone du document, ou extrait textuel localisable. Un champ illisible doit rester absent ou être marqué à vérifier, plutôt que complété à partir des habitudes du fournisseur.

Préservez les identifiants sous forme de chaînes : un numéro comme « 00047 » perd son sens si un programme le transforme en entier. Distinguez également zéro et absence de valeur. Le schéma doit préciser les types, les champs obligatoires et les cas de refus ; un JSON syntaxiquement correct peut contenir des données fausses.

Séparer extraction et calcul

Demandez d’abord ce qui figure sur la pièce. Un total calculé par le système doit rester identifiable comme calcul, avec sa formule. Cela évite qu’une déduction soit ensuite présentée comme un montant imprimé sur la facture. Pour un avoir, une remise globale, un acompte ou plusieurs taux de taxe, les règles doivent être définies explicitement avant toute automatisation.

Exemple fictif : le document affiche 200,00 HT, 40,00 de taxe et 240,00 TTC. Une sortie donnant 290,00 TTC doit être signalée. L’égalité entre les trois montants ne prouve cependant ni l’identité du fournisseur, ni l’exactitude des lignes, ni la validité fiscale de la pièce. Un contrôle arithmétique constitue seulement un filtre.

Un filtre reproductible en Python

La documentation Python 3.14 du module decimal explique la représentation décimale exacte et le contrôle des arrondis. Construire les montants à partir de chaînes évite d’introduire les approximations d’un flottant binaire. Le code ci-dessous attend des chaînes déjà normalisées ; il refuse volontairement les autres formats au lieu de deviner leur sens.

from decimal import Decimal
import re

def montant(valeur):
    # Entrée déjà normalisée : point décimal, sans devise.
    if not isinstance(valeur, str) or len(valeur) > 20:
        raise ValueError("Montant à relire")
    if not re.fullmatch(r"-?[0-9]+(?:\.[0-9]{1,2})?", valeur):
        raise ValueError("Format à relire")
    return Decimal(valeur)

def total_coherent(ht, taxe, ttc):
    ecart = abs(montant(ht) + montant(taxe) - montant(ttc))
    return ecart <= Decimal("0.01")

# Données fictives ; ceci ne valide pas la facture.
print(total_coherent("200.00", "40.00", "240.00"))  # True
print(total_coherent("200.00", "40.00", "290.00"))  # False

La tolérance d’un centime est un choix de démonstration, à remplacer par la règle d’arrondi documentée du processus. Elle ne convient pas automatiquement à toutes les devises. Les exceptions doivent envoyer le dossier vers une relecture. Même un résultat True ne doit pas déclencher l’import : d’autres contrôles restent nécessaires.

Traiter les vrais pièges du catalogue

Un fournisseur facture parfois des cartons alors que le POS gère des unités. Associer directement les quantités peut fausser les stocks. Maintenez une correspondance vérifiée entre référence fournisseur, article interne, unité d’achat et coefficient de conversion. Une ressemblance de libellé proposée par l’IA peut aider à rechercher ; elle ne suffit pas à créer cette correspondance.

Contrôlez aussi les doublons à deux niveaux. Une empreinte du fichier repère un renvoi identique ; une clé métier combinant fournisseur vérifié et numéro de pièce peut signaler une seconde photographie de la même facture. Conservez les références originales et les cas particuliers : numéro absent, avoir lié ou correction. L’import doit posséder son propre identifiant durable pour empêcher qu’une reprise technique enregistre deux fois la même opération.

Évaluer les erreurs qui comptent

Constituez un petit lot relu manuellement, avec tableaux multipages, photos inclinées, virgules décimales, remises et documents français ou arabes si ces langues sont présentes. Séparez les fournisseurs utilisés pour régler le système de ceux réservés au test final. Faites confirmer les champs critiques par une seconde lecture lorsque l’ambiguïté persiste.

Mesurez séparément l’exactitude des montants, l’association correcte des lignes, les omissions et les valeurs inventées. Suivez aussi la proportion de documents envoyés en relecture et le temps de correction. Une moyenne par champ peut masquer un dossier inutilisable : calculez également la proportion de pièces dont tous les champs critiques sont corrects. Aucun résultat chiffré n’est revendiqué ici.

Donner un rôle limité aux agents

Un agent peut demander une nouvelle lecture d’une zone, rapprocher un code d’un dictionnaire validé ou expliquer un écart. Il doit conserver la trace de ses étapes, respecter un budget et s’arrêter lorsque les preuves manquent. Le contenu d’une facture demeure une donnée à analyser : une instruction imprimée dans le document ne doit jamais modifier les règles du traitement.

Présentez au validateur la pièce et les champs côte à côte, puis journalisez les corrections et l’import. Limitez les données transmises aux services externes et vérifiez leurs conditions de traitement avant l’essai. Pour uniCenta ou un autre POS, utilisez un chemin d’import adapté à la version installée ; ce protocole ne constitue ni un connecteur livré ni une validation de compatibilité. Cette logique prolonge la conception d’une caisse à partir du travail réel.

Références et limites

Eli Stewart, Extract V2.6: Max Effort, 29 octobre 2026 ; Boyang Zhang et Justin Xu, ExtractBench Pro, 15 octobre 2026 ; Python Software Foundation, decimal, documentation Python 3.14, référence de fond consultée le 3 novembre 2026. Les deux annonces sont lues sur le site de leurs auteurs. Les exemples et les règles proposées sont pédagogiques et ne constituent pas un avis fiscal.