Dématérialisation des factures et PDP : quelles solutions d'intégration selon votre version SAP ?

Au-delà des choix stratégiques d’identification des fournisseurs de PDP et de la solution qui va permettre de gérer ce nouveau flux au sein de l’ERP, la problématique d’intégration n'est pas anodine. On observe souvent que les approches d'intégration sont envisagées par habitude plutôt que par stratégie. "Les clients et leurs intégrateurs ont tendance à aller vers les technologies qu'ils connaissent", constate Mikael Thepault, responsable de l’offre SAP BTP au sein de Talan. Sur ECC, "dès que le client va parler d'intégration, pour lui, les données qui vont sortir de SAP seront forcément de la technologie IDOC. Parce que c'est structuré, parce que c'est quelque chose qu'ils maîtrisent.". Cette tendance à reproduire les schémas connus peut cependant s'avérer contre-productive à long terme.

Il convient avant tout de distinguer clairement les deux ERP SAP majoritaires sur le marché : SAP ECC et SAP S/4HANA. « Dans le cas où le client ne souhaite pas évoluer vers SAP DRC (solution proposée par défaut par l’éditeur SAP qui est aussi PDP) nous avons deux approches principales en fonction de l'ERP source et de la version du socle technologique. », explique Mikael Thepault. Cette distinction n'est pas simplement technique, elle reflète deux stratégies d'intégration différentes qui conditionnent l'architecture globale du système d'information.

Pour les systèmes ECC, quelle que soit leur version (de EHP 0 à EHP 8), l'approche recommandée s'éloigne des IDOCs traditionnels. "Sur ECC, on va plutôt partir sur des BAPIs converties en webservices SOAP ou OData, en minimisant ainsi le développement spécifique, et donc la dette technologique pour plus tard", préconise l’expert. Cette stratégie présente un double avantage : elle améliore la sécurité des échanges et prépare le terrain pour une éventuelle migration future vers S/4HANA. "Le fait d'encapsuler la BAPI dans un web service SOAP ou OData va rajouter une couche de sécurité supplémentaire", ajoute-t-il.

Cette orientation vers les web services SOAP/OData plutôt que les IDOCs s'inscrit dans une vision plus large de l'urbanisation du système d'information. Il s'agit de "minimiser l’impact futur du spécifique côté ECC" pour ne pas "transporter une dette technologique lorsque le projet de transformation vers SAP S/4HANA arrivera". L'enjeu est donc autant technique que stratégique : chaque développement d'aujourd'hui doit être pensé en fonction de son impact sur l'architecture de demain.

Du côté de SAP S/4HANA, la situation est sensiblement différente. "Quand vous êtes sur S/4HANA, vous avez déjà des API standards proposées par SAP, prêtes à être consommées et qui seront stables sur le long terme", explique Mikael Thepault. Cette standardisation représente une opportunité majeure pour les entreprises, qui peuvent désormais s'appuyer sur des interfaces documentées et maintenues par l'éditeur lui-même.

Pour les organisations ayant déjà franchi le pas vers SAP S/4HANA, la recommandation est claire : privilégier systématiquement les API standards fournies par SAP plutôt que de développer des interfaces spécifiques. Ces API, conçues selon les meilleures pratiques actuelles, offrent une meilleure sécurité, une maintenance simplifiée et une évolutivité accrue face aux changements réglementaires ou techniques futures. C’est d’ailleurs une tendance lourde d’évolution des systèmes d’information.

Une question légitime se pose alors pour les entreprises encore sur SAP ECC mais projetant une migration vers SAP S/4HANA : faut-il anticiper dès maintenant l'adoption des standards API ? "Dans un système SAP ECC, est-ce qu'il est vraiment pertinent à ce moment-là de développer tout de suite les API qui seront les API futures qu'on pourrait retrouver dans SAP S/4HANA, plutôt que de repartir sur un développement BAPI ?", s'interroge Aurélie Dos Santos, experte fonctionnelle logistique chez TALAN. Cette réflexion prospective mérite d'être menée par chaque organisation selon ses contraintes et son calendrier de migration.

