Connecter SAP sans y toucher : comment intégrer votre boutique, votre banque et vos partenaires sans laisser de développements qui gênent

En 1 minute

Connecter quelque chose à SAP oblige à deux décisions : par quel mécanisme on entre, et où vit la logique de chaque canal. Le raccourci — un programme maison, couplé aux entrailles de SAP — paraît plus rapide et se paie à la mise à jour suivante. SAP le dit avec ses mots : ce qui s'appuie sur ses interfaces publiées est ce qui résiste le mieux à une mise à jour. Cet article explique, dans le langage d'un comité de direction, quelles portes existent, quand chacune convient et quoi demander avant d'approuver la prochaine intégration.

Imaginez une entreprise de taille moyenne qui tient sa comptabilité, ses stocks et sa facturation dans SAP. Elle est fictive, mais elle ressemble à beaucoup d'autres. Un jour, trois demandes arrivent à l'équipe informatique, presque en même temps :

• Le commercial veut que la boutique en ligne envoie chaque commande à SAP et consulte le prix et le stock.
• La finance veut que le relevé bancaire soit rapproché de ce que SAP a en créances.
• Les ventes veulent qu'un partenaire distributeur puisse envoyer ses commandes depuis son propre système.

Les trois sont raisonnables. Et les trois cachent la même question : où la connexion va-t-elle vivre ?

La réponse rapide est souvent « dans SAP, comme on peut » : un programme sur mesure qui lit le fichier de la banque, une nouvelle table pour les commandes de la boutique, un ajustement d'un processus standard pour le partenaire. Cela marche, et vite. Le coût n'apparaît pas le jour de la livraison. Il apparaît le jour où il faut mettre SAP à jour, et où quelqu'un découvre que chacun de ces développements doit être revu, testé et, parfois, refait.

Cet article s'adresse à ceux qui dirigent l'informatique, la finance ou les opérations d'une entreprise qui utilise SAP et doit y connecter davantage de choses ; le raisonnement vaut aussi pour d'autres ERP d'éditeur. Il défend une idée : la connexion passe par les portes que l'éditeur prend en charge, et ce qui appartient à chaque canal vit, en règle générale, en dehors de l'ERP. Ce n'est pas seulement une préférence d'architecture : SAP recommande de séparer ce qui est ajouté et de s'appuyer sur ses interfaces publiées pour réduire la dette technique et faciliter les mises à jour [1][2].

Ce n'est pas un article sur le choix entre une connexion en ligne ou asynchrone ; c'est le sujet de En ligne ou asynchrone ?. Ici, la question est autre : par quelle porte entrer dans SAP, et ce qui reste dehors.

Le coût se paie à la mise à jour suivante

SAP le répète à ses clients depuis des années, sous un nom : cœur propre (clean core). L'idée est de séparer ce que chaque entreprise ajoute de ce que SAP livre, pour qu'une mise à jour ne casse pas ce qui a été ajouté et que ce qui a été ajouté ne casse pas la mise à jour. Une présentation publique de consultants de SAP le résume ainsi : les extensions maison ne doivent pas casser une mise à jour, ni les mises à jour une extension, et pour cela on les sépare en s'appuyant sur les interfaces publiées de SAP ; et mieux vaut éviter les extensions quand c'est possible (traduction libre) [2].

Son matériel de formation est encore plus clair sur l'ancienne voie. Il décrit la façon traditionnelle de programmer dans SAP comme un code « étroitement couplé au système », qui « pouvait poser problème lors d'une mise à jour » et qui était donc recommandé « en dernier recours » (traduction libre) [1]. Aujourd'hui, pour SAP S/4HANA, SAP classe les extensions en quatre niveaux, de A à D : le niveau A utilise des interfaces et des points d'extension publiés et c'est celui qui donne la plus grande stabilité lors des mises à jour, que ce soit en dehors de SAP ou à l'intérieur avec les outils que SAP admet ; et une extension est notée d'après la technologie du niveau le plus bas qu'elle utilise [1].

Dit dans le langage d'un comité : chaque développement couplé aux entrailles de SAP est une dette qui se paie, avec intérêts, lors des mises à jour. On ne peut pas tous les éviter. Mais chacun devrait avoir une raison écrite. Et même quand tout est en ordre, chaque mise à jour se teste : ce qui change, c'est la quantité de choses à revoir.

Les portes que SAP possède déjà

