FR

Accueil / Guide EDI / Protocoles de transmission

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.

Mise à jour 18 octobre 2026 · fokus it solutions, Jens Musleh

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é.
  • 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é.

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é.

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 ?.

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.

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.

Sources

Nous contacter · Questions fréquentes · Tous les articles du guide