AS4 — Applicability Statement 4

Le successeur SOAP d'AS2, profilé par l'OASIS sur la base d'ebMS 3.0. Devenu en 2020 le transport unique du réseau PEPPOL eDelivery et du Building Block eDelivery de la Commission européenne.

Qu'est-ce qu'AS4 ?

AS4 est un profil de la spécification OASIS ebXML Messaging Services 3.0 (ebMS3). La spécification ebMS3 Core est dense — elle couvre routing multi-hop, fiabilité WS-ReliableMessaging, sécurité, fragmentation, politiques P-Mode complètes — et son adoption industrielle a été freinée par cette complexité. AS4 applique le principe just-enough design : on retient un sous-ensemble cohérent qui couvre 95 % des cas réels et on cadre les choix d'implémentation (algorithmes, MEP, schéma d'accusé) pour qu'une AS4 d'un éditeur parle d'emblée à l'AS4 d'un autre.

Trois apports d'AS4 par rapport au Core ebMS3 sont mis en avant par l'OASIS : (1) meilleur alignement sur les standards WS-* contemporains, (2) introduction du pull en plus du push, ce qui ouvre la messagerie aux clients sans IP fixe (PME, points d'accès mobiles), et (3) un mécanisme de réception intégré qui produit une preuve cryptographique de non-répudiation (signed receipt).

Pourquoi AS4 plutôt qu'AS2 ?

AS2 et AS4 résolvent le même problème — transporter un payload EDI signé et chiffré entre deux partenaires sur Internet — mais avec des choix architecturaux différents :

AS4 est donc le bon choix dès que (a) l'on rejoint le réseau PEPPOL ou eDelivery européen, (b) l'on a besoin d'un transport pull pour servir des clients sans IP fixe, ou (c) l'on veut une description déclarative des services (P-Mode) plutôt qu'un échange de cahier des charges manuels avec chaque partenaire.

Trois profils de conformité

La spécification AS4 §3 définit trois niveaux de conformité qui correspondent à trois rôles industriels distincts :

• AS4 ebHandler — l'équivalent d'une passerelle complète. Bidirectionnel (envoi et réception), supporte push et pull en transport, sécurité complète, gestion de paramètres P-Mode complets. C'est le profil qu'implémentent les Access Points PEPPOL et les passerelles eDelivery.
• AS4 Light Client — client uniquement, pas de serveur HTTP entrant requis. Pousse en sortie, tire (pull) en entrée depuis la file d'attente d'un ebHandler. Idéal pour les bureaux distants ou les clients mobiles sans IP fixe.
• AS4 Minimal Client — feature set réduit pour les contraintes basses. One-Way/Push seulement, pas de support natif de la signature ni des accusés. Chemin d'implémentation le plus court mais peu utilisé en pratique pour les flux réglementaires.

Anatomie d'un message AS4

Un message AS4 est un POST HTTP dont le corps est un multipart/related typé application/soap+xml. La première partie est l'enveloppe SOAP 1.2 qui contient :

• Un eb:Messaging dans le Header, qui transporte le UserMessage ou le SignalMessage selon que le message est un payload ou un accusé.
• Un eb:UserMessage qui décrit le contexte : parties (From, To avec PartyId typés iso6523), service et action métier (CollaborationInfo), et la liste des pièces jointes via PayloadInfo.
• Un en-tête wsse:Security qui porte la signature XMLDSig et éventuellement le chiffrement XMLEnc des parties.

Les parties suivantes du multipart/related portent les payloads métier, référencés par leur Content-ID depuis le PayloadInfo SOAP. Le corps SOAP lui-même est généralement vide — le payload n'est pas inline.

POST /msh HTTP/1.1
Host: ap.partner.example
Content-Type: multipart/related; boundary="MIMEBoundary_as4";
  type="application/soap+xml"; start="<soap@ediverse.io>"
SOAPAction: ""

--MIMEBoundary_as4
Content-Type: application/soap+xml; charset=UTF-8
Content-ID: <soap@ediverse.io>

<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
              xmlns:eb="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/">
  <s12:Header>
    <eb:Messaging s12:mustUnderstand="true">
      <eb:UserMessage>
        <eb:MessageInfo>
          <eb:Timestamp>2026-05-14T09:30:00Z</eb:Timestamp>
          <eb:MessageId>uuid:6b6f9a2c-2a4a-4b6f-a89e-0a4a2e9f1c14@ediverse.io</eb:MessageId>
        </eb:MessageInfo>
        <eb:PartyInfo>
          <eb:From>
            <eb:PartyId type="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088">
              5790000435975
            </eb:PartyId>
            <eb:Role>http://docs.peppol.eu/edn/as4/role/sender</eb:Role>
          </eb:From>
          <eb:To>
            <eb:PartyId type="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088">
              5790000123456
            </eb:PartyId>
            <eb:Role>http://docs.peppol.eu/edn/as4/role/receiver</eb:Role>
          </eb:To>
        </eb:PartyInfo>
        <eb:CollaborationInfo>
          <eb:Service type="cenbii-procid-ubl">
            urn:fdc:peppol.eu:2017:poacc:billing:01:1.0
          </eb:Service>
          <eb:Action>
            urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice
          </eb:Action>
          <eb:ConversationId>uuid:e6b7…</eb:ConversationId>
        </eb:CollaborationInfo>
        <eb:PayloadInfo>
          <eb:PartInfo href="cid:invoice@ediverse.io"/>
        </eb:PayloadInfo>
      </eb:UserMessage>
    </eb:Messaging>
    <!-- WSS 1.1: Signature et Timestamp omis ici pour la lisibilité -->
  </s12:Header>
  <s12:Body/>
</s12:Envelope>

--MIMEBoundary_as4
Content-Type: application/xml
Content-ID: <invoice@ediverse.io>
Content-Transfer-Encoding: binary

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  ...
</Invoice>
--MIMEBoundary_as4--

Séquence push / pull et accusé NRR

Le MEP One-Way/Push est le scénario par défaut : l'émetteur ouvre une connexion HTTPS vers l'URL MSH du destinataire et pousse le UserMessage. Le destinataire renvoie immédiatement un SignalMessage contenant un Receipt dans la même connexion (réponse synchrone) ou via un callback HTTPS séparé (asynchrone).

Le MEP One-Way/Pull inverse l'initiative : le client ouvre une connexion vers son ebHandler, envoie un SignalMessage de type PullRequest contenant un MPC (Message Partition Channel) qui identifie la queue à consulter, et reçoit en réponse un UserMessage du serveur. Ce modèle est essentiel pour servir des Access Points PEPPOL légers ou des PME dont l'infrastructure ne permet pas de tenir un serveur HTTP exposé.

L'accusé AS4 est sensiblement plus riche que le MDN AS2. Il contient un bloc NonRepudiationInformation qui réplique les ds:Reference de la signature XMLDSig du message original, avec leurs DigestValue tels que reçus. C'est cet écho de digest qui fait office de preuve cryptographique de réception : si les digests correspondent à ceux que l'émetteur a calculés à l'envoi, la NRR est prouvée.

<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
              xmlns:eb="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/">
  <s12:Header>
    <eb:Messaging s12:mustUnderstand="true">
      <eb:SignalMessage>
        <eb:MessageInfo>
          <eb:Timestamp>2026-05-14T09:30:02Z</eb:Timestamp>
          <eb:MessageId>uuid:receipt-9a1e…@ap.partner.example</eb:MessageId>
          <eb:RefToMessageId>uuid:6b6f9a2c-…@ediverse.io</eb:RefToMessageId>
        </eb:MessageInfo>
        <eb:Receipt>
          <ebbp:NonRepudiationInformation
              xmlns:ebbp="http://docs.oasis-open.org/ebxml-bp/ebbp-signals-2.0">
            <ebbp:MessagePartNRInformation>
              <ds:Reference URI="cid:invoice@ediverse.io"
                  xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>F4r0…Base64…SkE=</ds:DigestValue>
              </ds:Reference>
            </ebbp:MessagePartNRInformation>
          </ebbp:NonRepudiationInformation>
        </eb:Receipt>
      </eb:SignalMessage>
    </eb:Messaging>
  </s12:Header>
  <s12:Body/>
</s12:Envelope>

Sécurité — WS-Security et P-Mode

AS4 mandate WS-Security 1.1 pour la sécurité au niveau message :

• Signature XMLDSig sur l'en-tête Messaging et sur chaque partie référencée par PayloadInfo, avec algorithmes par défaut http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 pour la signature et http://www.w3.org/2001/10/xml-exc-c14n# pour la canonicalisation.
• Chiffrement XMLEnc sur les parties sensibles, avec http://www.w3.org/2009/xmlenc11#aes128-gcm ou aes256-gcm, et clé de session chiffrée par RSA-OAEP.
• Jeton X.509 dans le bloc wsse:BinarySecurityToken, qui porte le certificat de l'émetteur, référencé par la signature.
• TLS sous-jacent recommandé en plus, pour la confidentialité du transport et l'authentification mutuelle des points d'accès.

Le P-Mode (Processing Mode) est la pierre angulaire de l'interopérabilité AS4. C'est un ensemble de paramètres déclaratifs (Service, Action, sécurité requise, schéma d'accusé, compression) qu'un ebHandler associe à chaque type d'échange. Deux passerelles AS4 qui partagent le même P-Mode ID sont par construction interopérables : elles n'ont rien à négocier hors-bande. Dans PEPPOL, le P-Mode est imposé par l'OpenPEPPOL Authority et identifié par un AgreementRef public.

AS4 dans PEPPOL et eDelivery

L'adoption la plus visible d'AS4 est sa désignation comme transport unique du réseau PEPPOL eDelivery. Depuis le 1^er février 2020, tous les Access Points (les passerelles qui connectent une organisation au réseau) doivent implémenter AS4 selon le profil PEPPOL AS4 Specification, qui durcit certaines options laissées libres par OASIS (algorithmes obligatoires, MEP push-only entre Access Points, certificats émis par l'Autorité PEPPOL).

AS4 est également retenu comme transport par le Building Block eDelivery de la Connecting Europe Facility (CEF) de la Commission européenne. Ce Building Block est ré-utilisé dans des secteurs régulés : e-CODEX pour la justice transfrontière, eHealth Digital Service Infrastructure pour la santé, ENTSO-G/E pour les opérateurs de réseau gaz et électricité.

Conséquence : tout fournisseur EDI européen qui veut accompagner ses clients sur les mandats e-invoicing 2026-2028 (France septembre 2026, Belgique janvier 2026, Allemagne 2025, Espagne 2026-2027) doit avoir AS4 dans sa pile. C'est aujourd'hui la croissance la plus forte du portefeuille des éditeurs EDI historiquement positionnés sur AS2.

Pièges opérationnels

• P-Mode non aligné. Deux passerelles qui se croient interopérables peuvent diverger sur un détail (algorithme de signature, compression activée, schéma d'accusé async) et tous les messages tombent en erreur. Toujours valider via les tests OpenPEPPOL TIA avant mise en production.
• Référence digest cassée par re-canonicalisation. Un composant intermédiaire qui re-sérialise le SOAP (reformatage, ré-encodage UTF-8) casse les DigestValue des ds:Reference. L'AS4 doit recevoir l'XML byte-pour-byte tel qu'envoyé, comme pour AS2 S/MIME.
• Pull avec MPC mal configuré. Si un client pull est enregistré sur un MPC vide, il consommera des appels pour rien. Surveiller la profondeur des MPC côté ebHandler.
• Certificat AS4 distinct du certificat TLS. Les deux mondes sont indépendants : certificat WSS pour la signature des messages, certificat TLS pour la session HTTPS. Confondre les deux est une cause fréquente d'incidents d'enrôlement PEPPOL.

Sources officielles

• OASIS — AS4 Profile of ebMS 3.0 v1.0 (23 janvier 2013) — la spécification canonique.
• OASIS — ebXML Messaging Services 3.0 Core (Part 1) — la base technique qu'AS4 profile.
• PEPPOL AS4 Specification — le profil PEPPOL qui durcit AS4 pour le réseau eDelivery.
• CEF Digital Building Block — eDelivery — l'infrastructure UE qui réutilise AS4.

Pour aller plus loin

• AS2 — anatomie détaillée pour comparer point par point.
• PEPPOL — BIS Billing 3.0 et UBL pour le payload transporté par AS4 dans le réseau européen.
• Comparaison des cinq familles de protocoles EDI pour le contexte décisionnel.
• OFTP2 pour le contraste avec l'écosystème automobile européen.