Guide Peppol pour développeurs : BIS Billing, recherche SMP, AS4 et réponses

Peppol est un réseau à quatre coins : le logiciel de l'expéditeur (coin 1) remet un document à son point d'accès (coin 2), qui découvre le point d'accès du destinataire (coin 3) par une recherche DNS et SMP et livre via AS4 ; le coin 3 le transmet au logiciel du destinataire (coin 4). Pour un développeur, cela signifie trois problèmes distincts — produire un document Peppol BIS Billing 3.0, l'adresser avec le bon identifiant de participant, et obtenir qu'un prestataire de point d'accès accrédité le transporte. KRONENWERK résout lui-même les deux premiers et délègue le troisième à Storecove, un prestataire de point d'accès accrédité.

BIS Billing 3.0, c'est EN 16931 avec les contraintes de Peppol

Peppol BIS Billing 3.0 est une Core Invoice Usage Specification (CIUS) de EN 16931 : chaque document conforme au BIS est aussi conforme à la norme européenne, et le BIS ajoute les exigences dont le réseau a besoin pour router et traiter une facture. La publication actuelle au moment de la lecture est la version 3.0.21 (mise à jour de mai 2026). Elle lie le modèle sémantique aux documents UBL 2.1 Invoice et CreditNote ; CII n'est pas utilisé sur Peppol pour la facturation.

Les identifiants qui font d'un fichier UBL une facture Peppol BIS sont des chaînes fixes :

Au-delà des règles du noyau, le BIS exige les adresses électroniques du vendeur et de l'acheteur (cbc:EndpointID avec un schemeID), une référence acheteur ou une référence de bon de commande, des moyens de paiement avec un code, et une poignée de contraintes de format. Celles-ci sont appliquées par le Schematron Peppol (PEPPOL-EN16931-UBL.sch) sous forme de règles nommées PEPPOL-EN16931-Rxxx, par-dessus les règles du CEN (CEN-EN16931-UBL.sch). Les règles du noyau elles-mêmes sont expliquées dans le guide développeur EN 16931.

Identifiants de participant

Un participant Peppol est adressé par un schéma et une valeur, écrits schéma:valeur — par exemple 0208:0123456789 pour un numéro d'entreprise belge ou 0204: suivi d'une Leitweg-ID pour un acheteur public allemand. Les codes de schéma proviennent de la liste ISO 6523 International Code Designator telle que maintenue dans la Policy for use of Identifiers d'OpenPeppol (version 4.4.0, valable à partir du 1er novembre 2025 au moment de la lecture). Le même identifiant apparaît à trois endroits, et ils doivent concorder :

1. Dans le document UBL, comme cac:AccountingCustomerParty/cac:Party/cbc:EndpointID schemeID="0208" (BT-49) et l'équivalent pour le vendeur (BT-34).
2. Dans l'enveloppe (SBDH) comme identifiants d'expéditeur et de destinataire, avec le schéma d'identifiant iso6523-actorid-upis.
3. Dans l'entrée SMP du destinataire, là où la recherche a lieu.

Le schéma qu'utilise une entreprise donnée dépend de son pays et de ce qu'elle a enregistré. La Belgique s'enregistre sous 0208 (numéro d'entreprise), le secteur public allemand sous 0204, et des schémas fondés sur la TVA tels que 9925 (BE:VAT) ou 9930 (DE:VAT) existent en parallèle. Les schémas d'identifiants, leurs formats et la manière de trouver l'identifiant enregistré d'un partenaire sont traités dans identifiants Peppol ; l'outil d'identifiant Peppol gratuit vérifie le format d'une valeur.

Découverte : SML, DNS et SMP

Peppol n'a pas d'annuaire central qu'un expéditeur interroge. Le point d'accès expéditeur trouve dynamiquement le endpoint du destinataire :

1. Hacher l'identifiant de participant. La spécification SML actuelle (1.3.0) utilise un enregistrement U-NAPTR : la valeur de l'identifiant est mise en minuscules, hachée en SHA-256, encodée en Base32 avec les « = » finaux supprimés, et préfixée au schéma et à la zone SML. L'ancienne forme CNAME avec un hachage MD5 et un préfixe « B- » a été retirée du SML exploité par la Commission lors d'un nettoyage en février–mars 2026.
2. Le résoudre dans la zone SML. Le Service Metadata Locator est une zone DNS qui associe chaque participant haché au SMP hébergeant ses métadonnées. La réponse NAPTR porte l'URL du SMP.
3. Interroger le SMP. Le Service Metadata Publisher répond à deux appels REST : GET /{participantId} liste les types de documents que le participant peut recevoir, et GET /{participantId}/services/{documentTypeId} renvoie le endpoint pour l'un d'eux — l'URL AS4, l'identifiant de profil de transport, le certificat du destinataire et l'identifiant de processus. La spécification SMP en vigueur est la 1.4.0.
4. Livrer. Le point d'accès expéditeur chiffre et signe le message pour ce certificat et le poste à cette URL.

Le SML a déménagé en 2026. OpenPeppol a internalisé le localisateur depuis l'infrastructure eDelivery de la Commission : la production est passée de edelivery.tech.ec.europa.eu à api.sml.prod.tech.peppol.org, et le SML de test (anciennement SMK, acc.edelivery.tech.ec.europa.eu) à api.sml.test.tech.peppol.org. Les opérateurs de SMP devaient migrer leurs enregistrements avant le 31 mai 2026 et les points d'accès devaient basculer leurs recherches DNS avant le 31 août 2026. Les recherches de participants se résolvent sous iso6523-actorid-upis.participant.sml.prod.tech.peppol.org (production) et …sml.test.tech.peppol.org (test).