SAP n'est pas fermé. Il dispose de plusieurs mécanismes d'intégration — ici, nous les appelons des portes —, et chacun sert à quelque chose de différent. Le comité n'a pas besoin de savoir comment ils fonctionnent à l'intérieur ; il lui est utile de savoir qu'ils existent et de demander par lequel on va entrer. Lesquels sont disponibles, et pour quelles opérations, dépend du produit et de la version de SAP dont vous disposez.

Et une porte qui n'est pas dans la liste : écrire directement dans les tables de SAP. Elle est tentante parce qu'elle semble la plus courte, et elle gêne parce qu'elle peut contourner les contrôles avec lesquels le processus métier de SAP protège ses propres informations.

La page technique de Hábil MDW le dit en une phrase : pour les ERP, nous privilégions les interfaces que l'éditeur prend en charge — dans SAP, par exemple, JCo, OData, IDoc ou REST —, pour ne pas vous laisser de développements qui gênent ses mises à jour.

Ce qui reste dans SAP et ce qui reste dehors

Entrer par la bonne porte, c'est la moitié du chemin. L'autre moitié consiste à décider quelle logique vit dans SAP et laquelle vit dehors. Une règle utile :

• Dans SAP reste ce que SAP fait bien et ce que la loi ou l'audit demandent à SAP : la comptabilité, le stock officiel, la facturation, le client et l'article tels que l'ERP les connaît.
• Dehors reste ce qui appartient à chaque canal ou à chaque partenaire : le format de fichier de chaque banque, les règles de la boutique en ligne, la traduction de ce qu'envoie chaque distributeur, les nouvelles tentatives, la trace de ce qui a été envoyé et de ce que SAP a répondu.

Ces nouvelles tentatives et cette trace sont aussi ce qui fait tenir la vente le jour où l'ERP ne répond pas ; c'est le sujet de L'ERP est tombé samedi.

SAP a un nom pour la seconde partie : les extensions côte à côte (side-by-side), qui tournent en dehors de l'ERP et s'y connectent [2]. Ce n'est pas la seule voie propre — SAP admet aussi des extensions dans l'ERP quand le cas exige ce couplage et qu'elles sont construites avec ses outils publiés [1] —, mais pour ce qui appartient à chaque canal, c'est en général celle qui convient le mieux. L'avantage pour l'entreprise est double. Il reste moins de code maison dans l'ERP, donc moins de choses à revoir à chaque mise à jour. Et un nouveau canal change surtout la couche extérieure ; dans SAP, tout au plus, une donnée de base ou un paramétrage.

Les trois demandes, résolues par la bonne porte

Revenons à l'entreprise fictive.

La boutique en ligne. Chaque commande entre dans SAP par une interface publiée, avec un numéro de référence unique vérifié avant de l'enregistrer, pour qu'une nouvelle tentative ne la duplique pas : l'interface n'apporte pas cela, cela se conçoit. Le prix et le stock se consultent par la même voie, si la version de SAP la propose ; si la boutique les consulte de nombreuses fois par minute, il vaut mieux que la couche extérieure en garde une copie, avec une fréquence de rafraîchissement convenue, pour ne pas faire porter chaque visite à SAP. La logique du panier, les bons de réduction et les avis au client restent dans la boutique ou dans la couche extérieure, pas dans SAP.

La banque. La banque envoie son relevé sous forme de fichier, dans son format. La couche extérieure le récupère, le valide, le traduit et fait le rapprochement avec ce que SAP a en créances. SAP ne reçoit que ce qu'il doit enregistrer, par sa porte officielle. Si demain une deuxième banque arrive avec un autre format, on l'apprend à la couche extérieure ; dans SAP, tout au plus, on crée le compte.

Le partenaire distributeur. Le partenaire entre par une porte avec sa propre identité et ses propres permissions, envoie ses commandes dans son format, et la couche extérieure les traduit en commande que SAP connaît. Si le partenaire change de système, on ajuste la traduction ; SAP reste le même.

Dans les trois cas, SAP fait ce qu'il fait le mieux. Au moment de le mettre à jour, on teste les trois connexions, mais il n'y a pas trois développements maison cachés à l'intérieur à revoir un par un.

Quand la porte nécessaire n'existe pas

