Intégrateur SAP
Intégration de l'API SAP dans votre système
Nous branchons SAP S/4HANA à votre portail B2B, votre e-commerce ou votre app terrain : la commande crée la pièce, le stock et l'ATP restent ceux de S/4. Un seul SI pour la France et l'international.
- Équipe produit senior
- connecteurs ERP en production
- du cadrage au monitoring
Pourquoi faire appel à un intégrateur SAP et que peut-on connecter à SAP ?
SAP est l'ERP de référence des grandes entreprises industrielles et de distribution, avec S/4HANA comme cœur. On l'intègre pour que votre portail B2B, votre e-commerce ou votre app terrain y vivent : commande devenue sales order, ATP réel affiché, partenaire unique, sans Excel parallèle ni second SI. S/4 reste le système de référence ; BTP sert l'extension à côté, pas un doublon. Chaque produit SAP expose un protocole différent : nommer le produit et le périmètre dès le cadrage est la première étape.
Ce que SAP change dans votre plateforme
Portail B2B qui crée la commande S/4
Le portail crée le sales order et lit l'ATP. La date promise est celle de S/4, pas un espoir du middleware.
E-commerce branché sur stock et ATP
Clients, produits et commandes descendent dans S/4. Prix, crédit et stock restent la logique de l'ERP, FR et international.
App terrain sur le partenaire unique
L'app consulte le Business Partner et les commandes ouvertes. Commercial et entrepôt voient la même fiche, sans triple saisie.
Approbation métier hors SAP, même SI
Un événement de commande part vers le workflow d'approbation ou la notification métier, sans batch Excel de quinze minutes.
Ce que ça change dans votre produit
La technique au service d'un résultat mesurable : commande portail dans S/4, disponibilité réelle, partenaire unique.
S/4 reste la source de vérité
Commande, stock, tarif et crédit restent dans S/4. Votre produit s'y greffe, il ne réimplémente pas l'ERP dans un duplicata.
Une date de livraison tenable
L'ATP S/4 (disponibilité réelle) alimente le parcours de vente. Vous arrêtez de promettre une date que l'entrepôt refuse le lendemain.
Un partenaire, pas trois fiches
Le Business Partner unique alimente CRM, facturation et logistique. Les relances partent au bon tiers, pas à un doublon.
Un connecteur qui vous appartient
Code livré, documenté et maintenable. Nous travaillons avec votre équipe SAP, sans boîte noire ni connecteur générique.
Comment nous branchons SAP sur votre plateforme
Cadrage
Où S/4 entre dans votre produit : portail, e-commerce, terrain. Public Cloud, Private ou sur site, scénarios ouverts, présence BTP, middleware. Sans ça, l'estimation ne veut rien dire.
Mapping métier
Org commerciale, canal, division, incrément de commande, blocage crédit. Validé avec SD, FI ou MM, pas seulement avec l'IT.
Développement et recette
Connecteur branché sur votre portail, votre site ou votre app. Uniquement les APIs publiées du Hub, idempotence. Recette sur le QAS client.
Monitoring
Alertes sur échec, file de reprise, journal des échanges. Vous voyez un incident avant qu'il casse le portail ou la promesse de date.
Ce que l'API apporte à votre plateforme
- Créer la commande depuis le portail
- APIs publiées du Hub : sales order, Business Partner, produit. Uniquement les services Published, jamais un endpoint interne Fiori.
- Activer l'accès inbound avant le premier flux
- Sans Arrangement actif (système de communication + utilisateur technique), l'endpoint n'existe pas pour vous, même s'il figure dans le Hub.
- Réagir dans le produit sans batch
- Événements S/4 poussés vers Event Mesh (commande créée, par exemple). Ce n'est pas une URL webhook à coller dans un écran.
- Étendre à côté de S/4, pas dedans
- BTP en side-by-side : Destinations, Integration Suite, CAP. Le spécifique vit hors du core, une montée de release ne casse pas un Z-program.
Le vocabulaire d'une intégration SAP
- Communication Arrangement
- Le contrat d'accès inbound dans Communication Management : système, utilisateur technique, scénario SAP_COM_*. Sans lui, l'OData du Hub n'est pas joignable depuis l'extérieur.
- Communication User
- Compte technique, pas un utilisateur nominatif. Rotation, coffre, un utilisateur par environnement (DEV, QAS, PROD). Basic Auth inbound reste courant sur Public Cloud.
- Business Accelerator Hub
- Le catalogue des APIs publiées (ex-API Business Hub). On ne consomme que ce qui y figure pour le package et la version du tenant, metadata figée dans le dépôt.
- BTP
- Business Technology Platform : Destinations, Integration Suite, CAP, Event Mesh. Ce n'est pas S/4. Une page qui dit « API SAP » en parlant de BTP mélange l'ERP et l'extension.
- Event Mesh
- Le bus d'événements BTP qui reçoit les Event Objects S/4. Votre app s'abonne ici. Il n'y a pas d'écran S/4 où coller une URL HTTPS à la HubSpot.
- API Policy
- La règle SAP : uniquement les APIs Published. Interdit d'appeler un endpoint interne, de scraper Fiori ou d'extraire hors des chemins prévus. Un reverse-engineering n'est pas livrable.
Les contraintes réelles d'une intégration SAP
« SAP » désigne plusieurs produits
S/4HANA Cloud Public, Private / sur site, BTP, Business One et ECC n'ont ni le même protocole ni le même contrat. Le premier livrable est de nommer le produit, sinon l'estimation ne veut rien dire.
Sans Arrangement, pas d'API inbound
Sur Public Cloud, sans Communication Arrangement actif, l'endpoint OData n'existe pas pour vous, même s'il est dans le Hub. L'activation est un chantier SAP, pas un header HTTP.
Uniquement les APIs Published du Hub
L'API Policy interdit les endpoints internes et le scraping Fiori. Nous ne livrons que des services du Hub, versionnés, pour le package de votre tenant.
OData S/4 n'est pas un REST plat
Deep insert, $filter, $expand, $batch, ETags, parfois SOAP en parallèle. Mapper un sales order (postes, partenaires, conditions, textes) est un projet, pas quinze champs.
S/4HANA Cloud ou BTP, et ce que ça implique
Deux couches distinctes. S/4 est l'ERP. BTP est la plateforme d'extension. Les mélanger dans un devis rend le projet inchiffrable.
| Critère | S/4HANA CloudL'ERP, APIs publiées | SAP BTPExtension, pas l'ERP |
|---|---|---|
| Rôle | Core ERP : partenaire, commande, stock, FI | Side-by-side : UX, flux, API publique, IA |
| Canal d'accès | OData V2/V4 et SOAP du Hub, Arrangement | Destinations, Integration Suite, CAP, Event Mesh |
| Authentification | Communication User, OAuth 2.0, certificat | Auth vers S/4 via Destination (Basic, OAuth, certificat) |
| Temps réel | Event Objects S/4 (centaines sur Public Cloud) | Abonnement Event Mesh, puis votre application |
| Quotas | Contrôles par API sur le Hub, pas de chiffre global public | Ceux du service BTP souscrit, distincts de S/4 |
| Effort d'intégration | Élevé : mapping SD/FI/MM et Arrangement | Élevé si on y met le spécifique, plus léger en simple Destination |
| Le bon cas | Portail ou e-commerce qui crée la pièce dans S/4 | Processus absent du core, à isoler des montées de release |
Nous ne revendiquons aucun partenariat SAP, ni certification BTP ou Integration Suite. Nous intégrons via les APIs publiées du Business Accelerator Hub, avec l'équipe SAP ou l'intégrateur historique du client.
Ce que nous mesurons sur un projet SAP
Les autres ERP que nous intégrons
Le choix se fait sur l'ERP déjà en place chez vous, rarement sur la technique.
On combine SAP avec
La stack qui entoure S/4 et BTP sur nos projets.
Intégration SAP : vos questions
D'abord cartographier où S/4 entre dans votre produit (portail, e-commerce, terrain) et nommer le produit : S/4HANA Cloud Public, Private / sur site, BTP, Business One ou ECC. Sur Public Cloud, l'accès inbound exige un Arrangement et un utilisateur de communication. On consomme uniquement les APIs publiées du Hub. L'idempotence repose sur le numéro de pièce S/4. BTP intervient si le spécifique doit vivre hors du core. La difficulté réelle n'est pas l'appel HTTP, c'est que la commande canal et l'ATP affiché partagent la même vérité S/4.
Cela dépend du produit, des touchpoints et du mapping métier. Un portail qui crée des sales orders se chiffre autrement qu'un pont e-commerce catalogue plus commandes plus retours, ou qu'une extension sur BTP. Deux éléments pèsent lourd : les Communication Scenarios déjà ouverts, et le middleware déjà en place. Un existant ECC n'est pas le même devis qu'un tenant Public Cloud. Nous cadrons le produit et donnons une estimation ferme.
S/4HANA Cloud est l'ERP : partenaire, commande, stock, finance. Ses APIs sont celles du Hub, derrière un Communication Arrangement. BTP est la plateforme d'extension : Destinations vers S/4, Integration Suite pour les flux, CAP pour un process métier absent du core, Event Mesh pour les événements. Une app BTP ne « tape » pas S/4 en dur : elle passe par une Destination nommée. Mélanger les deux dans un cahier des charges produit un devis faux. Le cadrage tranche : pièce dans S/4, spécifique à côté, ou les deux.
Le statut partenaire est utile pour le déploiement fonctionnel, les licences et le paramétrage S/4. Pour un connecteur sur les APIs publiques, ce qui compte est la maîtrise d'OData, des Arrangements et du mapping métier, plus la capacité à travailler avec l'équipe SAP déjà en place. Nous ne revendiquons aucun partenariat SAP ni certification BTP : nous développons sur les APIs publiées du Business Accelerator Hub, et nous travaillons volontiers avec l'intégrateur historique qui gère votre core.
Non. L'API Policy SAP n'autorise que les APIs Published du Hub pour le package et la version du tenant. Un reverse-engineering d'écran Fiori, un namespace interne ou une extraction massive hors des chemins prévus n'est pas une intégration livrable. Sur Public Cloud, même un service Hub reste injoignable tant que l'Arrangement n'est pas actif. Nous figeons le nom du service, la version OData et la metadata dans le dépôt, et nous recettons sur le QAS client : le sandbox Hub n'a ni vos extensions ni vos checks métier.
Un projet d'intégration SAP ?
Parlons-en. 30 minutes pour identifier où S/4 touche votre portail ou votre canal, le produit (S/4 Cloud, BTP, ECC), les scénarios déjà ouverts, puis vous dire franchement ce qui est faisable.
Parler de mon projet SAP