Intégration ERP : connecter SAP et Dynamics à des logiciels personnalisés

L'intégration d'un logiciel sur mesure dans un système ERP détermine souvent si une nouvelle application sera réellement utilisée au quotidien ou si elle restera une solution isolée, parallèlement à SAP ou Dynamics 365. Quiconque connecte un logiciel sur mesure à un système ERP existant doit prendre très tôt une décision fondamentale : une connexion directe aux interfaces du fabricant ou l’interposition d’une couche de middleware.

Intégration ERP pour les logiciels sur mesure : connexion directe ou middleware

Dans le cas d'une connexion directe, le logiciel sur mesure communique directement avec les interfaces du système ERP, sans couche logicielle intermédiaire. Cela permet de réduire les coûts d'infrastructure et de licence, mais rend le logiciel sur mesure plus étroitement lié à la version et aux spécificités du système ERP concerné. Un middleware dissocie les deux systèmes, ce qui entraîne des coûts supplémentaires d'exploitation et de maintenance, mais rend en contrepartie le logiciel sur mesure plus indépendant d'un éventuel changement ou d'une mise à jour ultérieure du système ERP.

Dans le cas d'une interface unique et clairement délimitée, la connexion directe l'emporte généralement dans la pratique. Lorsque plusieurs systèmes ont besoin des mêmes données, il est préférable d'opter pour une couche middleware, car les modifications peuvent alors être répercutées à un seul endroit plutôt que dans plusieurs applications. Un autre facteur à prendre en compte est l'équipe du donneur d'ordre. Lorsque personne ne gère en permanence les interfaces ERP, un middleware doté de son propre système de surveillance allège une partie de cette charge, qui, sinon, incomberait au logiciel sur mesure lui-même.

Technologies d'interface chez SAP

Trois technologies principales sont disponibles pour l'interfaçage avec les systèmes SAP. BAPI est la technologie d'interface classique et bien documentée, principalement utilisée dans les environnements SAP plus anciens. OData est adaptée aux accès web orientés ressources et est elle-même utilisée par les interfaces SAP modernes. Le Norme OData est défini de manière indépendante des éditeurs, ce qui facilite la connexion avec des systèmes extérieurs à l'écosystème SAP. Les interfaces REST viennent compléter ces deux solutions en apportant une norme légère et largement répandue, qui s'intègre facilement à presque tous les logiciels personnalisés.

Le modèle de programmation RESTful ABAP permet en outre de créer une « façade » qui réduit l'interface API visible de l'extérieur au strict nécessaire pour le logiciel personnalisé et masque la complexité interne du système SAP qui se cache derrière. Pour un projet d’intégration, cela se traduit par une surface d’attaque réduite et une interface plus claire, mais aussi par un effort de développement supplémentaire du côté de SAP, qui doit être pris en compte dans la planification. Avec Microsoft Dynamics 365, la connexion s’effectue généralement via l’interface Dataverse ou directement via des points de terminaison OData, qui ne sont techniquement pas sans rappeler leur équivalent SAP, même si le modèle de données et le concept d’autorisation diffèrent.

La numérotation décalée dans S/4HANA : un piège pour les projets d'intégration

Un détail souvent négligé dans les projets d'intégration est ce qu'on appelle la « numérotation tardive » (Late Numbering) dans S/4HANA. Selon une classification technique tirée de la Communauté SAP À partir de 2023, pour certains documents, les clés définitives, telles que les numéros de document, ne sont déterminées qu’après la comptabilisation effective, et non pas dès leur création. Pour un logiciel personnalisé qui repose sur un identifiant fixe et immédiatement disponible, cela peut entraîner des incohérences s’il enregistre l’identifiant provisoire et que la pièce en reçoit un autre lors de la comptabilisation.

Les projets d'intégration doivent prévoir ce cas dès le départ, par exemple en ajoutant une étape de rapprochement supplémentaire après la comptabilisation ou en utilisant un numéro de référence spécifique, indépendant de SAP, qui ne sera associé à la clé définitive qu'a posteriori. Ceux qui ne s’en aperçoivent qu’au cours du développement prévoient généralement plusieurs semaines supplémentaires pour les retouches, car les modèles de données et les cas de test concernés ne peuvent être corrigés a posteriori qu’au prix d’un surcroît de travail.

Combien coûte réellement une migration vers S/4HANA ?

