Choisir entre API et EDI : arbre de décision pratique

Le débat « faut-il faire de l'EDI ou des API ?» n'est utile qu'à condition de poser les bons critères. Cette page propose cinq questions à se poser dans l'ordre, et un arbre de décision pragmatique pour orienter un choix en contexte.

Une mauvaise opposition

L'opposition « API moderne vs EDI legacy » est mal posée. EDI et API REST sont deux familles techniques qui se recouvrent partiellement : un message EDIFACT peut transiter en HTTPS POST, une API REST peut acheminer un payload UBL aussi bien qu'un JSON propriétaire. Le sujet réel n'est pas le format d'écriture (XML vs JSON vs segments) ni le transport (AS2 vs HTTPS), mais plutôt : qui est le partenaire, quelles contraintes pèsent sur l'échange, et comment minimiser le TCO sur la durée du flux. Voir aussi l'article EDI à l'heure des API pour la discussion étendue.

Critère 1 : qui est le partenaire

La première question est celle du partenaire et de ses préférences techniques. Cinq cas de figure dominent :

• Hub retail ou OEM automotive avec spec propriétaire — la décision est presque toujours faite : le partenaire impose son format (X12, EDIFACT, parfois VDA), son transport (AS2 ou OFTP2) et ses MIC. Le choix se réduit à respecter la spec partenaire.
• Acheteur public ou facturation publique européenne — PEPPOL BIS Billing 3.0 / EN 16931 est probablement la voie obligatoire, avec AS4 eDelivery comme transport. L'API REST classique ne s'applique pas.
• Marketplace e-commerce ou SaaS B2B — l'API REST/webhook est la norme, souvent avec OpenAPI publique et SDK officiel. L'EDI classique ne s'applique pas.
• PME fournisseur ou prestataire de service — souvent pas de préférence forte, le choix doit minimiser leur coût d'intégration (donc souvent API REST si le partenaire est moderne, ou portail web simple si l'investissement IT est faible).
• Banque ou institution financière — souvent ISO 20022 sur EBICS/SWIFT, parfois SFTP. L'API REST progresse via les Open Banking mandates (PSD2 en Europe, équivalents nationaux) mais coexiste avec les protocoles établis.

Critère 2 : y a-t-il un mandat réglementaire

Si un mandat réglementaire impose un format ou un transport spécifique, la décision est verrouillée. Exemples notables en 2026 : ViDA en Europe (EN 16931 obligatoire pour intra-UE à partir de 2030), HIPAA aux États-Unis (X12 5010 obligatoire pour claims/remittance/eligibility), Italie SdI (FatturaPA XML obligatoire pour B2B/B2G/B2C), Espagne SII (rapport transactionnel obligatoire pour TVA), Pologne KSeF (FA(2) obligatoire pour B2B), France PPF/PDP (calendrier 2026-2027), Arabie Saoudite ZATCA (FATOORA), Mexique CFDI 4.0, etc.

En présence d'un mandat, le choix se réduit à la conformité : quel format imposé, quel transport accepté, quel calendrier. La latitude technique se loge dans l'architecture interne, pas dans le contrat externe.

Critère 3 : quelle fréquence d'échange

La fréquence change le profil opérationnel attendu. Trois ordres de grandeur :

• Très haute fréquence (millions de transactions par jour, latence sub-second) — API REST/gRPC ou messaging événementiel (Kafka). Les protocoles EDI traditionnels (AS2 batch) deviennent non-pertinents.
• Fréquence normale (centaines à dizaines de milliers de transactions par jour, latence acceptable de quelques secondes à quelques minutes) — EDI ou API REST sont tous deux viables, le choix se fait sur d'autres critères.
• Faible fréquence ou batch (quelques transactions par jour ou par semaine, latence acceptable en heures) — l'EDI batch (AS2, SFTP) reste optimal : simplicité opérationnelle, faible coût, traçabilité éprouvée.

Critère 4 : sémantique partagée ou propriétaire

Quand vous échangez avec un partenaire pour la première fois, la sémantique partagée est déterminante. EN 16931 et PEPPOL BIS Billing 3.0 imposent un vocabulaire commun à tous les États membres : votre facture est automatiquement interprétable par n'importe quel destinataire conforme. EDIFACT et X12 reposent sur des guides d'implémentation publics : la sémantique est traçable mais nécessite un travail d'interprétation. À l'inverse, une API REST publique est un vocabulaire propriétaire (le vôtre, ou celui du partenaire) : chaque intégration est un projet d'onboarding spécifique.

Si l'écosystème comporte beaucoup de partenaires (typique du retail, du secteur public, de l'invoicing B2B européen), une sémantique partagée standardisée (EDIFACT, X12, EN 16931) minimise le coût d'onboarding. Si l'écosystème comporte peu de partenaires bilatéraux et stables, une API REST propriétaire peut être plus économique.

Critère 5 : exigences contractuelles

Quatre exigences contractuelles peuvent peser sur le choix :

• Non-répudiation cryptographique : AS2 (MDN signé) et AS4 (receipt signé) embarquent une preuve de non-répudiation de réception (NRR) qui n'existe pas nativement dans une API REST. Pour les flux légaux (factures, contrats), c'est souvent décisif.
• Archivage long terme : les flux EDI sont historiquement archivés en formats stables (XML, segments) qui survivent aux générations de plateformes. Les payloads API JSON s'archivent aussi bien mais nécessitent de fixer le schéma au moment de l'archivage.
• SLA contractuel strict : les protocoles EDI matures (AS2, OFTP2) offrent des SLA observables et négociables qui sont plus difficiles à garantir sur une API REST publique (rate limit, throttling, versioning).
• Souveraineté ou confidentialité forte : certaines verticales (défense, énergie critique, santé) excluent les architectures cloud public, ce qui peut favoriser AS2 over VPN privé ou OFTP2.

L'arbre de décision en synthèse

La séquence pragmatique à suivre, dans cet ordre :

1. Le partenaire impose-t-il une technologie ou un format ? → si oui, respecter la spec partenaire.
2. Y a-t-il un mandat réglementaire ? → si oui, respecter le mandat (souvent EDI ou XML standard).
3. La fréquence est-elle très haute avec latence sub-second ? → si oui, API REST/gRPC ou messaging événementiel.
4. Le flux nécessite-t-il non-répudiation cryptographique ou archivage légal long terme ? → si oui, EDI (AS2/AS4 ou équivalent).
5. L'écosystème compte-t-il beaucoup de partenaires hétérogènes ? → si oui, EDI standardisé (EDIFACT, X12, EN 16931). Sinon API REST propriétaire est viable.

Pour aller plus loin

• EDI à l'heure des API — la discussion étendue sur la convergence.
• Architecture d'intégration moderne — le cadre architectural global.
• PEPPOL vs bilatéral — un cas particulier important du même arbre.