Il arrive qu'il n'y ait pas d'interface publiée pour ce dont on a besoin, surtout dans les anciennes versions de SAP. Cela n'oblige pas à entrer dans SAP d'emblée. SAP publie lui-même un guide pour ce cas : envelopper une fonction classique — son exemple est une BAPI qui crée des demandes d'achat — dans une interface maison, petite et documentée, publiée pour que le nouveau développement l'utilise ; la fonction en dessous reste classique, et SAP la classe au niveau B [1][6]. Le même groupe de tutoriels montre ensuite comment remplacer cette enveloppe par l'interface publiée que SAP a sortie pour ce processus [6]. Sa foire aux questions ajoute une mise en garde utile : regrouper plusieurs fonctions classiques dans une seule enveloppe empêche de la retirer plus tard, quand SAP publie l'interface de l'une d'elles, et mélange les responsabilités (traduction libre) [7].

Dit dans le langage d'un comité : s'il faut entrer par une porte qui n'est pas celle du premier niveau, on le fait exprès, à un seul endroit, avec un nom et un responsable, en vérifiant à chaque version si SAP propose déjà une alternative publiée.

Les risques, dans le langage de l'entreprise

Cinq questions pour votre prochain comité

1. Combien de développements maison votre entreprise a-t-elle dans SAP pour connecter d'autres systèmes, et qui les connaît ? Si personne ne peut répondre avec une liste, c'est le premier constat.
2. Lors de la dernière mise à jour de SAP, combien de ces développements a-t-il fallu revoir ou refaire, et combien de temps cela a-t-il pris ?
3. Pour la prochaine intégration à approuver, par quelle porte de SAP va-t-elle entrer ? Demandez-le par écrit : interface publiée, fonction distante, document d'échange ou fichier — et quel processus de SAP le reçoit —, et pourquoi.
4. Quelque chose écrit-il directement dans les tables de SAP ? Si la réponse est « je ne crois pas », cela vaut la peine de le vérifier.
5. Si demain une nouvelle banque ou un nouveau partenaire arrive, que faut-il changer dans SAP ? Une donnée de base ou un paramétrage, c'est normal. Si la réponse est « un nouveau programme », la logique de chaque canal vit probablement au mauvais endroit.

Si plusieurs réponses sont « je ne sais pas », prenez-le comme un signal pour faire l'inventaire avant d'approuver la prochaine intégration.

Par où commencer cette semaine

Faites l'inventaire des connexions de SAP. Une feuille, une ligne par connexion, avec cinq colonnes :

• Quel système se connecte : boutique, banque, partenaire, autre ?
• Par quelle porte entre-t-il : interface publiée, fonction distante, document d'échange, fichier ou directement dans les tables ?
• La logique de ce canal vit-elle dans SAP ou dehors ?
• Qui la maintient, et est-elle documentée ?
• A-t-elle cassé, ou a-t-il fallu la revoir, lors de la dernière mise à jour ?

La feuille qui en résulte montre, avec des faits, quelles connexions dépendent de code maison dans SAP et aide à décider par où il convient de commencer à sortir de la logique. Elle fonctionne avec n'importe quel outil, ou sans aucun.

Ce que fait Hábil

Chez Hábil, nous construisons sur mesure l'intégration entre SAP — ou l'ERP que vous avez — et ce qui l'entoure : la boutique, les banques, les partenaires et les canaux. Nous le faisons en entrant par les portes que l'éditeur prend en charge et en laissant dehors ce qui appartient à chaque canal.

Si votre inventaire montre des connexions qui dépendent de développements maison dans SAP, la proposition se trouve dans Hábil MDW. Il se connecte à votre ERP et à vos canaux par les voies que chacun possède déjà, convertit ce qui arrive dans un même langage et enregistre ce qui s'est passé, quand et qui l'a fait. Pour les ERP, nous privilégions les interfaces que l'éditeur prend en charge, pour ne pas vous laisser de développements qui gênent ses mises à jour. Banques, magasins, agents et distributeurs se connectent avec leur propre identité et leurs propres permissions. Le périmètre, les portes utilisées et l'ordre dans lequel on sort de la logique de SAP se revoient avec votre cas.

La conversation peut commencer avec votre inventaire, même à moitié fait : ce qui se connecte, par quelle porte et ce qui a cassé lors de la dernière mise à jour. Avec cela, nous voyons ensemble par où il convient de commencer. Écrivez-nous sur WhatsApp ; pour protéger vos informations, ne partagez pas par ce canal de données sur vos systèmes ni sur vos clients : nous conviendrons dans la conversation du canal adapté au cas.

Demandez votre première conversation, sans frais.

Consultées le 12 novembre 2026. Chaque référence indique sa fiabilité : élevée (source primaire lue).