SAP Business Technology Platform

Qu’est-ce que SAP BTP ?

SAP Business Technology Platform (SAP BTP) est la plateforme cloud de SAP pour l’intégration, les extensions, l’automatisation des processus, les données et l’IA : la couche qui relie les systèmes SAP et non SAP et qui porte la logique qui n’a pas sa place dans une application standard. Spadoom est un SAP Gold Partner suisse qui met en œuvre SAP BTP pour relier SAP S/4HANA Public Cloud à Sales Cloud V2, Service Cloud V2 et au reste de la pile CX, et qui exploite les interfaces et extensions qu’il construit. Depuis septembre 2026, Spadoom est aussi partenaire SAP PartnerEdge Build : nos propres solutions BTP passent la vérification de SAP et seront proposées dans le SAP Store.

En pratique, BTP porte trois types de travail : l’interface entre l’ERP et les applications CX, l’étape de validation dont votre processus a besoin et que le standard ne prévoit pas, et l’événement qui doit atteindre trois systèmes dans le bon ordre. La documentation de la plateforme SAP est la référence technique officielle, la page produit de SAP BTP présente les familles de services, SAP Integration Suite est le service par lequel commencent la plupart de nos projets, et le SAP Discovery Center est le catalogue SAP des services, plans et missions de référence, avec l’outil d’estimation des coûts que nous utilisons pour cadrer le périmètre.

La règle que nous appliquons : BTP n’est pas la première réponse. Nous vérifions les fonctions standard, puis les extensions in-app prises en charge, et seulement ensuite une extension side-by-side sur BTP. Une extension dont vous n’aviez pas besoin devient un système qu’il faut désormais exploiter, corriger et transmettre. Si vous souhaitez d’abord l’introduction générale, notre blog explique ce qu’est SAP BTP et quand vous en avez besoin. Cette page porte sur la mise en œuvre : ce que nous construisons sur BTP, comment il est licencié et qui l’exploite ensuite.

Spadoom construit sur BTP dans le cadre de ses projets Cloud ERP et Customer Experience en Suisse, en Allemagne, en Autriche et en Italie, avec une seule équipe pour le côté ERP et le côté CX de chaque interface.

Étude de cas : plus d’un million de messages par mois chez Meier Tobler

Meier Tobler fournit des techniques de chauffage, de ventilation et de sanitaire dans toute la Suisse. Sa plateforme SAP PI/PO vieillissante ne fournissait pas de données fiables en temps réel entre la boutique en ligne et SAP S/4HANA, si bien que les prix et les stocks de la boutique étaient souvent dépassés. Nous avons d’abord conseillé l’achat et le dimensionnement des licences SAP Integration Suite pour leur volume de messages, puis mis en œuvre SAP Integration Suite comme plateforme d’intégration centrale et construit les interfaces entre la boutique et l’ERP.

Aujourd’hui, plus d’un million de messages par mois passent par une seule plateforme supervisée, les prix et les stocks de la boutique sont synchronisés en temps réel et les commandes reviennent dans l’ERP sans intervention manuelle. La nouvelle architecture prépare aussi la mise hors service progressive des anciens systèmes PI/PO. Lisez le témoignage complet de Meier Tobler.

Chez intelligentfood, le travail sur BTP était d’une autre nature : des applications mobiles pour une équipe commerciale qui travaille sur la route, en complément de Sales Cloud V2 et de l’intégration Cloud ERP.

Integration Suite, Build ou IA : quel service BTP fait quoi

« Il nous faut BTP » n’est pas encore un périmètre. BTP est un catalogue de services, chacun licencié et exploité séparément, et la plupart des projets en utilisent deux ou trois, pas tous. Voici comment nous présentons les principaux avant toute commande.

