Facturation Électronique Peppol & Knowledge Graph : Guide Pratique d'Ingestion avec n8n, Peppyrus et Neo4j

Le Nouveau Paradigme de la Facturation B2B : Adieu le PDF

Avec la généralisation progressive de l'obligation de facturation électronique inter-entreprises en Europe (notamment en Belgique et en France), le traditionnel fichier PDF envoyé par e-mail devient obsolète.

La norme européenne Peppol BIS Billing 3.0 repose sur un format structuré universel : le XML UBL 2.1 (Universal Business Language). Contrairement à un document PDF scanné qui nécessite des outils d'OCR probabilistes et coûteux, une facture Peppol contient des données 100 % déterministes, typées et validées par des règles strictes (Schematron).

Dans ce guide technique complet, nous vous détaillons l'architecture déployée par DAGAL pour orchestrer l'ingestion en temps réel des factures Peppol, leur dédoublonnage cryptographique et leur structuration dans un Knowledge Graph Neo4j.

---

1. Vue d'Ensemble de l'Architecture

L'architecture se compose de trois couches souveraines complémentaires :

---

2. Étape 1 : Récupération des Messages via l'API Peppyrus

Le point d'accès (Access Point) Peppol expose une API REST sécurisée par en-tête d'authentification. Pour interroger la boîte de réception et récupérer les 50 derniers messages :

GET https://api.peppyrus.be/v1/message/list?limit=50
X-Api-Key: VOTRE_CLE_API_SECURISEE
Accept: application/json

La réponse JSON contient la liste des transactions avec leur statut (DELIVERED, ACCEPTED), le sens du flux (IN pour les factures reçues, OUT pour les factures émises) et l'identifiant unique de chaque message permettant de télécharger son contenu XML.

---

3. Étape 2 : Parsing du XML UBL 2.1 & Extraction Fiscale

Une facture Peppol BIS 3.0 type est un document XML hiérarchisé contenant l'ensemble des métadonnées commerciales et comptables :

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomizationID>
  <cbc:ID>FACT-2026-0042</cbc:ID>
  <cbc:IssueDate>2026-08-12</cbc:IssueDate>
  <cbc:DueDate>2026-09-12</cbc:DueDate>
  
  <!-- Fournisseur & Client -->
  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:PartyName><cbc:Name>Fournisseur Conseil & Cloud</cbc:Name></cac:PartyName>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>BE0123456789</cbc:CompanyID>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:PartyTaxScheme>
    </cac:Party>
  </cac:AccountingSupplierParty>

  <!-- Ligne de prestation -->
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="DAY">3.00</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">2400.00</cbc:LineExtensionAmount>
    <cac:Item>
      <cbc:Name>Consulting Architecture Cloud & Graphe</cbc:Name>
      <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>21.00</cbc:Percent>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
  </cac:InvoiceLine>
</Invoice>

Dans n8n, nous utilisons un nœud de code JavaScript pour extraire :

---

4. Étape 3 : Dédoublonnage Déterministe par Empreinte SHA-256

Un problème classique dans les architectures de synchronisation récurrente est la génération de doublons lorsque la même facture est lue plusieurs fois.

Pour résoudre ce défi sans état lourd, nous calculons une empreinte cryptographique SHA-256 unique basée sur les attributs immuables de la facture :

// Calcul du hash déterministe dans le nœud n8n Code
const crypto = require('crypto');

const rawFingerprint = `${supplierVat}|${invoiceNumber}|${issueDate}|${totalTtc}`;
const invoiceHash = crypto.createHash('sha256').update(rawFingerprint).digest('hex');

Grâce à cette signature déterministe, même si la facture est reçue en double ou envoyée en test vers soi-même, son nœud dans la base de données reste strictement unique.

---

5. Étape 4 : Modélisation & Ingestion dans Neo4j

Le stockage dans un Knowledge Graph offre un avantage décisif sur une base SQL classique : il permet de cartographier naturellement les réseaux de tiers, de fournisseurs récurrents et de lignes d'achats pour alimenter des agents de recherche sémantique (GraphRAG).

Le Modèle Graphe Déployé

Requête Cypher d'Upsert Transactionnel

// 1. Fusionner la facture de manière idempotente
MERGE (i:Invoice {hash: $invoice.hash})
ON CREATE SET 
  i.number = $invoice.number,
  i.issue_date = date($invoice.issueDate),
  i.due_date = date($invoice.dueDate),
  i.total_ht = $invoice.totalHt,
  i.total_tva = $invoice.totalTva,
  i.total_ttc = $invoice.totalTtc,
  i.currency = $invoice.currency,
  i.direction = $invoice.direction,
  i.created_at = datetime()
ON MATCH SET
  i.last_synced = datetime()

// 2. Fusionner le Fournisseur et le Client
MERGE (supplier:Company {vat: $invoice.supplierVat})
ON CREATE SET supplier.name = $invoice.supplierName
MERGE (supplier)-[:EMET]->(i)

MERGE (customer:Company {vat: $invoice.customerVat})
ON CREATE SET customer.name = $invoice.customerName
MERGE (i)-[:DESTINE_A]->(customer)

// 3. Fusionner les lignes de facture
WITH i
UNWIND $invoice.lines AS line
MERGE (l:LineItem {id: i.hash + "_" + line.id})
SET 
  l.description = line.description,
  l.quantity = line.quantity,
  l.amount_ht = line.amountHt,
  l.vat_rate = line.vatRate
MERGE (i)-[:CONTIENT_LIGNE]->(l)

---

6. Quels Bénéfices Concrets pour une PME ou Startup ?

---

Conclusion : Réussir votre Transition Numérique

L'obligation de la facturation électronique Peppol ne doit pas être subie comme une contrainte administrative, mais saisie comme un levier stratégique pour moderniser et automatiser vos processus métier.

Chez DAGAL, nous concevons et déployons ces architectures sur mesure pour les dirigeants et équipes qui souhaitent gagner un temps précieux tout en garantissant la souveraineté de leurs données.