ediverse

Tapez pour rechercher dans les standards, messages, outils et glossaire.

ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

— 01

Fondamentaux

— 02

Standards

— 03

Messages phares

— 04

Outils

Validation Pipeline

Quatre étages de validation, quatre familles d'erreur, quatre réponses distinctes — le pattern qui rend les erreurs partenaires actionnables.

Problème

Un hub EDI reçoit un INVOIC qui rejette. Le rejet dit « message invalide ». Mais : est-ce que la structure EDIFACT est cassée ? Un qualifier inconnu ? Une règle métier (« la facture référence une commande inexistante ») ? Une contrainte spécifique Walmart (« le numéro de fournisseur doit faire 9 digits ») ? Sans distinction, l'opérateur en support EDI ne sait pas quel acteur prévenir (fournisseur partenaire ? équipe métier interne ? IT du partenaire ?). Le traitement est indifférencié : tout va en DLC, on perd 4h à diagnostiquer.

Forces

  • Les erreurs ont des sources différentes. Bug logiciel partenaire, malentendu métier, IG partenaire mal lu, donnée incohérente.
  • Les traitements diffèrent. Erreur syntaxique → relance technique. Erreur métier → escalade business. Erreur IG → coordination partenaire.
  • Les ACK différents existent. CONTRL (syntaxique EDIFACT), APERAK (applicatif EDIFACT), 999 (X12 implementation), 824 (X12 application advice), NRR (AS4).
  • L'ordre des validations compte. Inutile de vérifier le business si la syntaxe est cassée.

Solution

Construire un pipeline ordonné à quatre niveaux. 1. Syntactic : conformité au schéma (EDIFACT message definition, XSD UBL, X12 transaction set). 2. Semantic : validité des codes et qualifiers (Schematron sur UBL, EN 16931 BR-CO rules, table UN/EDIFACT). 3. Business : règles applicatives (référence à une PO existante, doublon de facture, montant cohérent avec lignes). 4. Partner : Implementation Guide partenaire (Walmart custom rules, PEPPOL country profile). Chaque échec produit un ACK approprié et un événement typé. Le pipeline s'arrête au premier échec — pas la peine de tester l'IG sur une syntaxe cassée. 

Message reçu (INVOIC EDIFACT, X12 810, UBL Invoice)
        │
        ▼
  ┌────────────────────────────────┐
  │ 1. Syntactic validation        │
  │    schéma D.96A / XSD UBL      │
  │    structure, types, requis    │
  └──────┬─────────────────────────┘
   échec │ → CONTRL négatif / 999 / NRR fault  → DLC technique
   ok    ▼
  ┌────────────────────────────────┐
  │ 2. Semantic validation         │
  │    qualifiers, codes, énum     │
  │    Schematron, EN 16931 rules  │
  └──────┬─────────────────────────┘
   échec │ → APERAK / 824           → DLC sémantique
   ok    ▼
  ┌────────────────────────────────┐
  │ 3. Business validation         │
  │    règles métier (cohérence,   │
  │    duplicates, autorisation)   │
  └──────┬─────────────────────────┘
   échec │ → APERAK + escalade      → exception flow
   ok    ▼
  ┌────────────────────────────────┐
  │ 4. Partner validation          │
  │    Walmart IG, Stellantis      │
  │    spécifique, codes propres   │
  └──────┬─────────────────────────┘
   échec │ → fonctionnel partenaire → workflow partner
   ok    ▼
  Message accepté → broker événements

Implémentation EDI

Cas concret : hub Factur-X reçoit une facture électronique. Étape 1 — XSD UBL 2.1 valide la structure XML, retourne OperationOutcome structuré FHIR-like si fail. Étape 2 — Schematron EN 16931 (BR-CO-01 à BR-CO-25, BR-DE-XX pour l'Allemagne, BR-FR-XX pour la France via Factur-X) : cohérence taxe/total, format SIRET, devise CE valide. Étape 3 — règles métier internes : « la PO référencée existe en base », « pas déjà facturé », « montant cohérent avec ASN reçue ». Étape 4 — IG spécifique : pour Walmart, GS06 doit être l'EIN ; pour PEPPOL FR, IBAN obligatoire. Chaque étape émet : InvoiceSyntacticallyValid, InvoiceSemanticallyValid, InvoiceBusinessValid, InvoicePartnerValid, ou les variantes échec typées. L'opérateur ops a un dashboard par étage : il sait à la seconde si on a un problème EN 16931 (équipe interne) ou un problème custom Walmart (à escalader chez le partenaire). Outils pour étape 2 : Saxon-EE Schematron, OpenAPI KoSIT validator (référence EN 16931), peppol-validator.

Anti-patterns

  • Validation monolithique. « Le message est valide ou non » : aucun diagnostic, opérateur perdu.
  • Validation business en étape 1. Tester « la PO existe » sur un message dont la syntaxe est cassée : faux positifs, faux négatifs.
  • Erreur 500 au lieu d'ACK négatif. Le partenaire ne sait pas que la validation a échoué — il croit que le hub est down.
  • Validation sans versionning. Une règle EN 16931 change en 2027, on perd les vieux messages valides 2025. Versionner les pipelines.
  • Validation qui suit l'enrichissement. Si on enrichit avant de valider, on consomme des ressources sur des messages destinés à être rejetés. Valider d'abord (au moins étapes 1+2).

Patterns liés

Sources