# Protocoles de transmission EDI : lequel convient à votre partenaire ? Les protocoles de transmission EDI courants sont AS2, OFTP2, SFTP, les interfaces HTTPS (API), l'e-mail et, dans certains secteurs, encore X.400 via un VAN. Vous décidez rarement seul de celui que vous utilisez : le plus souvent, le client ou le fournisseur l'impose dans son guide EDI. Cette page montre ce qui distingue ces protocoles et à quoi il faut veiller lors de la mise en place. ## Format et protocole de transmission : deux questions Une connexion EDI comporte deux niveaux qu'on confond souvent : - Le format détermine la structure du contenu : EDIFACT, VDA, XML ou CSV. Plus de détails dans [EDIFACT expliqué](https://edi-service.eu/fr/guide/edifact/). - Le protocole de transmission détermine comment le fichier passe d'un ordinateur à l'autre : AS2, OFTP2, SFTP, etc. Ces niveaux sont indépendants. Une facture EDIFACT peut voyager via AS2, OFTP2 ou SFTP. Un programme de livraison VDA arrive souvent via OFTP2, mais techniquement d'autres voies seraient possibles. Quand votre client exige « l'EDI », il vous faut donc deux réponses : quel format et quel protocole. ## Les protocoles de transmission EDI en un coup d'œil ### AS2 AS2 envoie des fichiers par HTTP directement au partenaire, signés, chiffrés et avec un accusé de réception, le MDN. Il repose sur la RFC 4130. AS2 n'est lié à aucun secteur. Détails : [AS2 expliqué](https://edi-service.eu/fr/guide/protocole-as2/). ### OFTP2 OFTP2 est le protocole de l'industrie automobile, maintenu par Odette et décrit dans la RFC 5024. Il utilise sa propre connexion TCP (port 6619 avec TLS), s'appuie sur des certificats et confirme chaque fichier par un EERP. Détails : [OFTP2 expliqué](https://edi-service.eu/fr/guide/oftp2/). ### SFTP SFTP transfère des fichiers via une connexion SSH (Secure Shell, RFC 4251 ; port standard 22). Le plus souvent, une partie met un répertoire à disposition, l'autre y dépose des fichiers ou les y récupère. La connexion est chiffrée, mais il n'y a pas d'accusé de réception au niveau du fichier. Vous ne savez si un fichier a été traité que par un message de réponse ou par une convention, par exemple « le fichier est supprimé après récupération ». ### Interface HTTPS (API) Une connexion par API signifie que le partenaire propose une adresse web à laquelle votre système envoie des données ou depuis laquelle il les récupère, le plus souvent en JSON ou en XML. La connexion est chiffrée par TLS (RFC 8446), l'authentification passe par des clés ou des jetons. Chaque API est construite différemment, chacune exige donc sa propre connexion. ### E-mail L'e-mail est la voie la plus simple : le fichier EDI est joint à un message. La RFC 1767 décrit comment encapsuler des données EDI dans des e-mails MIME ; AS1 (RFC 3335) y a ajouté signature et accusé de réception. En pratique, un e-mail simple n'est ni signé ni confirmé. Il reste utilisé pour de petits volumes ou comme solution transitoire. ### X.400 et VAN Avec X.400, l'UIT-T décrit une série de normes pour les systèmes de messagerie ; elle en recense des versions depuis 1988, la version en vigueur étant celle de 1999. Un VAN (Value Added Network, réseau à valeur ajoutée) est le réseau d'un prestataire, avec des boîtes aux lettres, par lequel les partenaires échangent des données sans se connecter directement. Dans la distribution, on rencontre encore X.400 : des prestataires EDI allemands comme cctop et EDI Fuchs le font figurer dans leurs grilles tarifaires, EDI Fuchs par exemple en supplément à partir de 10 € par mois, par type de message et par partenaire. ## Tableau comparatif | Protocole | Où il est courant | Sécurité | Accusé de réception | Effort pour vous | |---|---|---|---|---| | AS2 | tous secteurs | signature et chiffrement par fichier, TLS en option | oui, MDN (signature possible) | moyen : logiciel, certificat, adresse joignable | | OFTP2 | industrie automobile | TLS, certificats, signature et chiffrement des fichiers possibles | oui, EERP (signature possible) | moyen à élevé : logiciel, identifiant Odette, certificat, port 6619 | | SFTP | tous secteurs | connexion chiffrée par SSH | non, seulement par convention ou message de réponse | faible : accès et clé | | HTTPS/API | là où le partenaire propose une API | TLS, authentification par jeton ou clé | selon l'API (code de réponse, statut) | une connexion propre à chaque API | | E-mail | petits volumes, solutions transitoires | e-mail simple non protégé, chiffrement seulement avec un complément | non (oui avec AS1) | faible, mais source d'erreurs | | X.400/VAN | une partie de la distribution | dans le réseau du prestataire | selon le réseau | contrat avec un prestataire VAN, frais récurrents | La colonne « Où il est courant » donne un classement approximatif. Ce qui fait foi, c'est ce que votre partenaire exige dans son guide EDI. ## Les critères de choix Si vous avez le choix, trois questions aident : 1. Avez-vous besoin d'une preuve que le fichier est arrivé ? Pour l'avis d'expédition et la facture, c'est en général le cas. AS2 et OFTP2 ont alors l'avantage, car l'accusé de réception fait partie du protocole. 2. Qui établit la connexion ? Avec AS2 et OFTP2, le partenaire vous envoie souvent les fichiers de lui-même. Votre serveur a alors besoin d'une adresse fixe et d'un port entrant ouvert. Avec SFTP ou une API, vous pouvez aussi récupérer les données vous-même, sans port ouvert dans votre pare-feu. 3. Combien de partenaires utilisent le même protocole ? Chaque protocole supplémentaire est un composant de plus à exploiter, à surveiller et à doter de certificats. Côté sécurité : une voie avec connexion chiffrée suffit pour beaucoup de données. Les fichiers signés et les accusés de réception valent la peine quand un litige sur la réception ou le contenu peut survenir plus tard. ## Le coût de la transmission Les spécifications d'AS2, OFTP2, SFTP et HTTPS sont librement accessibles sous forme de RFC. Les coûts viennent du logiciel, des certificats, pour OFTP2 de l'identifiant Odette, et de l'exploitation. Avec X.400 et un VAN s'ajoutent les frais récurrents de l'opérateur du réseau. Le calcul d'ensemble figure dans [Combien coûte une connexion EDI ?](https://edi-service.eu/fr/guide/combien-coute-l-edi/). ## Les protocoles de transmission chez edi-service.eu edi-service.eu prend en charge OFTP2, AS2, SFTP, HTTPS et l'e-mail, en entrée et en sortie. X.400 et les boîtes aux lettres VAN n'en font pas partie. Si un partenaire n'est joignable que par ce biais, il faut une voie complémentaire, par exemple un prestataire EDI uniquement pour ce partenaire, ou bien le partenaire passe à AS2 ou OFTP2. Notre composant OFTP2 n'est pas testé par Odette ; nous clarifions ce point en amont si votre client exige un logiciel testé. Ce que couvre le prix figure sous [Prix](https://edi-service.eu/fr/#preis). ## Questions fréquentes ### Quel est le meilleur protocole de transmission EDI ? Il n'y a pas un meilleur protocole ; le plus souvent, c'est votre partenaire qui décide. Dans l'automobile, OFTP2 est répandu ; les autres secteurs utilisent selon le partenaire AS2, SFTP ou une API. SFTP est simple à mettre en place, mais ne fournit pas d'accusé de réception. ### L'e-mail suffit-il pour l'EDI ? Pour de petits volumes et comme solution transitoire, il peut suffire si votre partenaire l'accepte. Mais un e-mail simple n'est ni signé ni confirmé, et les messageries filtrent parfois les pièces jointes. Pour les avis d'expédition et les factures, un protocole avec accusé de réception est le choix le plus sûr. ### Qu'est-ce qu'un VAN, et en ai-je besoin ? Un VAN est le réseau d'un prestataire, dans lequel chaque participant dispose d'une boîte aux lettres. Vous n'en avez besoin que si un partenaire n'est joignable que par ce moyen, par exemple via X.400. Pour des connexions directes via AS2, OFTP2 ou SFTP, aucun VAN n'est nécessaire. ### Mon serveur doit-il être joignable depuis Internet ? Avec AS2 et OFTP2, le plus souvent oui, à savoir quand le partenaire vous envoie les fichiers de lui-même. Il vous faut alors une adresse fixe et un port ouvert. Avec SFTP ou une API, quand c'est vous qui récupérez, une connexion sortante suffit. Vous voulez vérifier si les protocoles de vos partenaires correspondent à 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 5024: ODETTE File Transfer Protocol 2 », (consulté le 16 octobre 2026) - Odette International : « OFTP2 », (consulté le 16 octobre 2026) - RFC Editor : « RFC 4251: The Secure Shell (SSH) Protocol Architecture », (consulté le 16 octobre 2026) - RFC Editor : « RFC 4253: The Secure Shell (SSH) Transport Layer Protocol » (port 22), (consulté le 16 octobre 2026) - RFC Editor : « RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 », (consulté le 16 octobre 2026) - RFC Editor : « RFC 1767: MIME Encapsulation of EDI Objects », (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) - ITU-T : « F.400/X.400: Message handling system and service overview », (consulté le 16 octobre 2026) - stratEDI (cctop) : Preisliste Clearing und WebEDI (PDF), (consulté le 16 octobre 2026) - Fuchs ITC (EDI Fuchs) : Preise, (consulté le 16 octobre 2026)