Compta : extraction de factures

#Ce qu'on automatise, et à quel niveau de fiabilité

À partir d'un PDF de facture fournisseur, on veut obtenir un JSON structuré (fournisseur, numéro, date, montants HT, TVA et TTC, lignes) que l'on peut importer par lot dans le logiciel comptable. Un modèle de vision servi par Ollama lit directement l'image de la page, sans passer par un OCR séparé. La règle qui rend le montage fiable tient en une phrase : le modèle lit, le code contrôle. Une extraction n'est jamais importée sans passer des vérifications arithmétiques et d'identifiants, et tout ce qui échoue part en file de relecture humaine.

Ce guide vise un cas concret : un cabinet ou une PME qui reçoit quelques centaines de factures par mois, sur un poste ou un petit serveur local. Aucun chiffre de précision n'est promis ici : la précision dépend de vos fournisseurs, de la qualité des scans et du modèle. La méthode de mesure figure plus bas, sur un échantillon de vos propres factures.

#Facture électronique : ce qui change en 2026 et 2027

Avant de construire un pipeline de lecture, il faut regarder ce que la réforme fait aux factures entrantes. Depuis le 1er septembre 2026, selon impots.gouv.fr, les grandes entreprises et les entreprises de taille intermédiaire doivent émettre leurs factures via une plateforme agréée, et toutes les entreprises doivent être en capacité de recevoir des factures électroniques. Pour les PME, TPE et micro-entreprises, l'obligation d'émission s'applique à compter du 1er septembre 2027, d'après le guide pratique de l'administration fiscale.

La conséquence pratique est double. D'une part, une part croissante de vos factures entrantes arrivera déjà sous forme structurée, sans qu'aucune lecture par IA ne soit nécessaire. D'autre part, le format Factur-X, standard franco-allemand de facture mixte, embarque dans un même fichier un PDF lisible et des données XML pour le traitement automatisé, avec plusieurs profils de données. Quand un PDF contient ce XML, le lire directement est plus sûr que de le faire deviner par un modèle. Le pipeline ci-dessous applique donc un ordre de priorité : données structurées si elles existent, texte natif du PDF ensuite, vision en dernier recours.

#Choisir le modèle : ce que la vision demande en mémoire

Pour la lecture de factures, deux familles conviennent dans la bibliothèque Ollama. Qwen 3.5 en 9 milliards de paramètres pèse 6,6 Go, accepte texte et image et annonce une fenêtre de 256 000 tokens ; sa version 27B pèse 17 Go. Gemma 4, avec sa variante e4b, occupe entre 6,6 et 9,5 Go selon la fiche Ollama et annonce 128 000 tokens de contexte, texte et image. Une carte de 12 Go suffit donc pour la variante 9B ou e4b, avec de la marge pour les images de pages.

Repère de mémoire du site : un modèle de 9 milliards de paramètres en Q4 pèse environ 5 à 6 Go, auxquels s'ajoutent le cache de contexte et les images de la page. Les pages de factures multipages coûtent plus que les autres : un lot de dix pages en une requête peut dépasser la fenêtre par défaut d'Ollama, qui reste bien inférieure aux 256 000 tokens annoncés par le modèle tant que vous ne la relevez pas.

#Trier les PDF avant de lire : natif, scanné, structuré

Détecter le type de fichier évite d'envoyer inutilement une image à un modèle de vision. Avec la bibliothèque PyMuPDF, un PDF dont le texte extrait fait plus de quelques centaines de caractères est natif ; un PDF quasi vide de texte est un scan. Les fichiers Factur-X contiennent une pièce jointe XML que l'on peut lister avant tout autre traitement.

import fitz  # PyMuPDF

def type_pdf(chemin):
    doc = fitz.open(chemin)
    pieces = doc.embfile_names()  # pièces jointes intégrées
    if any(n.lower().endswith('.xml') for n in pieces):
        return 'structure'
    texte = ''.join(page.get_text() for page in doc)
    return 'natif' if len(texte.strip()) > 300 else 'scan'

Pour les scans de mauvaise qualité, Tesseract reste un filet de secours gratuit et hors ligne : il faut alors installer le fichier de langue française et scanner à 300 points par pouce. Le guide sur Tesseract détaille les réglages. Un texte issu d'un mauvais OCR ne doit jamais passer sans contrôle : c'est la file de relecture humaine qui prend le relais.

# macOS
brew install tesseract tesseract-lang

# Ubuntu / Debian
sudo apt install tesseract-ocr tesseract-ocr-fra

#Extraire avec un modèle de vision et un schéma imposé

