Le Service Metadata Publisher (SMP) est l'annuaire du réseau Peppol. Lorsqu'un Access Point (AP) envoie un document, il utilise le Participant Identifier du destinataire pour trouver -- via le Service Metadata Locator (SML) et le Domain Name System (DNS) -- auprès de quel SMP le destinataire est enregistré, quelle URL d'endpoint appeler et quels types de documents sont pris en charge. Cet article décrit la chaîne de découverte étape par étape.

Peppol est un réseau ouvert : il n'existe pas de boîte aux lettres centrale qui reçoit et distribue tous les documents. Chaque prestataire de services certifié gère son propre SMP avec les métadonnées de ses clients -- quels documents ils peuvent recevoir, via quel AP et avec quels certificats ils signent. L'AP expéditeur doit déterminer où livrer le document avant chaque envoi, et utilise pour cela le SMP du destinataire.

La spécification SMP est une norme de l'Organization for the Advancement of Structured Information Standards (OASIS). eConnect figure sur la liste des solutions conformes eDelivery SMP de la Commission européenne avec sa propre implémentation.

Chaque organisation sur Peppol possède au moins un Participant Identifier, composé d'un scheme et d'une value :

iso6523-actorid-upis::<scheme>:<value>

Le scheme est un code de la liste de codes Electronic Address Scheme (EAS) -- un registre OpenPeppol de systèmes d'identification nationaux et internationaux. Les codes EAS les plus utilisés :

Un aperçu complet est disponible sur docs.peppol.eu/edelivery/codelists/ et dans ID Peppol et identifiants.

L'AP expéditeur répond à trois questions pour chaque document :

1. Où se trouve le SMP du destinataire ? Lookup via SML / DNS NAPTR.
2. Quel endpoint et quel certificat correspondent au type de document souhaité ? Lookup contre le SMP lui-même.
3. Quel profil Peppol le destinataire prend-il en charge ? La réponse se trouve dans la réponse SMP (BIS Billing V3, NLCIUS, PINT EU, etc.).

B-<md5>.iso6523-actorid-upis.edelivery.tech.ec.europa.eu

B-<md5>.iso6523-actorid-upis.edelivery.tech.ec.europa.eu
   IN NAPTR 100 10 "U" "Meta:SMP" "!^.*$!https://smp.example.com/!" .

GET https://smp.example.com/iso6523-actorid-upis%3A%3A0106%3A54441587

GET https://smp.example.com/iso6523-actorid-upis%3A%3A0106%3A54441587/services/<DocumentTypeId>

L'illustration end-to-end ci-dessous montre comment un Participant Identifier néerlandais (numéro KvK) mène à une URL d'endpoint concrète :

1. L'expéditeur veut envoyer une facture à :
   iso6523-actorid-upis::0106:54441587  (eConnect, EAS 0106 -- KvK)

2. L'AP expéditeur effectue un lookup DNS NAPTR :
   B-<md5>.iso6523-actorid-upis.edelivery.tech.ec.europa.eu
   --> URL SMP : https://smp.econnect.eu/

3. L'AP expéditeur interroge le SMP :
   GET https://smp.econnect.eu/iso6523-actorid-upis%3A%3A0106%3A54441587
   --> ServiceGroup avec notamment le DocumentTypeId pour la facture NLCIUS

4. L'AP expéditeur interroge les ServiceMetadata pour NLCIUS :
   GET https://smp.econnect.eu/iso6523-actorid-upis%3A%3A0106%3A54441587/services/<NLCIUS-DocumentTypeId>
   --> EndpointURI : https://ap.econnect.eu/as4
   --> Certificate : <X.509 / cert. PKI>
   --> TransportProfile : peppol-transport-as4-v2_0

5. L'AP expéditeur construit le SBDH avec les métadonnées de routage,
   signe et envoie via AS4 + TLS à l'EndpointURI.

Lors de l'enregistrement dans un SMP, des capabilities par famille de documents sont configurées par organisation :

Chaque capability a une valeur on, off ou inherited. L'ensemble complet des capabilities détermine quels types de documents l'AP expéditeur peut trouver dans le SMP -- et donc pour quoi un destinataire est effectivement joignable.

Les lookups SMP sont effectués à chaque envoi. Pour la montée en charge et la robustesse, le SMP eConnect applique sa propre couche de mise en cache : les lookups restent disponibles -- même si un SMP externe est temporairement inaccessible -- en réutilisant les métadonnées en cache dans la période de validité. eConnect garantit 99,99 % de disponibilité sur le SMP.

Deux termes similaires souvent confondus en pratique :

