Résumé

  • Le RFC 1865 remplaçait les composants de transmission entre systèmes EDI existants par le courrier Internet. Sa livraison SMTP directe et « assurée » s’arrêtait au système du partenaire et conservait les accords bilatéraux.
  • Le RFC 1767 transportait X12, EDIFACT et EDI-consent dans MIME sans changer leur syntaxe ni leur sens et sans apporter, à lui seul, de sécurité.
  • Les RFC 3335 et 4130 ont ajouté Message-ID, MIC, signature et MDN. Un reçu signé pouvait néanmoins signaler un échec, et la validité de la transaction restait à résoudre entre partenaires.

Le serveur de courrier ne pouvait pas acheter

Une commande électronique arrive sur le serveur d’un distributeur. Le dialogue SMTP est positif et les octets sont présents. Rien ne dit encore que le distributeur accepte la quantité, le prix ou la date. Le message peut être un doublon, échouer au traducteur EDI, viser un mauvais profil de partenaire ou déclencher un refus applicatif.

Le RFC 1865, document Informational de janvier 1996, s’adressait à une communauté EDI découvrant Internet. Il ne proposait pas de remplacer les applications métiers. Il plaçait des modules Internet à l’endroit occupé par les fonctions de communication.

Dans une connexion SMTP dédiée, écrivait-il, l’information était remise directement au système du partenaire et la livraison était assurée. Pour un parcours avec relais, l’intégrité dépendait des intermédiaires. La distinction avait une portée opérationnelle réelle. Mais le sujet grammatical était le système de transport. Lui attribuer l’acceptation d’une commande reviendrait à donner au serveur une compétence que le reste du texte réservait aux partenaires.

Une enveloppe commune, un sens inchangé

Le RFC 1865 définissait l’EDI comme l’échange d’informations commerciales standardisées entre applications. Le commerce électronique était plus large : communication humaine, transfert d’argent et ressources partagées pouvaient aussi en faire partie. Une facture EDI était donc un objet de commerce, pas la preuve que toutes les actions commerciales avaient eu lieu.

Le RFC 1767 rendit trois familles d’objets transportables par MIME : EDI-X12, EDIFACT et EDI-consent. Son parcours va du programme métier au traducteur EDI, puis au traitement MIME et à SMTP ; chez le destinataire, il faut encore retirer l’enveloppe, traduire et traiter.

Le texte précisait qu’il ne modifiait ni syntaxe ni sémantique EDI. Il ne fournissait pas davantage de sécurité par lui-même. Le type MIME rendait l’objet reconnaissable et transportable. Il ne validait ni son contenu, ni son origine, ni son autorité commerciale.

Le cas EDI-consent révélait aussi la gouvernance persistante : son usage exigeait l’accord bilatéral explicite des partenaires. Internet permettait de remplacer un nom de boîte propriétaire par une adresse ouverte ; il ne décidait pas qui pouvait engager l’entreprise.

Le reçu s’est enrichi par étapes

Le transport SMTP possède ses propres changements de responsabilité. Le RFC 5321 organise l’acceptation et la remise du courrier, pas la décision d’un acheteur. Pour dépasser ce niveau, l’EDI Internet a construit un reçu plus riche.

Le RFC 3335 décrivit signature, chiffrement et MDN signé. L’identifiant du message original permettait la corrélation ; le MIC retourné représentait le contenu reçu ; la signature du destinataire rendait la réponse attribuable selon la clé et la politique applicables. L’expéditeur devait encore vérifier ce reçu.

Même la non-répudiation de réception était présentée comme un événement juridique après cette vérification. Un certificat valable ne prouve pas, à lui seul, que le signataire avait mandat pour accepter une commande. Le protocole crée une pièce probante ; l’accord et le droit déterminent sa portée.

Le RFC 4130 rendit la frontière plus nette. Si un reçu signé était demandé, le destinataire devait le produire même lorsque le traitement du contenu échouait. La disposition devait exprimer l’échec. Ce reçu négatif était précieux : il distinguait une arrivée suivie d’un rejet d’une disparition silencieuse.

Quand le reçu signé obligatoire manquait, le RFC laissait aux partenaires le soin de résoudre la validité de la transaction, probablement invalide. Ses mécanismes soutenaient les besoins de preuve sans définir eux-mêmes la non-répudiation, décrite comme une exigence commerciale ou juridique.

Affiché ne voulait pas dire compris

Le RFC 3798 ajoutait deux limites générales. Le destinataire pouvait ignorer une demande de MDN. Une disposition displayed ne garantissait pas que le contenu avait été lu ou compris.

La même discipline vaut pour l’automatisation. Une réponse SMTP n’est pas un MDN. Un MDN n’est pas le résultat du traducteur. Un résultat du traducteur n’est pas l’accusé fonctionnel de l’application. Cet accusé n’est pas nécessairement l’acceptation contractuelle.

Il faut donc conserver la suite : objet exact envoyé, acceptation ou remise du courrier, disposition corrélée et éventuellement signée, comparaison du MIC, résultat EDI, réponse de l’application et décision de l’autorité commerciale. Les noms peuvent changer, mais aucun acteur ne doit exercer silencieusement le pouvoir du suivant.

La décentralisation du transport n’abolissait pas le contrat

RFC 1865 envisageait un annuaire distribué, un routage coopératif et une résolution d’adresses, ainsi que plusieurs fournisseurs et serveurs de courrier pour la fiabilité. L’EDI ne devait pas dépendre d’un coordinateur Internet central. Cette ouverture pouvait réduire la dépendance à un réseau à valeur ajoutée.

Pour autant, les partenaires continuaient à fixer l’identité admise, les certificats, les délais de reçu, le traitement des doublons, la conservation et les recours. Le transport devenait substituable ; la responsabilité restait attribuée.

Les sources officielles ne prouvent ni déploiement nommé, ni commande acceptée, ni paiement, ni décision judiciaire. Elles montrent une évolution plus sobre : MIME rendit l’objet transportable, les signatures et MIC rendirent la réception plus vérifiable, et les accords gardèrent le dernier mot commercial.

Sources