Ollama sait contraindre la réponse du modèle à un schéma JSON : d'après sa documentation, on fournit un schéma au champ format, et il est conseillé de le répéter aussi dans le prompt pour ancrer la réponse. C'est nettement plus robuste que demander « un JSON » en texte libre, car les clés et les types sont imposés. Pour les images, l'API REST attend des images encodées en base64 dans le champ images du message.

import base64, json, requests
from io import BytesIO
from pdf2image import convert_from_path

SCHEMA = {
  'type': 'object',
  'properties': {
    'fournisseur': {'type': 'object', 'properties': {
      'nom': {'type': 'string'},
      'siret': {'type': ['string', 'null']},
      'tva_intra': {'type': ['string', 'null']}}},
    'facture': {'type': 'object', 'properties': {
      'numero': {'type': 'string'},
      'date': {'type': 'string'},
      'echeance': {'type': ['string', 'null']}}},
    'montants': {'type': 'object', 'properties': {
      'ht': {'type': 'number'}, 'tva': {'type': 'number'},
      'ttc': {'type': 'number'}, 'devise': {'type': 'string'}}},
    'lignes': {'type': 'array', 'items': {'type': 'object', 'properties': {
      'description': {'type': 'string'}, 'quantite': {'type': 'number'},
      'pu_ht': {'type': 'number'}, 'total_ht': {'type': 'number'}}}}
  },
  'required': ['fournisseur', 'facture', 'montants']
}

PROMPT = ("Tu extrais les données d'une facture française. "
  "Réponds uniquement par un JSON conforme à ce schéma : " + json.dumps(SCHEMA) +
  ". Si une donnée est absente ou illisible, mets null. Les montants sont des nombres (1234.56), "
  "les dates au format AAAA-MM-JJ. N'invente rien.")

def pages_b64(pdf, dpi=200):
    sortie = []
    for img in convert_from_path(pdf, dpi=dpi):
        buf = BytesIO(); img.save(buf, format='PNG')
        sortie.append(base64.b64encode(buf.getvalue()).decode())
    return sortie

def extraire(pdf):
    r = requests.post('http://localhost:11434/api/chat', json={
      'model': 'qwen3.5:9b', 'stream': False, 'format': SCHEMA,
      'messages': [{'role': 'user', 'content': PROMPT, 'images': pages_b64(pdf)}],
      'options': {'temperature': 0, 'num_ctx': 16384}})
    return json.loads(r.json()['message']['content'])

Trois choix méritent une explication. La température à zéro rend la sortie reproductible. Le paramètre num_ctx relève la fenêtre, car les images de plusieurs pages consomment vite la fenêtre par défaut d'Ollama, réduite ; le guide sur la fenêtre de contexte détaille ce mécanisme. Enfin, la consigne « N'invente rien » avec une valeur null autorisée réduit le risque le plus grave : un modèle qui comble un champ illisible par une valeur plausible. Un schéma strict force la forme de la réponse, pas la justesse de son contenu.

#Étendre le schéma à vos cas réels

Le schéma de base couvre la plupart des factures de fournisseurs courants. Les extensions à prévoir dépendent de votre activité. Ajoutez-les une par une et mesurez l'effet de chacune sur votre échantillon : un schéma trop chargé dégrade la lecture des champs essentiels.

Acompte et solde

Ajoutez un champ acompte_paye. Sans lui, le total TTC ne correspond pas au reste à payer.

Références de commande

Un champ bon_commande_ref permet le rapprochement avec vos commandes.

Frais de port et remises

Ligne dédiée ou champ port_ht, sinon la somme des lignes ne retombe pas sur le HT.

Ventilation de TVA

Une liste taux, base, montant. Indispensable dès que la facture mélange plusieurs taux.

Imputation comptable

Ne demandez pas au modèle de deviner le compte : produisez une proposition, marquée comme telle, que votre règle métier ou un humain confirme.

#Valider avant d'importer : les contrôles qui attrapent les erreurs

C'est l'étape qui décide de la qualité du montage. Chaque contrôle est déterministe, donc plus fiable que le modèle. Le premier est arithmétique : HT plus TVA doit égaler le TTC, avec une tolérance de quelques centimes pour les arrondis. Le deuxième porte sur les lignes : leur somme doit retomber sur le HT. Le troisième sur les dates : ni antérieures à une limite raisonnable, ni dans le futur. Le quatrième sur le SIRET.

Le contrôle du SIRET mérite une attention particulière. Le numéro compte 14 chiffres et son dernier chiffre est une clé de contrôle calculée avec la formule de Luhn, précise Wikipédia. Une exception existe : les établissements de La Poste, dont le SIREN est 356000000, suivent une autre règle où la somme des 14 chiffres doit être un multiple de 5. Un contrôle naïf par Luhn rejetterait donc à tort des factures de La Poste. Le code suivant gère les deux cas.

from datetime import date

