RAG sur factures fournisseurs : architecture hybride SQL + IA

"Je veux savoir en 30 secondes combien j'ai dépensé chez ce fournisseur depuis janvier." Cette demande, on l'entend dans quasiment chaque PME qui s'interroge sur l'IA appliquée à sa comptabilité fournisseurs. Et c'est précisément là que la plupart des projets RAG sur factures échouent à la première démonstration.

Le problème est architectural. Un RAG classique retrouve des passages textuellement proches d'une question. Sur des factures, les comptables et les DAF ne veulent pas une réponse "ressemblante" : ils veulent un chiffre exact, vérifiable, auditable. Pour ça, il faut du SQL, pas du retrieval vectoriel. Et pourtant, le SQL seul ne répond pas aux questions ouvertes ("quelles factures semblent suspectes ce mois ?", "quels fournisseurs ont modifié leurs coordonnées bancaires récemment ?").

Cet article détaille l'architecture hybride SQL + RAG que nous recommandons et déployons chez Tensoria pour ce cas d'usage : comment structurer l'ingestion, pourquoi la détection de fraude IBAN doit rester déterministe, comment se préparer à la réforme de la facture électronique B2B 2026, et ce que tout ça coûte réellement.

Le problème spécifique des factures : les chiffres exacts n'ont pas de synonymes

Un document de politique RH, un contrat commercial ou un guide technique peuvent se résumer, se paraphraser, s'approximer. Une facture, non. Le montant HT est un nombre. La date d'échéance est une date. Le numéro de facture est un identifiant unique. La moindre imprécision dans la réponse crée une erreur comptable.

C'est fondamentalement différent de la plupart des cas d'usage RAG en entreprise. Un assistant IA interne sur de la documentation métier peut répondre "environ 3 semaines" à la question "quel est le délai de livraison standard ?". Personne ne va faire un rapprochement comptable sur cette réponse. Sur une facture, si le système répond "environ 12 400 euros" alors que le montant réel est 12 387,42 euros HT, le virement est faux.

Ce que veulent vraiment les comptables et les DAF

Après plusieurs déploiements sur ce cas d'usage, voici les requêtes qui reviennent systématiquement :

• Agrégats filtrés : "Total dépensé chez Fournisseur X par mois depuis janvier, ventilé par poste comptable"
• Rapprochements : "Quelles factures reçues cette semaine n'ont pas de bon de commande associé ?"
• Anomalies déterministes : "Y a-t-il des doublons de facturation sur ce trimestre ?"
• Questions ouvertes : "Quels fournisseurs ont un comportement de facturation inhabituel ce mois ?"
• Prévision : "À partir des échéances connues, quel est le besoin de trésorerie sur les 30 prochains jours ?"

Les quatre premières catégories nécessitent du SQL ou des règles déterministes. La dernière peut bénéficier d'un LLM pour synthétiser et expliquer. Un RAG pur rate les quatre premières. Un SQL pur rate la dernière. Il faut les deux.

Pourquoi le RAG seul ne suffit pas sur les données financières

Le RAG (Retrieval-Augmented Generation) est conçu pour retrouver des passages pertinents par similarité sémantique, puis générer une réponse en s'appuyant sur ces passages. C'est excellent pour les questions ouvertes sur du texte non structuré. Sur des factures, deux problèmes fondamentaux apparaissent.

Le problème de l'agrégation

Si je demande "quel est le total de mes achats chez Würth en 2024 ?", un RAG va chercher les passages contenant "Würth" et "2024", retrouver quelques factures, et tenter de sommer les montants qu'il voit dans le contexte. Il ne peut pas garantir d'avoir retrouvé toutes les factures Würth de 2024. Il ne peut pas non plus faire une somme arithmétique fiable sur un grand nombre de valeurs extraites de plusieurs documents.

SQL, lui, fait SELECT SUM(montant_ht) FROM factures WHERE fournisseur = 'Würth' AND YEAR(date_facture) = 2024 en moins d'une seconde, sur l'intégralité des enregistrements. C'est déterministe. C'est exact. C'est auditable.

Le problème de la confiance arithmétique