• Le SML (Service Metadata Locator) est la zone DNS centrale (edelivery.tech.ec.europa.eu pour la production) dans laquelle tous les Participant Identifiers sont publiés et qui pointe vers le SMP approprié. Il existe un SML de production et un SML de test ; OpenPeppol reprend la gestion de la Commission européenne (transition jusqu'à fin août 2026).
• Le SMP (Service Metadata Publisher) est le répertoire d'un prestataire de services individuel. Chaque SP exploite son propre SMP pour ses propres clients.

Analogie avec le DNS : le SML est l'annuaire de premier niveau qui renvoie au bon annuaire régional ; le SMP est cet annuaire avec les données réelles.

Un Participant Identifier ne peut être enregistré qu'auprès d'un seul SMP à la fois -- sinon C2 ne saurait pas où envoyer le document. En cas de changement de prestataire, une procédure de migration avec une clé de migration s'applique : le SMP actuel génère une clé, et le nouveau SMP l'utilise pour reprendre l'enregistrement de manière transparente. Pendant la transition, l'organisation reste joignable ; l'identifiant ne change pas, de sorte que les partenaires commerciaux ne remarquent rien.

En plus du SMP lisible par machine, deux interfaces publiques permettent des recherches manuelles :

• Peppol Directory -- directory.peppol.eu : le registre public des participants Peppol, avec recherche par nom d'organisation, pays et Participant ID. Asynchrone et peu fiable pour les vérifications d'accessibilité : le Directory récupère périodiquement ses données auprès des SMP et le service Directory est parfois temporairement indisponible. Par conséquent, une inscription ou une désinscription peut apparaître dans le Directory avec un délai -- ou pas du tout. Une organisation peut donc figurer dans le Directory alors que la recherche SMP renvoie No valid delivery options / PartyId not found, ou inversement. N'utilisez pas le Directory comme preuve qu'une personne peut ou ne peut pas recevoir.
• Peppol Lookup Service -- lookup.peppol.org, depuis mars 2026 : interroge le SMP directement et affiche le statut de publication actuel. Utile pour le dépannage lorsque le Directory et l'enregistrement réel sont désynchronisés.

Pour une réponse fiable à la question ce destinataire peut-il recevoir ou non, il faut effectuer une vraie recherche SMP -- ne pas consulter la vue du Directory. Deux outils publics effectuent la recherche Peppol réelle (la même recherche que celle exécutée par le PSB eConnect) :

• test.peppolautoriteit.nl/discover
• peppol.helger.com

Si la recherche réussit dans l'un de ces outils, le destinataire est joignable ; si elle échoue (PartyId not found / pas d'options de livraison), le destinataire n'est pas connecté pour ce type de document -- indépendamment de ce qu'affiche le Peppol Directory. Par programme, queryRecipientParty du PSB donne le même résultat autoritatif.

Dans le Peppol Directory, le champ « additional information » affiche le nom du fournisseur de services qui a effectué l’enregistrement -- pour les enregistrements via le PSB eConnect, il indique « eConnect ». Il s’agit de métadonnées de registrar SMP du SP enregistrant et ne fait pas partie de la businessCard configurable par participant. Les champs configurables par participant passent par businessCard.names ; le champ « additional information » est en dehors de cette portée et n’est donc pas configurable par participant -- même pas pour les partenaires en marque blanche qui s’enregistrent via l’endpoint PSB eConnect.

Pour les clients qui souhaitent vérifier par programmation si un destinataire est joignable, le Peppol Service Bus (PSB) eConnect propose l'endpoint queryRecipientParty qui interroge le SMP directement et indique via quel canal et format le destinataire est joignable.

Un destinataire peut être trouvable sur Peppol -- la recherche NAPTR et l'interrogation SMP réussissent -- et pourtant ne pas être en mesure de recevoir des factures. Le SMP publie en effet par type de document une capability. La réception de factures relève de invoices ; le renvoi d'un statut métier (BIS Invoice Response 3.0) relève de la capability distincte invoiceResponse. Ce sont des enregistrements indépendants.

Si un destinataire est enregistré sur son ID Peppol exclusivement pour Invoice Response transaction 3.0 (invoiceResponse sur on, invoices sur off), l'AP expéditeur ne trouve aucun endpoint invoices dans le SMP. Il n'existe alors aucun chemin de livraison valide pour une facture, et la plateforme eConnect signale No valid delivery options lors de l'envoi. Le destinataire peut envoyer un Invoice Response via cet identifiant, mais ne peut pas y recevoir de facture.

Deux solutions :

1. Point de livraison alternatif : demandez au client de contacter le destinataire pour savoir via quel canal (e-mail ou portail fournisseur) la facture peut être transmise.
2. Autre ID Peppol : vérifiez si le destinataire dispose d'un second ID Peppol sur lequel le type de document facture (invoices) est enregistré. Une organisation peut enregistrer plusieurs identifiants avec des capabilities de type de document distinctes par identifiant.

En cas de doute, vérifiez quels types de documents un destinataire publie via le Peppol Lookup Service ou par programmation via queryRecipientParty.