Interfaces ERP : EDI, API, iPaaS et e-facturation
Tout ERP de PME ou d'ETI se trouve au centre d'un réseau d'interfaces. Les commandes arrivent depuis les boutiques en ligne et les marketplaces, les stocks circulent vers un système de gestion d'entrepôt, les écritures sont transmises à l'environnement de l'expert-comptable, les partenaires commerciaux échangent en EDI, et les services cloud consomment les données de l'ERP via REST ou GraphQL. La manière dont un ERP expose ses interfaces détermine silencieusement si le déploiement reste moderne au quotidien. Cette page décrit le paysage des interfaces ERP pertinentes pour les organisations opérant en France, en mettant l'accent sur les ancrages réglementaires tels que la facturation électronique (Factur-X et la plateforme publique Chorus Pro), l'archivage à valeur probante, les obligations de la loi anti-fraude à la TVA pour les systèmes de caisse, et les régimes OSS/IOSS pour la TVA transfrontalière.
EDI : EDIFACT, OFTP2 et AS2
L'échange de données informatisé reste le protocole d'intégration dominant pour les flux B2B entre partenaires commerciaux dans la distribution, l'automobile et les achats industriels. EDIFACT est le standard de message prédominant, avec les sous-ensembles VDA et GALIA/Odette dans l'automobile. La couche de transport est généralement OFTP2 dans l'automobile et AS2 ou AS4 dans la distribution. Les grandes enseignes françaises comme Carrefour, Auchan ou Système U, ainsi que les constructeurs automobiles, maintiennent des guides d'implémentation détaillés, et l'intégration de nouveaux partenaires nécessite généralement un mappage par partenaire. En France, l'obligation progressive de facturation électronique interentreprises (B2B) et l'usage de Chorus Pro pour le secteur public (B2G) ajoutent une couche spécifique : les administrations exigent des factures structurées au format Factur-X, et les flux passeront par des plateformes de dématérialisation partenaires (PDP). L'EDI est rarement développé en interne dans les PME et ETI ; des prestataires spécialisés tels que Generix, Tenor, SEEBURGER ou l'autrichien ecosio exploitent des plateformes EDI hébergées dans le cloud, avec des modèles pré-mappés pour les principaux partenaires du marché.
API-first : REST et GraphQL
Les ERP cloud modernes exposent des API REST comme surface d'intégration principale, une part plus réduite mais croissante d'éditeurs proposant GraphQL. La qualité varie fortement : SAP S/4HANA Cloud, Microsoft Dynamics 365 Business Central, NetSuite, Cegid, Sage et Odoo publient des API complètes, versionnées et accompagnées de portails développeurs, tandis que certains éditeurs on-premise conservent d'anciennes interfaces SOAP ou par fichiers aux côtés d'une surface REST partielle. Les acheteurs doivent évaluer non seulement l'existence d'une API, mais aussi sa couverture d'objets, son modèle d'authentification, ses limites de débit, la disponibilité d'un environnement de test et sa discipline de versionnement. Les API à elles seules ne constituent pas une intégration ; elles sont le substrat sur lequel se construisent les middlewares, les flux iPaaS ou les connecteurs sur mesure.
Plateformes middleware iPaaS
L'intégration en mode plateforme-as-a-service fait passer le modèle d'intégration des interfaces point à point sur mesure à des flux déclaratifs exploités comme un service managé. Les plateformes mondiales établies incluent Boomi, MuleSoft (propriété de Salesforce) et Workato ; des alternatives pour le mid-market telles que Celigo, elastic.io et n8n (open source avec une offre hébergée) couvrent un périmètre similaire à un prix d'entrée plus bas. Pour les organisations exploitant plus d'une poignée de points d'intégration, l'iPaaS réduit la charge de maintenance à long terme grâce à une supervision centralisée, au contrôle de version, à la relecture des erreurs et à une bibliothèque de connecteurs préconçus. Les contreparties sont la dépendance à la plateforme (lock-in) et un coût d'abonnement récurrent généralement indexé sur le nombre de connexions ou le volume de transactions. Un iPaaS ne remplace pas la conception de l'intégration : une organisation qui ignore quelles données font foi dans quel système ne fera que rendre cette confusion plus coûteuse.
L'interface comptable et l'e-facturation : une exigence française
En France, l'échange de données avec l'expert-comptable et l'administration fiscale repose sur des formats normalisés : le Fichier des Écritures Comptables (FEC) exigé par l'administration, les exports vers les logiciels de cabinet, et désormais la facturation électronique au format Factur-X transitant par Chorus Pro pour le secteur public et par les plateformes de dématérialisation partenaires (PDP) pour le B2B. Une interface comptable robuste est donc une fonctionnalité quasi obligatoire pour tout ERP vendu en France. Des interfaces natives sont courantes dans les produits localisés pour le marché français tels que Cegid, Sage 100, Divalto ou EBP. Les ERP internationaux (SAP, Microsoft Dynamics 365, NetSuite, Oracle) s'appuient généralement sur un connecteur conçu par un partenaire pour le FEC et la conformité française. Les acheteurs doivent vérifier que l'interface prend en charge la version actuelle des formats réglementaires, gère les flux bidirectionnels, couvre les types de documents pertinents et est décrite dans une documentation de procédure conforme aux exigences d'archivage à valeur probante. Cadre de décision entre développement interne, achat et iPaaS : développer en interne uniquement lorsque l'intégration encode un processus réellement concurrentiel, acheter un connecteur packagé pour les flux standards comme le FEC ou Factur-X, et recourir à un iPaaS dès que le nombre d'intégrations fait de la maintenance par flux le coût dominant.