L’ordre compte. Integration Suite vient généralement en premier, car l’ERP et les applications CX doivent s’accorder sur les données avant d’automatiser quoi que ce soit par-dessus. Build suit lorsqu’une étape de processus manque. L’IA vient en dernier, une fois que les données sur lesquelles elle s’appuie sont justes et que quelqu’un est responsable du contrôle.

Clean core : quand une extension a sa place sur BTP

Clean core signifie garder l’ERP proche du standard pour que les versions SAP s’installent sans reprise. Dans SAP S/4HANA Cloud, un besoin peut être couvert à trois endroits, et nous les vérifions dans cet ordre.

1. Extensions key-user dans le système. Champs propres, logique propre dans des points d’extension publiés, formulaires et écrans adaptés. Aucune plateforme séparée, aucune exploitation supplémentaire.
2. Extensions développeur dans le système. Développement ABAP Cloud sur des API publiées, au plus près des données, pour une logique qui doit s’exécuter dans la transaction ERP.
3. Side-by-side sur SAP BTP. Une application ou un workflow séparé qui ne communique avec l’ERP que par des API et événements publiés. C’est le bon endroit lorsque la logique sert plusieurs systèmes (ERP et CX à la fois), a ses propres utilisateurs hors de l’ERP ou doit évoluer à un autre rythme que le cœur.

Une extension side-by-side coûte plus cher à exploiter qu’une extension in-app : son propre déploiement, ses propres rôles d’accès, sa propre supervision. Nous la recommandons lorsque l’une des raisons ci-dessus s’applique, et nous inscrivons cette raison dans la décision d’architecture pour que l’équipe suivante puisse la comprendre.

Relier. Étendre. Automatiser.

SAP BTP est la base de nos extensions. Nous relions SAP S/4HANA Public Cloud à Sales Cloud, Service Cloud, Commerce, CPQ et FSM. Nous partons du processus métier, convenons quel système fait foi pour chaque donnée et construisons autour les interfaces, les applications et la supervision.

Trois questions tranchent la plupart des conceptions d’interface avant qu’une ligne de code soit écrite :

• À qui appartient la donnée ? Un prix vit dans l’ERP, une opportunité dans Sales Cloud, un ordre de service dans FSM. Chaque interface copie depuis le système qui fait foi, jamais dans les deux sens sans règle pour les conflits.
• Synchrone ou événement ? Un contrôle de prix pendant l’offre exige une réponse immédiate. Un statut de livraison peut arriver sous forme d’événement quelques secondes plus tard. Ce choix change la gestion des erreurs, les volumes et les coûts.
• Que se passe-t-il si le système cible est indisponible ? Reprises, file de messages en échec et alerte à une personne désignée, convenues avant la mise en production.

Nous développons aussi nos propres produits sur SAP BTP, dont les extensions Engage pour Sales et Service Cloud V2 : voir Built by Spadoom.

Du devis à l’intervention sur le terrain

Un commercial prépare une offre dans Sales Cloud et CPQ. La commande acceptée arrive dans Cloud ERP, qui vérifie la solvabilité, les prix et la disponibilité. Un besoin de service crée une intervention pour l’équipe terrain dans FSM, et les heures et le matériel confirmés reviennent dans l’ERP pour la facturation. BTP relie les échanges et porte les extensions dont le processus a besoin, par exemple une validation pour une remise au-delà d’un seuil. Il s’agit d’une architecture d’exemple : les interfaces exactes, le périmètre produit et les licences sont vérifiés pendant l’évaluation. Notre vue d’ensemble de la transformation montre comment les briques ERP et CX s’assemblent de bout en bout.

Comment SAP BTP est licencié

SAP vend BTP selon deux modèles commerciaux, à la consommation et par abonnement, et de nombreux clients utilisent les deux. Il s’agit d’une orientation, pas d’une offre : vos droits effectifs dépendent de votre contrat. Le matériel de formation SAP sur les modèles commerciaux de SAP BTP les décrit en détail.

