Tester ses pipelines EDI : stratégies et outils

Les chaînes EDI ont longtemps été testées par couches métier en pré-production chez les partenaires, avec des cycles de mois. En 2026, on peut faire mieux : fixtures versionnées, mocks d'access point, validation en CI, contract testing. Cette page rassemble les stratégies qui marchent vraiment.

Pourquoi tester une chaîne EDI est différent

Tester une API REST interne est un exercice bien outillé : vous écrivez des tests unitaires sur les contrôleurs, des tests d'intégration contre une base de test, et des tests E2E avec Playwright ou Cypress. Tout est local, reproductible, rapide.

Tester une chaîne EDI ajoute trois difficultés. Le partenaire est externe et hors de votre contrôle — vous ne pouvez pas l'invoquer en CI sans coût et sans risque. Les formats sont rigides (EDIFACT D.96A, X12 850, PEPPOL BIS Billing 3.0) et leur validité est binaire : une virgule de trop fait échouer tout le pipeline. Les bugs se manifestent en différé : un mauvais mapping cause un rejet 24h plus tard, pas immédiatement.

La discipline de test doit donc compenser ces trois propriétés : enfermer le partenaire derrière un mock, formaliser le contrat de format en fixtures, et raccourcir la boucle de feedback à quelques secondes en CI.

Fixtures EDI — la base

Le socle de tout est un répertoire de fixtures : des messages EDI réels (ou réalistes), versionnés dans le repo, qui couvrent les cas typiques. Structurer ce répertoire est crucial. Une organisation qui marche bien :

tests/fixtures/edifact/d96a/orders/valid/single-line.edi
tests/fixtures/edifact/d96a/orders/valid/multi-line.edi
tests/fixtures/edifact/d96a/orders/valid/with-charges.edi
tests/fixtures/edifact/d96a/orders/invalid/missing-bgm.edi
tests/fixtures/edifact/d96a/orders/invalid/bad-currency.edi
tests/fixtures/peppol/bis-billing-3/invoice/valid/simple-fr.xml
tests/fixtures/peppol/bis-billing-3/invoice/valid/with-allowances.xml

Chaque fixture est accompagnée d'un fichier d'attente .expected.json (ou .expected.txt) qui décrit ce que le parser ou le mapper doit produire. Le test compare le résultat actuel à l'attendu et échoue en CI en cas de divergence. C'est l'application directe du pattern golden file testing à l'EDI.

Mocks de partenaire

Aucun test CI ne doit appeler un vrai partenaire externe. La règle d'or. Pour simuler le partenaire, on utilise un mock — un service local qui rejoue les réponses attendues. Pour les flux EDI typiques :

• Mock AS2/AS4 : un endpoint HTTPS local qui accepte les POST AS2/AS4 et retourne un MDN ou un receipt signé attendu. Bibliothèques utiles en 2026 : Open-AS2 (Java), node-as2 (Node.js), ou des images Docker prêtes pour test (cef-edelivery-test côté AS4).
• Mock SFTP : serveur SFTP local en CI (atmoz/sftp Docker), avec un répertoire pré-configuré et des fichiers attendus.
• Mock PEPPOL access point : pour le développement, soit on utilise l'OpenPeppol Test Network (réseau parallèle réservé aux tests et aux access points en cours de certification), soit un access point mock local.

L'intérêt : les tests tournent en quelques secondes, hors connexion, et sont reproductibles à 100 %. Le coût : maintenir la fidélité du mock par rapport au vrai partenaire — un mock obsolète peut masquer un bug réel.

Sandbox des access points PEPPOL

Au-delà des mocks locaux, la plupart des access points PEPPOL commerciaux exposent un environnement sandbox en plus de leur production. La sandbox accepte les soumissions de test, les valide, et simule la livraison vers un destinataire test sans toucher le vrai réseau PEPPOL. Stedi, Pagero, B2Brouter, Ibanity proposent tous une sandbox publique avec API key dédiée.