Les LLM peuvent halluciner des chiffres. Même les meilleurs modèles actuels commettent des erreurs d'arithmétique sur des sommes longues. Dans un contexte comptable, une réponse fausse avec un ton confiant est pire qu'une absence de réponse. Le responsable financier qui valide un virement sur la base d'un total hallucné engage sa responsabilité.

Ce n'est pas une critique de la technologie : c'est une question d'adéquation entre l'outil et le cas d'usage. Les LLM ne sont pas des calculatrices. Il ne faut pas les utiliser comme telles.

L'architecture hybride SQL + RAG : les deux couches et leur rôle

La bonne architecture sépare clairement ce que chaque technologie fait bien, puis les combine via un routeur intelligent.

Couche 1 : la base SQL structurée (source de vérité)

Chaque facture ingérée alimente une table structurée. Le schéma minimal que nous utilisons en production :

Les lignes de détail (description, quantité, prix unitaire, code analytique) sont dans une table factures_lignes liée par clé étrangère. Cette séparation permet les analyses par poste de dépense sans alourdir la table principale.

Couche 2 : l'index vectoriel (questions ouvertes)

En parallèle, chaque facture est indexée entière dans un index vectoriel (PgVector si vous êtes déjà sous PostgreSQL, Qdrant sinon). La facture est l'unité atomique d'indexation : on ne la découpe pas en chunks. Les lignes de détail constituent les sous-unités pertinentes si la facture est volumineuse.

Cet index répond aux questions que le SQL ne peut pas traiter : "quelles factures mentionnent des prestations de sous-traitance au sens large ?", "y a-t-il des factures de ce fournisseur avec des libellés inhabituels ?", "trouve-moi toutes les factures ayant trait aux travaux de ventilation du bâtiment B". Ces questions nécessitent une compréhension sémantique que le SQL ne possède pas.

Le routeur sémantique : qui répond à quoi

Un composant critique de l'architecture est le routeur qui analyse chaque question et décide du chemin de traitement. Les règles sont simples en pratique :

• Question contenant une opération d'agrégation (total, somme, nombre, moyenne, maximum) → SQL obligatoire
• Question avec filtre exact (fournisseur nommé, date précise, numéro de facture) → SQL + jointure
• Question ouverte ou sémantique ("suspecte", "inhabituel", "similaire à") → RAG + synthèse LLM
• Question mixte ("combien j'ai payé en moyenne, et est-ce normal pour ce secteur ?") → SQL pour le chiffre, RAG pour le contexte

Le LLM final reçoit le résultat SQL ou le résultat RAG (ou les deux) et produit une réponse en langage naturel vérifiable par l'utilisateur. On affiche toujours la requête SQL générée ou les sources RAG utilisées, pour que le comptable puisse auditer chaque réponse.

Pipeline d'ingestion : de la facture brute à la base structurée

L'ingestion est l'étape la plus critique. Une erreur d'extraction se propage dans toute la chaîne et corrompt les analyses en aval. Voici le pipeline que nous construisons.

Étape 1 : collecte et normalisation des formats

Une PME reçoit ses factures fournisseurs par plusieurs canaux :

