Échange de données informatisé (EDI) : Conclusion

1.1 - Permanence de la fonction de l’EDI

Tableau 1
1.2 - EDI classique : RVA et Edifact pour les grands comptes donneurs d’ordres

Tableau 2
1.3 - EDI classique Edifact demain, avec Internet, Web et XML

2 - Acquis et limites d’Edifact

2.1 - EDI classique standardisé d’en haut (top down)
2.2 - Que garder d’Edifact ?
2.3 - Edifact sur Internet

3 - Approche XML partant de l’utilisateur (bottom up)

3.1 - DTD-schémas et namespaces pour « eXtensibility » avec « reusability »
3.2 - Outils de mise en œuvre de XML
3.3 - Langages XML métiers, frameworks et référentiels

Figure 4 - ebXML

4 - Irruption attendue des Services Web (Web services)

4.1 - Naissance difficile
4.2 - Standardisation foisonnante des Services Web

Figure 5 - Message SOAP Figure 6 - Standards WS-*
4.3 - Apparition de la SOA (Services Oriented Architecture )

5 - Conclusion

Présentation

RÉSUMÉ

L’échange de données informatisé (EDI) installé depuis de nombreuses années constitue encore la plus grande partie des échanges électroniques, dès l’instant où ces échanges sont répétitifs et justifient d’être dématérialisés et automatisés. Pour le moment, la montée en puissance de l’Internet ne menace pas l’EDI, qui n’affiche aucune perte de vitesse avec le développement du commerce électronique et de la société de l’information, bien au contraire. Pourtant, la présence de XML dans toutes les fonctions du système d’information des entreprises et organisations finira par se traduire dans un nouvel EDI, même si cette migration reste lente.

Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.

Lire l’article

Auteur(s)

Claude CHIARAMONTI : EDItorialiste de la lettre VendrEDI - Membre d’honneur d’Édifrance

INTRODUCTION

Au début des années 1990, l’EDI était le sigle à la mode, porteur de la modernité d’une informatique qui devenait un outil de communication standardisé entre entreprises. Le sigle EDI, « Electronic Data Interchange », se conserve en français avec comme traduction Échange de Données Informatisé : à noter que c’est l’échange qui est informatisé, pas seulement les données. Ne serait-ce cette préoccupation de conserver le sigle anglais, on pouvait plus simplement parler d’échange électronique de données.

On ne parlera pas ici des échanges de données techniques qui ont leur sigle, EDT, leur norme, STEP, et leur problématique propre, pour s’en tenir aux échanges électroniques de données structurées relatives à l’administration, au commerce et au transport, selon la déclinaison d’origine du sigle Edifact, Electronic Data Interchange For Administration, Commerce and Transport.

EDI à l’heure d’Internet, de XML et des Services Web (Web Services)

Avec Internet, le Web et XML, l’EDI, jusqu’à présent centré sur les grands comptes donneurs d’ordres, va pouvoir pénétrer le tissu des PME et, après avoir été le précurseur du B2B, en rester l’épine dorsale pour être le « back office » du commerce électronique.

Car la fonction de l’EDI, rationaliser, codifier et automatiser des transactions répétitives entre applications d’entreprises différentes, ne peut que prendre de l’importance avec le commerce électronique et la société de l’information.

L’EDI classique installé va continuer à se renforcer en continuant à utiliser la norme Edifact. Mais si XML devient le liant entre tous les types d’applications, il sera de plus en plus difficile de ne pas passer de la syntaxe Edifact au métalangage XML.

Cette migration sera d’autant moins coûteuse pour les quelques 40 000 entreprises françaises déjà « édifiées » qu’elle préservera l’acquis d’Edifact : l’analyse des processus d’affaires et la sémantique des codifications utilisées.

Passer à XML et à ses outils apportera deux grands bénéfices : d’une part intégrer l’EDI, jusqu’ici marginalisé, parmi les outils de communication de l’entreprise, y compris places de marché et catalogues électroniques, d’autre part ouvrir l’EDI sur de nouveaux partenaires sur le Web.

Reste à XML à stabiliser les spécifications de ses outils et aux utilisateurs à enregistrer leurs profils de mise en œuvre pour concilier la liberté « eXtensible » de XML avec la possibilité de réutiliser ce qui existe déjà.

Reste aussi aux utilisateurs à choisir sous quelle forme ils souhaitent prolonger l’EDI classique : un framework « top down » de type ebXML, RosettaNet etc. ou le cadre plus souple des Services Web basé sur les standards SOAP, WSDL, UDDI et BPEL.

Cet article est réservé aux abonnés.
Il vous reste 93 % à découvrir.

Pour explorer cet article Consulter l'extrait gratuit

Déjà abonné ? Se connecter

DOI (Digital Object Identifier)

https://doi.org/10.51257/a-v1-h7408

CET ARTICLE SE TROUVE ÉGALEMENT DANS :

Accueil > Ressources documentaires > Archives > [Archives] Documents numériques - Gestion de contenu > Échange de données informatisé (EDI) > Conclusion

Lecture en cours
Présentation

Page
suivante

EDI classique, précurseur du B2B

Article inclus dans l'offre

"Traçabilité"

(52 articles)

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques.

Des contenus enrichis

Quiz, médias, tableaux, formules, vidéos, etc.

Des modules pratiques

Opérationnels et didactiques, pour garantir l'acquisition des compétences transverses.

Des avantages inclus

Un ensemble de services exclusifs en complément des ressources.

Voir l'offre

5. Conclusion

Précurseur du B2B, né dans le milieu de la simplification des procédures du commerce international, l’EDI classique en Edifact fait le gros dos depuis l’apparition d’Internet. La mort de l’EDI a été maintes fois annoncée, en particulier lors de l’irruption de XML. Pourtant, l’EDI classique installé depuis des années constitue toujours, en 2005, la plus grande partie des échanges électroniques automatisés entre entreprises. En Europe comme aux États-Unis en Ansi X12, standard équivalent à Edifact : « If it works, don’t fix it ! » on ne change pas un système que l’on a mis du temps à faire bien marcher. Et des extensions voient encore le jour en EDI classique, alors que dans des domaines, ou des pays, où cet EDI classique n’est pas présent, son étape est sautée pour aller directement à XML et aux Services Web.

L’irrésistible irrigation par XML de toutes les fonctions du système d’information des entreprises et organisations finira par se traduire aussi dans un EDI en XML. Seulement, cette migration continue à être lente et emprunte des voies progressives :

le Web EDI né avant XML dans la grande distribution, puis l’automobile, adapté pour des transactions avec des fournisseurs occasionnels ne souhaitant pas un EDI automatisé rentable surtout pour grands donneurs d’ordres et fournisseurs réguliers ;
EDI en Edifact, mais sans RVA onéreux, remplacé par un des protocoles sécurisés EDIINT (EDI sur Internet), AS1, AS2 ou AS3, qui ont des fonctionnalités complémentaires ;
simple traduction « à la volée » des messages Edifact en XML (et l’inverse), ne serait-ce que pour permettre à des nouveaux venus dans une Communauté EDI d’éviter Edifact s’ils pratiquent déjà XML. D’ailleurs, toutes les plates-formes EDI sont depuis longtemps multiformats, depuis les formats de l’EDI classique jusqu’à XML et à ses langages-métiers ;
migrer d’un Edifact « rigide » vers un langage-métier XML existant, en pouvant l’adapter à son business avec ses partenaires, XML étant un métalangage « eXtensible ». Mais sans plus avoir besoin d’un logiciel « traducteur » ni de spécialistes en Edifact : Windows ou Linux, de même que les développeurs, « parlant » déjà...