Le pattern recommandé : chaque environnement (dev, staging, prod) configure son propre couple API key + access point : dev→mock local, staging→sandbox access point, prod→production access point. Les secrets sont gérés via le gestionnaire de secrets de la plateforme cloud (AWS Secrets Manager, GCP Secret Manager, Vault).

Le réseau PEPPOL Test Network (TEST), opéré par OpenPeppol, sert pour les tests inter-access-points. Il fonctionne sur un SML test et des certificats test signés par une CA test PEPPOL. Toute soumission y est marquée et n'a pas de valeur juridique.

Validation Schematron et XSD en CI

Pour les flux UBL/PEPPOL, l'enjeu de test le plus puissant est la validation Schematron et XSD intégrée à la CI. À chaque commit, le pipeline GitHub Actions (ou GitLab CI, ou Jenkins) valide les fixtures contre les artefacts officiels d'OpenPeppol : PEPPOL-EN16931-UBL.sch, CEN-EN16931-UBL.sch, et le XSD UBL 2.1.

L'outil pratique : Saxon HE (gratuit) pour exécuter le Schematron en XSLT, plus xmlstarlet ou xmllint pour le XSD. Le tout enveloppé dans un script bash exécuté en CI. Quand OpenPeppol publie une nouvelle version du Schematron (typiquement deux fois par an), on met à jour le pipeline et on relance la CI ; les fixtures qui ne passent plus sont autant de cas à corriger.

Pour les flux EDIFACT, le validateur ediverse — la page Validateur EDIFACT — est intégrable en CI via son API REST. On envoie un message, on récupère la liste des erreurs, on vérifie qu'elle est vide pour les fixtures valides et qu'elle contient l'erreur attendue pour les fixtures invalides.

Contract testing des mappings

Le pattern contract testing applique à l'EDI ce que Pact a apporté aux microservices : figer un contrat entre deux extrémités, et tester l'extrémité de manière isolée. Pour un mapping EDIFACT→JSON ERP interne, le contrat est un fichier de spec qui dit : « ce segment BGM avec qualifier 220 doit donner le champ orderNumber dans le JSON ».

Implémentation typique : une suite de cas paramétrés. Pour chaque cas, on fournit la fixture entrée (EDIFACT) et le JSON attendu sorti. Le test exécute le mapper et compare. Cette suite tourne en quelques secondes et garantit qu'une régression de mapping est attrapée avant la mise en prod.

Pour les mappings bidirectionnels — EDIFACT ↔ JSON, ou UBL ↔ Factur-X, ou HL7 v2 ↔ FHIR — on teste les deux sens : aller-retour doit être idempotent à des conventions près (encodage des dates, séparateurs). Cette propriété, le roundtrip property test, attrape une catégorie particulière de bugs invisibles autrement.

Tests end-to-end et environnements

Au sommet de la pyramide, les tests E2E couvrent la chaîne complète : génération depuis l'ERP, validation locale, soumission à l'access point sandbox, réception de l'accusé, lecture par le destinataire test. Ces tests sont lents (minutes à heures) et fragiles (dépendent d'environnements externes), donc on les réserve aux smoke tests en staging après chaque déploiement, pas à chaque PR.

Les environnements à organiser :

• dev : 100 % local, mocks, pas de réseau externe. Tests unitaires + contract tests + Schematron CI. <1 min.
• staging : access points sandbox, partenaires de test fictifs. Smoke tests E2E quotidiens, déclenchés à chaque déploiement staging. <15 min.
• prod : vrais partenaires, vrais montants, vraie TVA. Aucun test automatisé n'écrit en prod sans coordination préalable avec le partenaire.

Pour aller plus loin

• Validateur EDIFACT — utilisable en CI via son API REST.
• Validateur PEPPOL — pour les flux UBL/EN 16931.
• Catalogue Patterns — Dead Letter Channel, Circuit Breaker et leurs équivalents test.
• Patterns EDI 2026 — l'article de fond sur les patterns testables.