# Comment fonctionne le protocole AS2 ? Le protocole AS2 (Applicability Statement 2) est une méthode qui permet à deux entreprises d'échanger des fichiers EDI directement sur Internet, signés, chiffrés et avec accusé de réception. Il est décrit dans la RFC 4130 de l'IETF et utilise HTTP comme transport. AS2 n'est lié à aucun secteur ; dans l'automobile, c'est en revanche le plus souvent [OFTP2](https://edi-service.eu/fr/guide/oftp2/) qui est demandé. Pour vous connecter, il vous faut un logiciel AS2, un identifiant AS2, un certificat et une adresse joignable depuis Internet. ## Comment fonctionne le protocole AS2 La RFC 4130 est parue en juillet 2005 en tant que « Proposed Standard ». Son prédécesseur AS1 (RFC 3335) transmettait les fichiers par e-mail ; AS2 transpose le même principe sur HTTP. Une transmission se déroule ainsi : 1. Votre logiciel emballe le fichier EDI, par exemple une facture EDIFACT, dans un message MIME. 2. Il signe le message avec votre clé privée et le chiffre avec le certificat public du partenaire (S/MIME, le même procédé que pour l'e-mail sécurisé). 3. Il envoie le message par HTTP POST à une adresse du partenaire convenue à l'avance, par exemple `https://as2.partner.example/as2`. 4. Le logiciel du partenaire déchiffre, vérifie la signature et renvoie un accusé de réception, le MDN. Ce sont les partenaires qui décident si la connexion est en plus sécurisée par TLS (donc HTTPS au lieu de HTTP). Le fichier lui-même est protégé par la signature et le chiffrement, même si la connexion n'utilise pas TLS. Le guide EDI de votre partenaire indique s'il exige en plus HTTPS. AS2 est un protocole point à point. Il n'y a pas d'intermédiaire comme dans un VAN (Value Added Network, réseau à valeur ajoutée) ; les fichiers vont directement de serveur à serveur. Une comparaison avec les autres protocoles figure dans [Protocoles de transmission EDI](https://edi-service.eu/fr/guide/protocoles-transmission-edi/). ## Identifiant AS2 et profil partenaire Chaque partie a un identifiant AS2. Il figure dans les en-têtes HTTP `AS2-From` et `AS2-To` et indique de qui vient le message et à qui il est destiné. Selon la RFC 4130, l'identifiant AS2 compte de 1 à 128 caractères ASCII imprimables, et la casse compte. Un numéro existant convient comme valeur ; la RFC 4130 cite en exemple le numéro DUNS, le GLN est également possible. Plus d'informations dans [GLN et autres identifiants](https://edi-service.eu/fr/guide/gln-identifiants-edi/). Un profil partenaire AS2 complet contient : | Information | Exemple (fictif) | |---|---| | votre identifiant AS2 et celui du partenaire | `9520000000011` et `PARTNERAS2` | | adresse (URL) du partenaire | `https://as2.partner.example/as2` | | certificat du partenaire pour le chiffrement et la vérification de signature | fichier `partner.cer` | | algorithmes de signature et de chiffrement | par exemple SHA-256 et AES | | MDN : signé ou non, synchrone ou asynchrone | signé, synchrone | | adresse de test et adresse de production | souvent deux URL distinctes | Ces valeurs figurent dans le guide EDI de votre client ou dans son formulaire d'inscription. S'il manque une information, demandez-la au lieu de la deviner. ## L'échange des certificats AS2 utilise des certificats X.509. Selon la RFC 4130, les partenaires peuvent utiliser des certificats auto-signés ; une autorité de certification n'est pas obligatoire. En pratique, chaque partie génère une paire de clés et envoie à l'autre son certificat public, le plus souvent par e-mail ou via un portail. La clé privée reste toujours chez vous. Les certificats expirent. Les nouveaux certificats doivent être échangés suffisamment tôt avant la date d'expiration, sinon la vérification de signature ou le déchiffrement échouent. Prévoyez pour cela une échéance fixe et une surveillance. ## Le MDN, accusé de réception synchrone ou asynchrone Le MDN (Message Disposition Notification) est l'accusé de réception. S'il est signé, il contient une valeur de contrôle du message reçu (MIC, Message Integrity Check). Vous pouvez ainsi prouver que ce fichier précis est arrivé sans modification. Dans la variante synchrone, le MDN revient en réponse au même appel HTTP. C'est simple, car aucune seconde connexion n'est nécessaire. Mais avec de très gros fichiers, la connexion peut expirer avant que le destinataire ait terminé. Dans la variante asynchrone, le destinataire confirme immédiatement l'appel HTTP et envoie le MDN plus tard, par une connexion distincte, à une adresse que l'émetteur indique dans l'en-tête `Receipt-Delivery-Option`. L'émetteur doit alors lui aussi être joignable depuis Internet. ## Les erreurs fréquentes dans les connexions AS2 - Identifiant AS2 mal orthographié : comme la casse compte, `Partneras2` est un autre identifiant que `PARTNERAS2`. - Certificat erroné ou expiré : le partenaire a un nouveau certificat, votre logiciel utilise encore l'ancien. - Pare-feu : l'adresse n'est pas joignable depuis Internet, ou le port du partenaire est bloqué en sortie. - MIC non concordant : les algorithmes des deux côtés ne correspondent pas, le MDN est rejeté comme invalide. - Le MDN asynchrone n'arrive pas, parce que l'adresse de retour est interne ou bloquée. - Test et production inversés : des fichiers de test arrivent dans le système de production du partenaire, ou l'inverse. La plupart de ces erreurs apparaissent lors du premier test de connexion. C'est pourquoi chaque mise en production est précédée d'un test avec des fichiers de test, jusqu'à ce que fichier et MDN passent correctement dans les deux sens. ## Ce qui distingue AS4 d'AS2 AS4 est un protocole plus récent de l'organisme de normalisation OASIS, standard OASIS depuis le 23 janvier 2013. Selon le standard, il a été créé pour prolonger le succès d'AS2. Par rapport à AS2, OASIS cite trois nouveautés : AS4 s'aligne sur les standards des services web (ebMS 3.0, fondé sur SOAP), les messages peuvent être récupérés par le destinataire (« pull »), et les accusés de réception sont intégrés d'office. Un domaine d'utilisation important est Peppol, un réseau notamment pour les factures électroniques : selon la spécification Peppol, l'échange entre les points d'accès (Access Points) passe par AS4. Ce que cela implique pour les factures électroniques est expliqué dans [EDI, Web-EDI et facture électronique](https://edi-service.eu/fr/guide/edi-web-edi-facture-electronique/). ## AS2 chez edi-service.eu Chez edi-service.eu, AS2 fait partie des protocoles de transmission, avec OFTP2, SFTP, HTTPS et l'e-mail, en entrée et en sortie avec MDN. Le logiciel tourne sur votre propre serveur ; celui-ci a besoin pour cela d'une adresse fixe et d'un port HTTPS entrant. Nous ne proposons pas d'accès Peppol (AS4) propre. Ce qui est compris dans le prix figure dans les [questions fréquentes](https://edi-service.eu/fr/faq/). ## Questions fréquentes ### Quelle est la différence entre AS2 et SFTP ? AS2 signe et chiffre chaque fichier et fournit avec le MDN un accusé de réception. SFTP transfère des fichiers via une connexion SSH chiffrée, sans accusé de réception métier. C'est le plus souvent votre client qui fixe le protocole. ### Faut-il acheter un certificat pour AS2 ? Pas forcément. La RFC 4130 autorise les certificats auto-signés. Certains partenaires exigent toutefois un certificat d'une autorité de certification précise ; cela figure alors dans leur guide EDI. ### Un MDN synchrone ou asynchrone, lequel est le mieux ? Le synchrone est plus simple et suffit pour des tailles de fichier courantes. L'asynchrone est utile pour les gros fichiers ou les traitements longs, mais suppose que votre système soit lui aussi joignable de l'extérieur. Le plus souvent, le partenaire impose la variante. ### AS2 est-il dépassé parce qu'AS4 existe ? Non. La RFC 4130 reste en vigueur sans changement, et AS2 reste utilisé pour les connexions directes entre partenaires commerciaux. Vous rencontrerez AS4 surtout dans des réseaux comme Peppol. Le guide EDI de votre partenaire vous dit de quel protocole vous avez besoin. Vous avez le guide AS2 de votre client et voulez savoir si la connexion est possible avec edi-service.eu ? [Envoyez-nous une demande](https://edi-service.eu/fr/demande/). ## Sources - RFC Editor : « RFC 4130: MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2) », (consulté le 16 octobre 2026) - RFC Editor : « RFC 3335: MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet », (consulté le 16 octobre 2026) - OASIS : « AS4 Profile of ebMS 3.0 Version 1.0 », standard OASIS du 23 janvier 2013, (consulté le 16 octobre 2026) - OpenPeppol : « Peppol AS4 Profile », (consulté le 16 octobre 2026)