Au-delà des spécificités propres à chaque version de SAP, une constante émerge : l'importance croissante d'un middleware pour orchestrer les flux entre SAP et les autres systèmes (PDP dans le cadre de la facturation électronique). "La voie vers laquelle se diriger, c'est quand même de mettre un middleware entre tout ça, pour monitorer les flux entre le système SAP et la PDP", recommande Mikael Thepault. Cette couche intermédiaire offre plusieurs avantages déterminants : visibilité sur les échanges, sécurisation des flux, capacité de transformation des formats et possibilité de connecter facilement différentes PDP du marché.

L'utilisation d'un middleware comme SAP Integration Suite permet de s’appuyer sur un framework pour orchestrer ces échanges et ouvre également la voie à des architectures événementielles particulièrement adaptées au contexte de la facturation électronique. "Il faut savoir que toute cette architecture événementielle est déjà en standard dans SAP", souligne Mikael Thepault. "Dès que l’on modifie ou que l’on créé un document dans SAP, on peut envoyer un événement pour informer les autres systèmes." Cette approche event-driven représente une évolution significative par rapport aux méthodes traditionnelles : au lieu d'interroger régulièrement le système pour détecter des changements, les applications sont notifiées en temps réel lorsqu'un événement pertinent survient.

Cette capacité événementielle, disponible via des technologies comme SAP BTP Event Mesh "va remplacer tout ce que connaissaient nos clients aussi en termes d'IDOCs", explique Mikael Thepault. Ce changement de paradigme permet une réactivité accrue et une meilleure gestion des ressources système, deux aspects particulièrement importants dans le cadre de la dématérialisation des factures où les délais de traitement peuvent avoir des impacts financiers directs.

La complexité du sujet peut parfois décourager les entreprises d'adopter les approches les plus modernes. "On a une quantité d'acronymes qui nous perdent rapidement entre les systèmes sources, les systèmes cibles, les protocoles, les technologies et les méthodes d'appel, sans compter la prévisibilité des impacts financiers de ces choix", reconnaît Jérôme Mollier-Pierret, Directeur de l’Innovation et des Offres chez TALAN. Face à cette complexité, certaines organisations peuvent être tentées de s'en tenir aux méthodes qu'elles maîtrisent déjà, au risque de perpétuer des architectures sous-optimales.

Développer une vision d'ensemble plus claire représente une opportunité majeure pour susciter l'adhésion au changement. "Les clients n'ont pas forcément la vision globale", observe Mikael Thepault. "Ils n'ont pas toujours conscience non plus des tendances imposées par l’arrivée de solutions Cloud, lié à la consommation de plus en plus importante de solutions SaaS/PaaS", ajoute Jérôme Mollier-Pierret. Cette méconnaissance peut conduire à des choix technologiques qui semblent pertinents à court terme mais qui s'avéreront problématiques dans la durée.

Les conséquences d'une approche non adaptée peuvent être immédiates lors d'une migration vers SAP S/4HANA. "L’un de nos clients en cours de migration vers SAP S/4HANA découvre que certaines de ses solutions spécifiques, basées sur les batch inputs, ne fonctionnent plus. La réécriture est alors subie.", rapporte Mikael Thepault. Ces situations critiques, qui peuvent retarder des projets stratégiques ou générer des coûts imprévus, illustrent l'importance d'anticiper les évolutions technologiques dès la conception des interfaces.

En conclusion, le choix des solutions d'intégration pour la dématérialisation des factures et la connexion aux PDP doit s'inscrire dans une stratégie globale tenant compte non seulement de la version actuelle de SAP, mais aussi des évolutions futures du système d'information. Pour les systèmes ECC, privilégier les BAPIs encapsulées en web services SOAP constitue un compromis raisonnable entre faisabilité immédiate et pérennité. Pour SAP S/4HANA, l'utilisation des API standards s'impose comme la solution la plus adaptée.

Dans tous les cas, l'intégration d'un middleware moderne pour orchestrer les flux représente un investissement judicieux, offrant à la fois une sécurité accrue, une meilleure visibilité et une flexibilité précieuse notamment face aux évolutions réglementaires de la facturation électronique. Cette approche architecturale, bien que demandant un effort initial d'adaptation, constitue aujourd'hui le meilleur moyen d'aborder sereinement les défis d’intégration dans l'écosystème SAP.