Selon une étude réalisée par VendorBenchmark en 2025, les coûts d'un projet S/4HANA dépendent principalement de quatre facteurs : la quantité de code développé en interne, du nombre d'interfaces, de la qualité des données dans les systèmes existants et du modèle d'exploitation choisi, par exemple le cloud ou sur site. Le facteur de la qualité des données est souvent sous-estimé. Les données de base, qui ont été gérées en parallèle dans plusieurs systèmes pendant des années, contiennent presque toujours des doublons et des entrées contradictoires qui doivent être corrigées avant toute intégration ; sinon, le nouveau logiciel sur mesure reprendra ces erreurs sans les vérifier.

Il n'est toutefois pas possible d'en déduire une fourchette de coûts universelle. Chaque environnement ERP a évolué différemment au fil des années, avec des adaptations différentes, des interfaces différentes et une qualité des données différente. Il n’est donc possible d’estimer de manière réaliste l’effort nécessaire à sa propre intégration qu’après un examen des interfaces réellement concernées, et non pas à l’avance de manière forfaitaire sur la base d’un indicateur général. L’article explique comment classer ces facteurs de coûts cachés dans les domaines de l’intégration, de la maintenance et de la gestion du changement. Coûts cachés dans les projets logiciels : intégration, maintenance, gestion du changement.

La manière dont il est possible de limiter dès le départ l'effort nécessaire pour chaque interface dépend également du fait qu'une entreprise ait déjà adopté une architecture « API-first » ou qu'elle n'ait jusqu'à présent développé des interfaces qu'au cas par cas, en fonction des besoins. Dans le premier cas, de nombreux éléments peuvent être réutilisés ; dans le second, l'intégration ERP part souvent de zéro.

Foire aux questions

Connexion directe ou middleware ?

Dans le cas d’un logiciel spécifique accédant à un seul et même système ERP, une connexion directe constitue généralement la solution la plus pragmatique, car elle engendre moins de charges d’exploitation. Dès que plusieurs systèmes ont besoin des mêmes données ERP ou qu'un changement de système ERP est prévisible à moyen terme, un middleware compense généralement cet effort supplémentaire. Il n'existe pas de recommandation générale valable dans tous les cas ; la décision dépend de l'environnement informatique concret.

Combien coûte une interface ?

Il est difficile de répondre sérieusement à cette question sans examiner le système en question. Une interface BAPI ou OData unique et bien documentée, avec un volume de données raisonnable, nécessite un effort considérablement différent de celui requis pour une interface qui doit tenir compte d'une logique spécifique issue de l'évolution historique du système, d'une mauvaise qualité des données ou de la « Late Numbering » décrite. On ne peut obtenir des chiffres réalistes qu’une fois qu’une équipe de développement a effectivement examiné les interfaces concernées. Les devis qui avancent un chiffre fixe avant cet examen intègrent généralement une majoration pour risque qui s’avère inutilement élevée dans le cas d’une interface bien préparée.

Quels changements S/4HANA apporte-t-il ?

Outre certaines questions techniques telles que la « Late Numbering », c'est surtout l'architecture d'intégration recommandée qui évolue. Avec S/4HANA, SAP mise davantage sur des interfaces clairement délimitées et documentées via le modèle de programmation ABAP RESTful, plutôt que sur l’accès direct aux tables internes, comme c’était encore parfois le cas dans les anciens environnements SAP. Pour les entreprises qui migrent vers S/4HANA, cela implique souvent une refonte en profondeur des connexions existantes avec les logiciels personnalisés, allant bien au-delà d’une simple migration technique.

Torck construit Logiciels sur mesure pour l'industrie et le commerce, qui s'intègre généralement à SAP, Dynamics 365 ou à des systèmes ERP similaires, il n'existe pas de domaine dans lequel les efforts nécessaires puissent être estimés de manière fiable sur la planche à dessin. Les équipes de développement de Maxhütte-Haidhof, Vienne et Rabat examinent donc, avant chaque devis, les interfaces réellement concernées, au lieu de se baser sur un chiffre forfaitaire. Les contrats sont conclus par la société allemande torck GmbH, ce qui apporte une sécurité supplémentaire dans le cadre de projets d'intégration s'étalant sur plusieurs années. Un Premier entretien indique quel niveau d'effort est réaliste pour son propre environnement ERP.

Prendre rendez-vous