Table des matières
Ouvrir table des matières
Pourquoi un épisode sur Peppol dans une série française ?
Si vous avez suivi la série depuis l’épisode 1, vous savez que la réforme française repose sur des plateformes agréées qui s’échangent des factures. Mais la France n’a pas inventé ce modèle dans son coin : il existe depuis des années un réseau international d’échange de documents métier qui a défriché tous ces concepts — Peppol — et son ombre plane sur toute la réforme. On le croise dans les discussions d’interopérabilité entre plateformes, dans les stratégies des éditeurs européens, et dans le vocabulaire des spécifications.
Mon objectif ici : que vous sachiez dessiner Peppol au tableau blanc — parce que ses concepts (le modèle à quatre coins, l’annuaire distribué) sont la grammaire de tout l’e-invoicing moderne, réforme française comprise.
Une précision d’honnêteté avant de commencer : je décris ici l’architecture générale de Peppol, largement documentée publiquement (le réseau est gouverné par l’association OpenPeppol, basée à Bruxelles). Pour les détails normatifs à jour — versions de protocoles, politiques par pays — la source reste peppol.org 🔗 et sa documentation technique.
Le modèle à quatre coins : personne ne parle directement à personne
Le cœur de Peppol, c’est le modèle à quatre coins (four-corner model) :
- Coin 1 : l’émetteur du document (une entreprise).
- Coin 2 : son point d’accès (Access Point) — le prestataire qui la connecte au réseau.
- Coin 3 : le point d’accès du destinataire.
- Coin 4 : le destinataire.
L’entreprise ne parle qu’à son point d’accès. Les points d’accès se parlent entre eux, selon un protocole d’échange commun (la messagerie sécurisée AS4, dans les profils actuels du réseau). Résultat : chaque participant n’a besoin que d’une seule connexion pour joindre tout le réseau — c’est l’anti-modèle du « chaque paire d’acteurs négocie sa connexion », qui a englouti des décennies de projets EDI.
Ce dessin doit vous rappeler quelque chose : le schéma en Y français, avec ses plateformes agréées de part et d’autre, est une déclinaison de cette idée — deux entreprises, deux intermédiaires connectés entre eux, plus une branche fiscale spécifiquement française. Quand vous entendez « interopérabilité entre plateformes agréées », pensez « coin 2 parle à coin 3 ».
SMP et SML : l’annuaire est distribué, et c’est génial
La question qui fâche dans tout réseau décentralisé : comment le coin 2 sait-il où est le coin 3 ? Réponse Peppol, en deux étages — et c’est l’idée la plus élégante du système :
- Chaque destinataire est décrit dans un SMP (Service Metadata Publisher) : un petit service qui publie « ce participant sait recevoir tel type de document, à telle adresse de point d’accès, avec tel certificat ». C’est décentralisé : chaque prestataire peut opérer son SMP pour ses clients.
- Pour trouver quel SMP décrit un participant donné, il y a le SML (Service Metadata Locator) : un service central qui, à partir de l’identifiant du participant, oriente vers le bon SMP — techniquement, via le DNS.
Si vous avez lu mon article sur la résolution de tenant, vous comprenez pourquoi j’aime cette architecture : la livraison repose sur des faits d’adressage publiés — ce qu’un prestataire a déclaré dans un SMP — et non sur ce qu’un document raconte. On résout un identifiant vers une capacité de réception vérifiable, avec une chaîne de confiance par certificats. C’est le DNS des documents métier, littéralement.
Pour un développeur, deux conséquences pratiques :
- L’enregistrement est un acte de publication. Être « joignable sur Peppol », c’est exister dans un SMP référencé par le SML. Si un partenaire dit « on ne vous trouve pas », le diagnostic commence par là — pas dans votre code d’envoi.
- La découverte est dynamique. On interroge l’annuaire au moment d’envoyer : le destinataire a pu changer de prestataire hier. Toute mise en cache agressive de la résolution est un bug en puissance — vous reconnaîtrez le thème de fraîcheur des annuaires, omniprésent aussi dans la réforme française.
Ce que Peppol change (ou pas) pour votre chantier français
Alors, faut-il « être sur Peppol » pour être en règle en France ? Non — l’obligation française passe par les plateformes agréées (épisode 1). Mais Peppol reste pertinent dans au moins trois situations :
- Vous vendez au secteur public européen. Peppol est né de la commande publique européenne et y reste massivement utilisé. Si votre logiciel adresse des clients publics hors de France, le sujet est déjà sur votre table.
- Vous êtes éditeur avec des ambitions européennes. L’Allemagne, la Belgique, et d’autres pays structurent leur facturation électronique B2B autour de réseaux et de formats compatibles ; les concepts (et parfois l’infrastructure) Peppol y sont centraux. Une architecture qui parle nativement « quatre coins + annuaire distribué » voyagera mieux qu’une architecture franco-française.
- Votre plateforme agréée s’appuie sur Peppol pour l’interopérabilité. C’est un choix d’implémentation que certaines plateformes font pour leurs échanges. En tant qu’intégrateur vous n’avez pas à le gérer — mais le comprendre vous rendra meilleur dans les conversations techniques, notamment quand un statut se perd entre deux plateformes et qu’il faut diagnostiquer où.
Et même si vous ne touchez jamais Peppol directement, ses patterns sont un excellent kit de conception : découverte par annuaire plutôt que configuration par paire, capacités publiées plutôt que devinées, chaîne de confiance par certificats, accusés de bout en bout. Toute la série que vous êtes en train de lire en est, d’une certaine façon, une variation.
Épilogue
Peppol n’est pas une case à cocher de la réforme française — c’est la grammaire dont la réforme est un dialecte. Sachez dessiner les quatre coins, expliquer SMP et SML, et vous saurez situer n’importe quelle discussion d’interopérabilité, française ou européenne. Pour les détails normatifs du moment, une seule adresse : la documentation d’OpenPeppol.
Dernier épisode de la série la semaine prochaine : les pièges d’intégration que je vois passer — la synthèse terrain de tout ce qu’on a vu. Et pour la version « avec les mains dans le moteur » : gaetancottrez.dev/facturation-electronique 🔗.
Des questions sur le réseau, l’annuaire, les points d’accès ? En commentaire — je me ferai une joie de vous répondre.
Sources (consultées en août 2026) : peppol.org 🔗 (OpenPeppol AISBL — documentation eDelivery) · Spécifications externes et normes 🔗 (impots.gouv.fr). Note de relecture : les versions exactes des profils/protocoles Peppol (AS4, politiques SML) évoluent — à re-vérifier sur la documentation OpenPeppol avant publication ; l’article reste volontairement au niveau des concepts stables.