Transport : AS4 via un point d'accès

Les messages circulent entre points d'accès selon le profil Peppol AS4 (version 2.0.3, valable à partir du 22 avril 2024), un échange ebMS3/AS4 avec signature et chiffrement fondés sur des certificats délivrés par la PKI d'OpenPeppol. Seuls les points d'accès accrédités détiennent ces certificats : pour en devenir un, une organisation signe le Peppol Transport Infrastructure Agreement, passe les tests de conformité et opère selon les règles de niveau de service d'OpenPeppol. C'est pourquoi la plupart des éditeurs de logiciels, KRONENWERK compris, utilisent un prestataire plutôt que d'exploiter un point d'accès.

Le document métier est enveloppé dans un Peppol Business Message Envelope (SBDH, spécification 2.0.2, en vigueur depuis le 2 juillet 2026), qui porte l'expéditeur, le destinataire, l'identifiant de type de document, l'identifiant de processus et un identifiant d'instance. L'enveloppe est ce sur quoi le point d'accès route ; l'UBL à l'intérieur est ce que lit le logiciel du destinataire. Lorsque vous intégrez l'API d'un prestataire de point d'accès, le prestataire construit généralement l'enveloppe à partir de quelques paramètres et vous ne fournissez que l'UBL et l'identifiant du destinataire.

Validation et environnement de test

Un point d'accès expéditeur valide chaque document contre le Schematron Peppol avant transmission et rejette les échecs. Validez d'abord de votre côté avec les mêmes artefacts : CEN-EN16931-UBL.sch et PEPPOL-EN16931-UBL.sch, téléchargeables depuis la documentation BIS Billing 3.0, exécutés avec n'importe quel processeur Schematron ou avec le scénario Peppol du validateur KoSIT. Les identifiants de règles PEPPOL-EN16931-R001 et suivants nomment les échecs propres à Peppol ; BR-xx et BR-CO-xx nomment ceux du noyau.

Pour les tests de bout en bout, OpenPeppol exploite un réseau de test avec son propre SML (le T-SML), sa propre PKI et des identifiants de participants de test. Les prestataires de point d'accès l'exposent comme un sandbox : les documents envoyés là ne sont livrés qu'à des participants de test et n'atteignent jamais un vrai destinataire. Le réseau de test Peppol est le bon endroit pour éprouver votre gestion des identifiants et votre enveloppe avant la première facture de production ; un document qui se valide mais est adressé à un identifiant que le destinataire n'a jamais enregistré n'échoue qu'au moment de la recherche, et c'est ce que le réseau de test vous montre.

Réponses : niveau message et niveau facture

Deux types de retour existent, et un expéditeur devrait traiter les deux.

Accusé de transport

L'accusé AS4 signé du point d'accès destinataire prouve que le message est arrivé au coin 3. Il ne dit rien du contenu.

Message Level Response (MLR, BIS 3.0)

Un ApplicationResponse UBL renvoyé à l'expéditeur par le point d'accès destinataire ou le destinataire, rapportant le résultat de la validation : AP accepté (aucune erreur fatale), RE rejeté (violations de conformité, le traitement s'arrête), AB accusé de réception sans validation. Un destinataire qui trouve des erreurs fatales devrait rejeter via MLR même si aucun n'a été demandé.

Invoice Response (BIS 3.2)

Une réponse au niveau métier de l'acheteur — acceptée, rejetée, payée, acceptée sous condition — utilisée dans le profil « facturation avec réponse » (billing:02). Facultative, et adoptée de manière inégale.

En pratique : traitez un accusé AS4 manquant comme non livré, un MLR RE comme un défaut de document à corriger et renvoyer, et une Invoice Response comme un événement métier à montrer à une personne.

Comment KRONENWERK abstrait cela

PRIS EN CHARGE AVEC LIMITATIONS KRONENWERK génère à l'émission du Peppol BIS Billing 3.0 UBL pour les factures belges, avec l'identifiant de participant du client inscrit dans le document et validé contre les Schematron Peppol et CEN avant que le numéro de facture soit consommé. KRONENWERK n'est pas un point d'accès Peppol. Il envoie et reçoit via Peppol par l'intermédiaire d'un prestataire de point d'accès accrédité (Storecove) une fois l'entreprise connectée dans Paramètres → Envoi ; la découverte, l'enveloppe, le transport AS4 et les accusés sont réalisés par ce prestataire, et l'envoi en production dépend de ce compte et de sa configuration. Les factures UBL entrantes reçues via le prestataire sont lues en factures fournisseurs. KRONENWERK ne contient aucun client DNS ou SMP propre, par conception : la migration SML de 2026 n'a rien exigé de KRONENWERK parce que la recherche n'a jamais été son rôle.

Via l'API, un développeur crée le brouillon (POST /invoices/drafts) et lit la facture émise (GET /invoices/{number}) ; l'émission, la validation et l'envoi ont lieu dans le produit, et le webhook invoice.issued signale l'émission. Il n'existe aucun endpoint qui dépose de l'UBL brut, recherche un participant ou renvoie un MLR. Ce que l'API peut et ne peut pas faire autour de Peppol est décrit dans intégration Peppol ; le contexte plus large se trouve sur la page Peppol et envoyer et recevoir, et l'obligation belge sur le hub Belgique et la page pays.