Avant d’exposer le propos sur la différence entre l’un ou l’autre. Il faut présenter ce qu’est un TEF (transfert électronique de fonds). 
Il s’agit de tout transfert informatisé effectué par deux banques ou établissements financiers. En d’autres termes, cela désigne les méthodes de transaction numérique, sans l’intervention directe d’une personne. De telle sorte que les TEF peuvent être des virements, des prélèvements, des paiements CCA (Chambre de compensation automatisée), etc.
Les TEF pullulent depuis l’avènement de l’Internet, du commerce électronique et de l’argent liquide numérique. Un projet de numériser l’euro est encours par ailleurs.
Quasiment tous les éléments d’une transaction traditionnelle tendent vers le numérique : les factures, les reçus, les paiements et les systèmes de TEF en sont une composante essentielle.
Dans ce cas pourquoi accepte-t-on encore les transactions de débit numériques, les chèques électroniques… si les cartes de crédit sont si populaires ?
Il faut savoir que près de 55 % des responsables de la chaîne d’approvisionnement ont considéré les Webservices API comme une alternative à l’EDI. Néanmoins, l’idée n’est pas de supplanter l’API par l’EDI, du moins c’est notre point de vue. Ce serait plutôt de parvenir à un nouveau modèle d’intégration sans pour autant rejeter l’EDI
Le développement des interfaces de programmation d’applications et la gestion de celles-ci enrichissent les technologies B2B traditionnelles comme l’EDI. La clé de la réussite est de comprendre la technologie qui répond le mieux au besoin du partenaire commercial. Ainsi, en incluant les capacités API à l’EDI. il sera donc aisé de se connecter et de communiquer avec l’ensemble de l’écosystème de vos partenaires commerciaux.
 Il faut donc bien mettre en avant que l’EDI et l’API, doit être un alliage pour parfaire l’EDI en place.
Il ne faut pas forcément se séparer de l’EDI, tout cela parce qu’une étude financière provenance REUTERS vente les API et les transferts électronique de fonds par ce modèle.
 Il est vrai que les experts ne cessent de vanter les mérites de l’API, du fait que son implémentation est rapide, facile, intelligente et surtout bon marché. Les transmissions des données sont concises et se font en temps réel entre les différentes parties (applications commerciales, API, webservice, ERP, Téléphones, etc.). Les API sont parfaites pour connecter vos systèmes on-premise et/ou en SAAS, et elles peuvent aussi gérer la plupart des interactions B2B que l’EDI peut gérer. Mais, alors pourquoi ne pas utiliser uniquement les API ? Si elle a le vent en poupe, c’est une bonne raison de s’y pencher, non ?

D’un autre côté, l’EDI existe depuis plus de 40 ans et a la réputation d’être une technologie révolue, et pourtant l’EDI reste tenace. Il est fiable et sûr, malgré son âge. Tout comme le protocole du même âge (TCP/IP), qui permet à lui seul de faire tourner l’Internet. Ou encore nos fameux serveur OS400, qu’on tente d’évincer depuis les années 2000

Qu’est-ce qui bloque auprès des entreprises pour sauter le pas ? En France, comme toujours on est à la traine par rapport à nos voisins. On favorise les EDI et on ne trouve pas d’excuse sur cette rigidité maladive de vouloir faire évoluer les systèmes vers l’API. Les organisations disent que l’EDI suffit amplement à répondre aux besoins, tandis que les API demanderaient trop d’investissements coûteux et complexes. De plus, l’EDI est basique et il fonctionne tel quel. Ce genre de mentalité m’inquiète, car il considère l’EDI comme un simple standard qui n’évolue presque plus depuis sa création. Nous avons tendance à confondre la normalisation de sa globalité et que tout part de l’entendement de cette notion. En réalité pour nous, l’EDI est plus vaste que l’API. Dans son sens propre, on dit bien Echanges de Documents Informatisés. Et non cette équation qui semble demeurer dans les esprits EDI = EDIFACT voire X12.

En réalité, si l’on confronte les deux, il n’apparaît clairement qu’aucune des deux technologies n’est parfaite. Chacune a ses forces et ses faiblesses. La vérité est que les forces de l’une compensent souvent les faiblesses de l’autre. Ensemble, elles représentent une solution formidable pour les interactions B2B. D’où mon point de vue précédent.

L’EDI permet l’échange sécurisé d’un large éventail de documents commerciaux dans un format standard qui convient aux partenaires commerciaux. Il peut gérer le traitement par lots dans les volumes nécessaires aux chaînes d’approvisionnement d’aujourd’hui. Et il offre sécurité, traçabilité et fiabilité, ainsi qu’une gamme de services EDI à valeur ajoutée couvrant des domaines tels que la gestion des communautés et l’analyse.

Nonobstant, l’EDI peut avoir du mal à transférer des données en temps réel. Et c’est-là où les API sont fortes, bien qu’elles soient plus faibles dans des domaines tels que la sécurité et les volumes de données. Le fait de communiquer sur l’autoroute de l’Internet effraie plus d’un. L’EDI a su évoluer avec son temps et ses modes communications aussi, mais l’essence de l’EDI a toujours été sécurisé. L’API n’est qu’au début de son avènement, et l’évolution doit suivre son cours en s’inspirant de son grand frère l’EDI.

Avec cette croissance d’API, le prochain défi est de savoir gérer ces niches entre elles. Certain fournisseur d’API sans les citer, dénombre environ 19 millions d’emplacements où seraient stockés des API, type API collections (JAVA). A cette allure, on peut présager que l’EDI demeurera, en soutien des API et de ses propres lacunes. Seul l’avenir nous le confirmera, n’est-ce pas ?

Au départ, il s’agit juste d’une réflexion sur l’idée du meilleur choix d’une plateforme d’intégration EDI

Et comme évoqué précédemment, l’EDI a résolu, il y a bien longtemps, le défi que peut représenter la gestion de multiples connexions. Les RVA (Réseaux à Valeur Ajoutée) ont été développés pour permettre une connectivité multiple sans se soucier des normes et des formats de l’organisation avec laquelle se fera l’échange de flux.

Les plateformes d’intégration EDI ont évolué au fil des ans. En effet, Il est désormais beaucoup plus simple d’embarquer et de commencer à échanger des informations avec de nouveaux partenaires commerciaux. Par ailleurs, ces plateformes ont évolué pour offrir des plateforme d’intégration en tant que service, en unifiant l’intégration et la gestion des données en une seule plateforme, quelle que soit la source. Des telle sorte que l’on regroupe les capacités EDI et API, dans l’objectif de créer un modèle B2B plus riches et plus connectées dans l’écosystème de chaque partenaire commercial. Voilà, notre conclusion de l’apport de l’API sur l’EDI, qui se solde par une combinaison visant la réussite

Il faut savoir que la perte d’un contrat car l’utilisation d’un ERP ou WMS/TMS ne supportant pas les échanges via API m’a poussé à écrire ce post, en montrant que via l’EDI on peut pallier les deux. En prenant, le sujet dans le bon sens, il y a toujours une possibilité de répondre à l’appel d’offre, toutefois vous vous devez d’assurer la faisabilité en recherchant toujours le plus simple, et c’est d’ailleurs cette vision que nous à MARYNSOFT par notre leitmotiv : « L’essence de tout projet se tient à l’observation »