def luhn_ok(s):
    total = 0
    for i, c in enumerate(reversed(s)):
        d = int(c)
        if i % 2 == 1:
            d *= 2
            if d > 9:
                d -= 9
        total += d
    return total % 10 == 0

def siret_valide(s):
    if not (s.isdigit() and len(s) == 14):
        return False
    if s.startswith('356000000'):  # La Poste : somme multiple de 5
        return sum(int(c) for c in s) % 5 == 0
    return luhn_ok(s)

def valider(f):
    erreurs = []
    m = f['montants']
    if abs(m['ht'] + m['tva'] - m['ttc']) > 0.02:
        erreurs.append('HT + TVA différent du TTC')
    lignes = f.get('lignes') or []
    if lignes and abs(sum(l['total_ht'] for l in lignes) - m['ht']) > 0.05:
        erreurs.append('somme des lignes différente du HT')
    siret = (f['fournisseur'].get('siret') or '').replace(' ', '')
    if siret and not siret_valide(siret):
        erreurs.append('SIRET invalide : ' + siret)
    try:
        d = date.fromisoformat(f['facture']['date'])
        if d.year < 2000 or d > date.today():
            erreurs.append('date suspecte : ' + str(d))
    except ValueError:
        erreurs.append('date illisible')
    return erreurs

#Mesurer la précision sur vos propres factures

Aucun chiffre de précision publié ne remplace une mesure sur votre corpus, car un cabinet qui traite des factures de grossistes n'a pas les mêmes documents qu'une association. Constituez un échantillon d'une cinquantaine de factures représentatives, saisissez à la main les champs essentiels, puis comparez champ par champ.

1. 01
   Constituer l'échantillon

   Prenez des factures réelles variées : scans, PDF natifs, plusieurs pages, plusieurs fournisseurs. Anonymisez si vous partagez les résultats.
2. 02
   Saisir la vérité terrain

   Notez à la main les champs à automatiser : numéro, date, HT, TVA, TTC, SIRET.
3. 03
   Comparer champ par champ

   Calculez le taux d'exactitude par champ, pas globalement : un modèle peut lire les dates parfaitement et se tromper sur les TVA.
4. 04
   Fixer un seuil d'automatisation

   Décidez quels champs peuvent être importés sans relecture. Les montants, s'ils passent le contrôle arithmétique, en sont de bons candidats ; l'imputation comptable, jamais.
5. 05
   Rejouer à chaque changement

   Changez de modèle, de résolution ou de prompt : relancez l'échantillon avant de passer en production.

#Traiter un dossier de factures par lot

Le traitement par lot enchaîne le tri, l'extraction et la validation, puis range chaque facture selon le résultat. Conservez toujours deux fichiers côte à côte : le PDF d'origine et le JSON extrait.

from pathlib import Path
import json

def traiter(dossier_in, dossier_ok, dossier_revue):
    for pdf in Path(dossier_in).glob('*.pdf'):
        try:
            f = extraire(str(pdf))
            erreurs = valider(f)
        except Exception as e:
            f, erreurs = {}, ['échec extraction : ' + str(e)]
        dest = Path(dossier_ok if not erreurs else dossier_revue)
        (dest / (pdf.stem + '.json')).write_text(
            json.dumps({'donnees': f, 'erreurs': erreurs}, ensure_ascii=False, indent=2))
        pdf.rename(dest / pdf.name)
        print(('OK ' if not erreurs else 'A VERIFIER ') + pdf.name)

#Verser les données dans le logiciel comptable

Chaque éditeur a son format d'import, et ses spécifications évoluent : partez de la documentation de votre outil, pas d'un modèle générique. Les logiciels de comptabilité proposent en général un import par fichier structuré ou une interface de programmation. Le plus sûr est de produire un fichier d'import conforme, de le charger dans un dossier de test, puis de comparer les écritures créées à celles que vous auriez saisies.

Conservez la piste d'audit : le PDF original, le JSON extrait, la version du modèle et la date de traitement. En cas de contrôle, vous devez pouvoir remonter de l'écriture comptable à la pièce justificative. Les factures contiennent des données personnelles et commerciales : rester en local évite d'en confier à un tiers, mais le stockage des fichiers relève toujours de vos règles de conservation et de sécurité.

• Tesseract OCR : lire un scan en local
• PaddleOCR : l'OCR qui comprend la page
• Docling : convertir des PDF pour une IA locale
• LLM multimodal en local avec Ollama
• Sorties JSON structurées avec Ollama
• Comprendre la fenêtre de contexte

• Source : impots.gouv.fr, facturation électronique
• Source : guide pratique de la facturation électronique (DGFiP)
• Source : le format Factur-X (FNFE-MPE)
• Source : sorties structurées Ollama
• Source : Qwen 3.5 dans la bibliothèque Ollama