Le réseau PEPPOL expliqué simplement

PEPPOL n'est pas un format de facture. C'est un réseau d'échange transfrontalier, fait de quatre acteurs logiques, de deux annuaires et d'un protocole de transport sécurisé. Cette page le présente sans jargon, avant de plonger ailleurs dans les détails techniques.

Le problème que PEPPOL résout

Imaginez un fournisseur établi en Suède qui veut facturer un hôpital public en Belgique. Sans PEPPOL, il devrait : découvrir comment cet hôpital reçoit ses factures (portail ? email ? EDI propriétaire ?), créer un compte chez cet hôpital ou son prestataire, apprendre son format (UBL local ? XML CIUS propre ?), tester, puis répéter ce travail pour chacun de ses clients publics européens. Multipliez par 27 États membres et plusieurs milliers d'acheteurs publics : le coût d'onboarding devient prohibitif.

PEPPOL résout ce problème par standardisation des trois axes : découverte (qui est le destinataire ?), format (quel XML envoyer ?), transport (par quel canal ?). Un fournisseur n'a plus qu'à s'enregistrer auprès d'un seul opérateur — son access point — et peut joindre n'importe quel destinataire enregistré sur le réseau, sans relation bilatérale.

Le modèle 4-corner

Le cœur du réseau est le modèle à quatre coins. Plutôt que de parler en abstrait, déroulons l'envoi d'une facture du fournisseur suédois Acme AB vers l'hôpital belge UZB.

Corner C1 — émetteur métier

Le Corner C1 est l'application métier de l'émetteur : l'ERP d'Acme AB qui génère la facture. Ce coin ne parle pas PEPPOL directement : il transmet la facture (typiquement en UBL Invoice 2.1) à son access point via une API privée (REST, SFTP, queue, etc.). Cette interface C1↔C2 est locale et spécifique au contrat entre Acme et son fournisseur d'access point.

Corner C2 — access point émetteur

Le Corner C2 est l'access point d'Acme — par exemple Tickstar ou Pagero — un opérateur certifié PEPPOL. À l'arrivée de la facture, C2 fait trois choses : il valide le document contre le Schematron du profil PEPPOL BIS Billing 3.0 ; il interroge l'annuaire pour trouver le destinataire ; et il pousse le message vers le destinataire en AS4.

Corner C3 — access point destinataire

Le Corner C3 est l'access point de l'hôpital UZB — disons B2Brouter ou Ibanity. Il reçoit le message AS4 d'Acme C2, vérifie la signature, retourne un receipt AS4 prouvant la livraison, et passe le document à son client final UZB.

Corner C4 — destinataire métier

Le Corner C4 est l'application métier du destinataire : le système de comptabilité de l'hôpital UZB. Comme C1, C4 ne parle pas PEPPOL directement : il récupère le document via une API privée fournie par son access point.

Le schéma à retenir : C1 → C2 → C3 → C4. Seul le segment C2→C3 emprunte le protocole PEPPOL standardisé ; les segments C1↔C2 et C3↔C4 sont privés et libres. Cette séparation est ce qui rend le réseau évolutif : chaque access point peut innover sur son interface client tant qu'il reste conforme côté PEPPOL.

Annuaires SMP et SML

Pour que C2 sache où pousser le message d'Acme vers UZB, il doit pouvoir résoudre l'identifiant du destinataire. PEPPOL utilise pour cela deux annuaires successifs.

Le SML (Service Metadata Locator) est un annuaire DNS centralisé unique, opéré par l'autorité technique de PEPPOL. Étant donné un identifiant destinataire — par exemple 0088:5790000435906 pour UZB (préfixe ICD 0088 pour les GLN GS1, suivi du GLN belge) — le SML répond par l'URL du SMP qui gère ce destinataire.

Le SMP (Service Metadata Publisher) est un annuaire fédéré. Chaque access point opère son propre SMP pour ses clients. Pour un identifiant donné, le SMP publie ses capacités : « ce destinataire peut recevoir des Invoice BIS Billing 3.0 », « ce destinataire peut recevoir des Order BIS 3.0 », avec pour chaque capacité l'URL AS4 de C3 et le certificat à utiliser pour chiffrer.

Le couple SML+SMP est inspiré du DNS d'Internet : un résolveur centralisé pour trouver le serveur de zone, un serveur de zone pour publier les détails. C'est cette architecture qui permet à n'importe quel destinataire de changer d'access point sans changer son identifiant.

Transport AS4 eDelivery

Une fois que C2 sait où pousser le message (URL de C3) et avec quel certificat, il utilise le protocole AS4 — un binding SOAP de l'OASIS ebMS 3.0. Le profil PEPPOL d'AS4 est strict : signature obligatoire, chiffrement obligatoire, receipt mode Non-Repudiation, pattern de communication One-Way Push.

AS4 PEPPOL fait partie du building block eDelivery de la Connecting Europe Facility (CEF), un cadre technique européen mutualisé. La conséquence pratique : l'autorité publique d'un pays peut s'appuyer sur l'implémentation open source Domibus pour déployer son propre access point sans repartir de zéro.

Sécurité par certificats X.509

Tout repose sur une chaîne de confiance cryptographique. Chaque access point détient un certificat PEPPOL X.509, signé par la PEPPOL Authority CA. Cette CA est elle-même attestée par OpenPeppol AISBL. Sans certificat valide, un access point ne peut ni pousser ni recevoir.

Pour qu'un nouvel access point rejoigne le réseau, il doit : 1) passer la certification PEPPOL annuelle (audit technique, tests de conformité) ; 2) s'enregistrer auprès d'une PEPPOL Authority nationale (Digdir en Norvège, AGID en Italie, AIFE en France, etc.) ; 3) obtenir son certificat. Le tout est payant et obéit à un calendrier annuel. C'est ce qui distingue PEPPOL d'un protocole ouvert comme HTTP : l'accès au réseau est contrôlé par une autorité.

Pour aller plus loin

• PEPPOL chez ediverse — la page de référence sur PEPPOL BIS Billing 3.0, EN 16931 et UBL.
• Feuille de route e-invoicing Europe 2025-2030 — où s'inscrit PEPPOL dans la directive ViDA et les mandats nationaux.
• OpenPEPPOL : architecture 4-corner et adoption en Europe — l'article de fond.
• AS4 chez ediverse — la page transport, pour les détails OASIS ebMS 3.0.