• Email avec PDF en pièce jointe (80 % des cas)
• Portail fournisseur (téléchargement manuel ou API)
• EDI (EDIFACT ou UBL pour les grandes enseignes)
• Courrier physique scanné (encore 20 à 30 % dans l'industrie et le BTP)

Le pipeline commence par un déclencheur unifié : une boîte email dédiée, un dossier de surveillance, ou une connexion API au logiciel comptable (Pennylane, Cegid, Sage). Tous les formats arrivent dans une file de traitement unique.

Étape 2 : OCR sur les documents non natifs

Les PDF natifs (générés par un logiciel) contiennent le texte en clair : pas besoin d'OCR. Les PDF scannés, TIFF et JPG nécessitent une reconnaissance de caractères. La qualité de cette étape détermine 80 % de la qualité finale.

Notre recommandation selon le contexte :

• POC ou budget serré : Tesseract (gratuit, open source). Précision correcte sur les scans propres, insuffisante sur les tableaux multi-colonnes ou les scans de mauvaise qualité.
• Production standard : Mistral OCR ou Azure Document Intelligence. Précision nettement supérieure sur les mises en page complexes. Coût de l'ordre de 1 à 3 euros pour 1 000 pages.
• Données sensibles, contrainte souveraineté : AWS Textract sur une instance privée, ou un modèle OCR open source fine-tuné sur vos propres factures.

Étape 3 : extraction structurée par LLM

Une fois le texte disponible (PDF natif ou OCR), un LLM extrait les champs structurés. On utilise un prompt d'extraction avec sortie JSON forcée (mode response_format chez OpenAI ou format structuré chez Anthropic). Le LLM lit la facture entière et retourne :

{
  "numero_facture": "FAC-2024-08741",
  "fournisseur_nom": "Acier Service SAS",
  "siret": "49287361500023",
  "date_facture": "2024-10-15",
  "date_echeance": "2024-11-14",
  "montant_ht": 4280.00,
  "taux_tva": 20.0,
  "montant_tva": 856.00,
  "montant_ttc": 5136.00,
  "iban": "FR76 3000 4028 3798 7654 3210 943",
  "lignes": [
    {"description": "Tôle acier S235 2mm 1500x3000", "qte": 20, "pu_ht": 214.00}
  ],
  "confiance": 0.97
}

Étape 4 : validation règles métier

Avant tout enregistrement en base, trois contrôles automatiques :

• Vérification arithmétique : montant_ht × (1 + taux_tva/100) doit correspondre à montant_ttc à 0,02 euro près. Si l'écart dépasse ce seuil, la facture passe en file de relecture humaine.
• Contrôle doublon : hash SHA-256 du numéro de facture + fournisseur + montant. Si le hash existe déjà en base, alerte doublon.
• Contrôle IBAN : comparaison avec la liste blanche (voir section suivante).

Seules les factures passant tous les contrôles sont enregistrées avec le statut "validée". Les autres entrent dans une file de validation manuelle avec le motif de blocage. Aucune facture n'est perdue : elle est toujours tracée, même si elle est bloquée.

Détection de fraude IBAN : une alerte déterministe, pas un modèle

La fraude au faux fournisseur par changement d'IBAN est l'une des fraudes comptables les plus fréquentes en PME. Son mécanisme est simple : un attaquant (interne ou externe) fait modifier les coordonnées bancaires d'un fournisseur existant. Le virement suivant part sur le mauvais compte.

On voit parfois des projets qui veulent "détecter la fraude avec le LLM". C'est une erreur d'approche. Le LLM peut manquer un IBAN frauduleux s'il n'a pas été entraîné sur ce type de détection, ou à l'inverse déclencher des faux positifs sur des IBAN légitimes présentés différemment. Pour ce risque précis, la règle doit être déterministe et exhaustive.

Comment implémenter l'alerte IBAN

Le principe est simple. Chaque fournisseur a une table de ses IBAN validés, avec la date de validation et l'identité de la personne qui a autorisé chaque ajout :

• À l'ingestion de chaque facture, l'IBAN extrait est comparé exactement à la liste des IBAN validés pour ce fournisseur.
• Si l'IBAN est connu et validé : traitement normal.
• Si l'IBAN est nouveau ou différent du précédent : blocage immédiat du paiement automatique, alerte email au DAF et au dirigeant, log horodaté de l'événement.
• La validation d'un nouvel IBAN nécessite une confirmation double (deux personnes différentes, ou confirmation par appel téléphonique au fournisseur sur un numéro référencé).

Cette règle s'applique aussi aux modifications manuelles dans le système : toute mise à jour d'IBAN fournisseur dans la base déclenche la même procédure de validation. Le système maintient un journal immuable de tous les changements d'IBAN avec horodatage, auteur et adresse IP. C'est la seule ligne de défense fiable contre ce vecteur de fraude.

Les fonctions du copilote comptable

Une fois l'architecture en place, les fonctions déployées en production couvrent quatre grands domaines.

Recherche et interrogation analytique

L'interface de requête en langage naturel traduit les questions en SQL ou en RAG selon le routeur. Les réponses incluent systématiquement la requête générée ou les sources utilisées. Quelques exemples de questions traitées :

• "Donne-moi le top 10 de mes fournisseurs par montant facturé ce semestre, avec l'évolution vs semestre précédent."
• "Quelles factures du mois n'ont pas encore été rapprochées avec un bon de commande ?"
• "Y a-t-il des fournisseurs pour lesquels nous avons des factures en double sur l'exercice ?"
• "Montre-moi toutes les factures de sous-traitance dépassant 10 000 euros sans visa du directeur technique."

Alertes automatiques

Le système envoie des alertes configurables sur plusieurs événements :

• Facture dépassant un seuil de montant paramétrable (ex : toute facture supérieure à 5 000 euros déclenchée pour validation manuelle)
• Doublon détecté
• IBAN modifié (voir section précédente)
• Facture proche de son échéance sans paiement planifié (J-7, J-3, J-1)
• Écart arithmétique détecté à l'extraction
• Confiance d'extraction faible (score < 0.85 sur un champ critique)

Prévision de trésorerie court terme

À partir des dates d'échéance et des montants TTC enregistrés en base, le système calcule le besoin de décaissement par période. Une simple requête SQL agrège les factures non payées par semaine sur les 90 prochains jours. Le LLM commente le résultat, signale les pics inhabituels et compare avec les moyennes historiques. Ce n'est pas de la prédiction au sens machine learning : c'est de l'agrégation sur des données contractuelles déjà connues, et c'est souvent suffisant pour un dirigeant de PME.

Export et intégration comptable

Le système peut pousser les données extraites et validées vers le logiciel comptable via API (Pennylane, Cegid, Sage, MyUnisoft) ou via export CSV/FEC. L'injection automatique ne se fait que pour les factures ayant passé tous les contrôles. Les factures en exception restent dans la file de validation manuelle.

Conformité facture électronique B2B 2026 : comment l'architecture s'y prépare

La réforme française de la facturation électronique B2B impose depuis 2024-2026 (selon la taille de l'entreprise) l'émission et la réception de factures via des Plateformes de Dématérialisation Partenaires (PDP) immatriculées par la DGFiP, ou via Chorus Pro pour les marchés publics.

Ce que ça change concrètement

Pour les flux concernés, les factures arriveront au format structuré standardisé : Factur-X (PDF enrichi d'un XML embarqué) ou UBL 2.1 (XML pur). Ces formats contiennent tous les champs obligatoires en données lisibles par machine, sans ambiguïté de mise en page.

Pour l'architecture hybride décrite dans cet article, c'est une excellente nouvelle :

• L'étape OCR devient inutile pour ces flux : le XML est directement parsé.
• La qualité d'extraction passe à 100 % sur les champs standardisés.
• L'identifiant fournisseur (SIRET, numéro TVA intracommunautaire) est structuré et vérifiable automatiquement contre le répertoire Sirene.

Les entreprises qui construisent cette architecture aujourd'hui, avec un pipeline d'ingestion modulaire, n'auront qu'à ajouter un lecteur XML Factur-X/UBL en entrée. Celles qui auront attendu devront construire en urgence pendant que le flux PDP est déjà actif.

Les flux qui resteront non structurés

L'obligation ne couvre pas tous les cas. Les fournisseurs étrangers (hors UE), les associations, les microentreprises et certains secteurs spécifiques continueront à émettre des PDF non structurés pendant encore plusieurs années. L'OCR et le pipeline d'extraction LLM restent nécessaires pour ces flux résiduels.

Quelles stacks techniques, selon votre contexte

Trois configurations que nous déployons selon les contraintes du client.

Stack 1 : PostgreSQL + PgVector + GPT-4o (recommandée pour débuter)

PgVector intègre l'index vectoriel directement dans PostgreSQL. Une seule base de données gère le SQL structuré et les embeddings. Simplicité opérationnelle maximale. GPT-4o avec vision pour les factures scannées ou PDF images. Idéal si vous avez déjà une instance PostgreSQL en production. C'est la stack que nous choisissons pour 70 % de nos POC.

Stack 2 : LlamaIndex + Qdrant + Claude 3.7 Sonnet + Mistral OCR (volume plus élevé)

La séparation entre index structuré et index vectoriel améliore les performances à partir de quelques dizaines de milliers de factures. Qdrant excelle sur les recherches vectorielles à grande échelle. Claude 3.7 Sonnet pour la compréhension des factures ambiguës (formats étrangers, factures manuscrites, mises en page non standard). Mistral OCR pour une extraction française de qualité.

Stack 3 : Apache Tika + Elasticsearch + Mistral (on-premise souverain)

Pour les industriels ou les cabinets comptables qui ont une contrainte forte de souveraineté des données. Tika gère l'extraction multi-format (PDF natif, DOCX, XML EDI, HTML). Elasticsearch pour la recherche hybride (BM25 + vectorielle). Tout tourne sur votre infrastructure, aucune donnée ne sort. Coût d'infrastructure plus élevé, mais conformité RGPD maximale et zéro dépendance à un fournisseur cloud.

Les pièges fréquents sur ce type de projet

Quatre erreurs que nous observons régulièrement et qui font dérailler les projets.

Sous-estimer la variabilité des formats fournisseurs

Chaque fournisseur a son propre gabarit PDF : en-têtes différents, positions des champs variables, colonnes de détail dans des ordres différents. Un modèle d'extraction qui fonctionne parfaitement sur les 10 principaux fournisseurs peut échouer sur le 11ème qui a une mise en page atypique. Il faut prévoir un mécanisme de fallback (relecture humaine déclenchée par un score de confiance bas) et un processus d'amélioration continue au fur et à mesure que de nouveaux formats apparaissent.

Confondre RAG et outil de Business Intelligence

"Combien j'ai dépensé par catégorie ce trimestre ?" est une requête SQL, pas une requête RAG. Si vous construisez un RAG pur et que vous essayez de lui faire faire de la BI, vous obtiendrez des réponses approximatives sur des questions qui appellent des réponses exactes. Construisez l'index SQL en parallèle de l'index vectoriel dès le départ, même si ça complexifie légèrement l'architecture initiale.

Négliger la déduplication

2 à 5 % des factures reçues en PME sont des doublons (relance fournisseur, double envoi, re-facturation d'un avoir). Sans déduplication par hash, le RAG les indexe deux fois et les agrégats SQL sont faux. Pire, un doublon de facture payé deux fois peut générer un litige fournisseur compliqué à résoudre. Le contrôle de doublon doit être le premier contrôle à l'ingestion, avant même l'enregistrement en base.

Traiter l'audit trail comme une option

Dans un système comptable, toute modification de données doit être tracée. Qui a modifié quel champ, quand, depuis quelle session. Ce n'est pas une exigence technique optionnelle : c'est une exigence légale (durée de conservation des pièces comptables de 10 ans en France) et une condition sine qua non pour que l'expert-comptable ou le commissaire aux comptes fasse confiance au système. Construisez l'audit trail dès le POC, pas en fin de projet.

Coûts réels et délais de mise en production

Voici les fourchettes que nous observons en pratique, en dehors de tout discours commercial.

Ces fourchettes s'entendent pour une PME traitant entre 100 et 5 000 factures par mois. Ce qui rallonge systématiquement les délais :

• Qualité des scans : si 30 % des factures sont des photocopies de mauvaise qualité, le prétraitement OCR prend 3 semaines supplémentaires.
• Intégration ERP (SAP, Sage, Cegid) : les connecteurs sont souvent peu documentés, les tests d'intégration sont chronophages. Comptez 3 semaines de plus.
• Rapprochement bon de commande : si ce périmètre est inclus dès le départ, doubler la durée estimée.
• Historique à réingérer : 10 ans de factures papier à numériser et ingérer représente un projet en soi.

Pour une estimation plus précise sur votre contexte, les détails sur le coût d'un projet RAG de bout en bout sont dans cet article dédié, avec la décomposition poste par poste.

FAQ

Pour aller plus loin

• RAG en entreprise : tout comprendre sur la technologie : les bases du RAG expliquées pour un décideur, sans jargon.
• Coût d'un projet RAG : du POC à la production : fourchettes détaillées, postes de coût et TCO sur 1 an.
• Automatiser les factures par email avec Pennylane et l'IA : l'automatisation des flux entrants, côté logiciel comptable.
• n8n + Mistral pour les factures fournisseurs BTP : un workflow concret pour le secteur du bâtiment.
• Automatiser les relances de factures avec un agent IA : le pendant côté facturation clients.
• Assistant IA interne RAG sur données d'entreprise : le cas d'usage RAG dans sa version la plus générale.
• 5 erreurs qui font échouer les projets RAG : les pièges à éviter avant de lancer.
• Notre offre d'assistant IA interne RAG : ce que nous construisons concrètement pour nos clients.