• À la consommation avec des cloud credits prépayés. Avec le SAP BTP Enterprise Agreement (BTPEA), vous vous engagez pour la durée du contrat sur un volume prépayé de cloud credits, et l’utilisation réelle des services éligibles est imputée chaque mois sur ces credits. BTPEA est le modèle des nouveaux contrats ; l’ancien Cloud Platform Enterprise Agreement (CPEA) fonctionne de la même manière et se poursuit pour les comptes CPEA existants. Les deux listes de services ne sont pas identiques.
• Pay-As-You-Go. Aucun engagement préalable ; vous êtes facturé chaque mois a posteriori pour ce que vous utilisez. SAP le destine aux petites applications, aux preuves de concept et aux projets pilotes.
• Abonnement. Un prix fixe pour un service et un plan donnés sur une durée fixe, indépendamment de la consommation. Adapté aux services dont l’usage est prévisible.
• Free tier. De nombreux services proposent des plans gratuits avec des limites d’usage, suffisants pour prototyper un flux avant toute commande.

RISE with SAP et GROW with SAP contiennent aussi BTP : SAP mentionne les cloud credits BTP comme composante de RISE, et les deux éditions de GROW incluent des credits du BTP Enterprise Agreement ainsi que des droits sur les fonctions SAP Build. Que ces credits couvrent vos intégrations prévues dépend du volume et des services utilisés.

Ce que nous vérifions avant de cadrer le périmètre, pour que la licence ne vous surprenne pas après la mise en production :

• Les droits existants. Quels services, plans et credits BTP votre contrat actuel (y compris RISE ou GROW) contient déjà.
• Les services et plans dont le flux a besoin. Integration Suite, un service Build, un service d’IA ou aucun d’entre eux, et dans quel plan.
• Une estimation de consommation. Volume de messages et connexions attendus, calculés avec l’outil d’estimation du SAP Discovery Center et documentés avec leurs hypothèses. Chez Meier Tobler, ce dimensionnement a été le premier livrable, avant la construction de la moindre interface.
• Qui suit la consommation. Les credits sont consommés chaque mois ; quelqu’un de votre côté ou du nôtre contrôle l’utilisation dans le BTP cockpit et reçoit une alerte avant que le budget soit épuisé.

Ce que coûte l’exploitation, après la construction

Ce qui décide d’un business case BTP, c’est rarement la construction. C’est de savoir qui surveille les interfaces en fin de mois, ce que couvrent réellement les droits de service de votre contrat et ce qui se passe lorsqu’un système cible est indisponible à deux heures du matin. Rôles d’accès, journalisation, déploiement et alertes font partie du périmètre dès le départ, et nous convenons des tests de réception avant la réalisation plutôt qu’après.

Après la mise en production, il y a deux options, et nous convenons laquelle s’applique avant de commencer à construire. Soit votre équipe informatique reprend avec la documentation, les runbooks et la transmission de chaque alerte, soit Spadoom exploite les interfaces et extensions dans le cadre d’un contrat de support : nous supervisons le traitement des messages, analysons les messages en échec, testons les versions trimestrielles de SAP sur les interfaces et rendons compte de la consommation. Dans les deux cas, chaque interface a un responsable désigné et un chemin de reprise documenté.

Commencer par un flux. Le construire correctement.

Apportez un processus qui dépend encore de copies de données ou de relances par courriel. Dans une évaluation à prix fixe, nous cartographions ses systèmes, ses responsables de données et ses exceptions, vérifions vos droits BTP existants et estimons la consommation. Vous recevez une proposition d’architecture, un périmètre de réalisation et une base de coût. Supervision et transmission font partie du périmètre, et non d’une demande de modification ultérieure.

Si vous utilisez encore SAP PI/PO, la même évaluation peut partir de votre inventaire d’interfaces : quels flux passent tels quels dans Integration Suite, lesquels sont repensés et lesquels peuvent être supprimés.

Parler de votre intégration ou découvrir comment les côtés ERP et CX s’articulent.