Maîtriser le cockpit SAP BTP : des étapes simples à la portée de tous

Le cockpit SAP Business Technology Platform (BTP) est la console web depuis laquelle vous pilotez votre environnement cloud SAP : comptes, services, utilisateurs, sécurité, applications déployées et coûts. Si vous administrez BTP, si vous y déployez des applications ou si vous validez sa facture, c'est l'écran sur lequel vous passerez votre temps.

Pour y accéder, ouvrez la passerelle régionale de votre région : https://emea.cockpit.btp.cloud.sap, https://amer.cockpit.btp.cloud.sap ou https://apac.cockpit.btp.cloud.sap (SAP Learning). Il vous faut un identifiant utilisateur SAP ; votre administrateur peut en créer un. Les comptes d'essai utilisent https://cockpit.hanatrial.ondemand.com/trial/ et durent jusqu'à 90 jours, avec une prolongation à demander au bout de 30 (SAP Developers).

Configurez ensuite les choses dans l'ordre ci-dessous. J'ai mis des jours à le comprendre la première fois. L'essentiel des difficultés venait du fait d'avoir fait l'étape quatre avant l'étape un.

Tout s'inscrit dans une hiérarchie. Le compte global est votre contrat avec SAP et contient le pool de services que vous avez achetés. Les répertoires regroupent les sous-comptes, par exemple par unité métier. Les sous-comptes sont l'endroit où le travail se fait : chacun a une région, un environnement tel que Cloud Foundry ou Kyma, ses propres utilisateurs et ses propres instances de service.

1. Compte globalVotre contrat avec SAP et les services que vous avez achetés
   Droits d'utilisationLe pool limité dans lequel puise chaque sous-compte
2. RépertoireRegroupe les sous-comptes, par exemple par unité métier

• Finance-DevDéveloppement, sur des plans gratuits ou de petite taille
• Finance-TestTest, avec ses propres utilisateurs et collections de rôles
• Finance-ProdProduction, avec des alertes configurées avant le go-live

BTP couvre quatre domaines : le développement et l'automatisation d'applications, l'intégration, les données et l'analytique, et l'IA. Vous les rencontrerez tous les quatre dans le cockpit, mais la plupart des programmes commencent par l'intégration et les extensions de S/4HANA.

C'est l'ordre que je suis sur un nouveau compte global. Chaque étape a un responsable naturel.

1. Convenir de la structure et du nommage des sous-comptes (responsable de la plateforme). Développement, test et production par domaine, par exemple Finance-Dev, Finance-Test, Finance-Prod.
2. Connecter votre fournisseur d'identité (responsable sécurité). Faites-le avant d'ajouter le moindre utilisateur.
3. Définir les collections de rôles par fonction (responsable sécurité), y compris une collection d'administrateur d'urgence (break-glass).
4. Distribuer les droits d'utilisation, au minimum d'abord (responsable de la plateforme). Ajoutez-en quand une équipe démontre qu'elle en a besoin.
5. Installer et configurer le Cloud Connector (équipe infrastructure) si BTP doit atteindre des systèmes on-premise.
6. Activer les alertes et la revue d'utilisation (responsable de la plateforme). Décidez qui regarde quoi, et à quelle fréquence.
7. Tout consigner en dehors du cockpit (architecte). Structure, règles de nommage, répartition des droits d'utilisation et raisons de chaque choix.

Sous-comptes et droits d'utilisation

C'est ici que la plupart des équipes créent un désordre qui les suit pendant des années.

J'ai travaillé un jour avec un client qui avait plus de 50 sous-comptes nommés au hasard, et personne ne retrouvait rien. Démêler cela en plein projet est pénible. Prenez une journée pour cartographier d'abord la structure sur papier. Si vous opérez dans plusieurs régions, reproduisez la structure d'une région à l'autre et utilisez des libellés pour regrouper les sous-comptes liés.

Les droits d'utilisation décident des services que chaque sous-compte peut utiliser, et en quelle quantité. Votre compte global dispose d'un pool limité. Je commence au minimum et j'augmente au besoin, et cette approche a fait économiser à mes clients des milliers en services inutilisés. Beaucoup de services ont un plan gratuit, suffisant pour les tests.

Utilisateurs, confiance et collections de rôles

Si votre entreprise dispose déjà d'un fournisseur d'identité tel que Microsoft Entra ID ou Okta, ne gérez pas les utilisateurs BTP à la main. La voie recommandée par SAP est un tenant SAP Cloud Identity Services, relié au sous-compte sous Security > Trust Configuration. Ce tenant joue alors le rôle de proxy vers votre fournisseur d'identité d'entreprise. La relation de confiance peut être établie automatiquement avec OpenID Connect. L'authentification à deux facteurs et les politiques d'accès sont ensuite regroupées au même endroit.

Les collections de rôles sont des ensembles de rôles que vous attribuez à des utilisateurs ou à des groupes. Mon approche :

1. Les construire autour des fonctions, pas des individus.
2. Les garder assez précises pour avoir un sens, mais pas assez fines pour qu'il faille en maintenir des centaines.
3. Garder une collection d'administrateur d'urgence (break-glass).
4. Revoir les attributions chaque trimestre. Les gens changent de poste et conservent leurs anciens accès.

Services, instances et clés

Pour créer une instance de service, ouvrez Services > Service Marketplace dans le sous-compte, choisissez le service et sélectionnez un plan. Le plan détermine à la fois les capacités et le coût. Conservez les paramètres choisis ailleurs que dans le cockpit ; vous en aurez besoin le jour où quelque chose casse.

Liez l'instance à votre application et BTP injecte les identifiants. Pour les outils externes qui ne sont pas des applications BTP, créez une clé de service. Nommez les clés d'après ceux qui les utilisent, par exemple jenkins-deployment, pas key1.

Choisir un environnement d'exécution

Le cockpit propose trois environnements principaux. Choisissez en gardant les compétences de votre équipe sous les yeux.

Environnement d'exécution	Idéal pour	À surveiller
Cloud Foundry	Applications Java, Node.js et Python, y compris SAP Cloud Application Programming Model (CAP)	Le choix par défaut éprouvé ; le moins de surprises pour la plupart des équipes
Kyma	Microservices natifs Kubernetes et extensions pilotées par événements	Demande des compétences Kubernetes que beaucoup d'équipes SAP n'ont pas
Environnement ABAP	Extensions ABAP Cloud à côté de S/4HANA	Choix naturel pour les développeurs ABAP ; n'utilise que des API publiées

J'ai vu des projets retardés de plusieurs mois parce que les développeurs devaient apprendre un nouvel environnement qui correspondait au plan d'architecture mais pas à leur expérience. L'environnement techniquement meilleur, mais dans lequel votre équipe ne sait pas développer, est le moins bon choix.

Pour déployer sur Cloud Foundry, décrivez l'application dans un fichier manifest.yml (mémoire, instances, buildpack, variables d'environnement), puis poussez-la avec la CLI CF ou un pipeline. Cloud Foundry détecte le buildpack, lie les services et configure les routes.

Connecter BTP à S/4HANA et à d'autres systèmes

La plupart du travail sur BTP, c'est de l'intégration. Voici les schémas que je mets en place le plus souvent.

Scénario	Comment le configurer
S/4HANA on-premise ou Private Edition	Cloud Connector sur votre réseau, une destination dans le sous-compte, puis API OData ou SOAP
Applications cloud SAP comme SuccessFactors	Destinations plus Integration Suite ou Event Mesh, avec des extensions en CAP
Systèmes non SAP comme Salesforce ou Workday	Adaptateurs Integration Suite, ou flux d'intégration sur mesure
Exposer vos propres API	API Management dans Integration Suite : concevoir, publier, surveiller

Le Cloud Connector ouvre un tunnel sortant vers BTP, de sorte que vous n'avez besoin d'aucune règle de pare-feu entrante. N'exposez que les systèmes et les chemins d'URL dont BTP a réellement besoin. Si l'intégration est votre usage principal, mon article sur SAP CPI traite plus en détail des choix de conception.

Supervision et maîtrise des coûts

Configurez la supervision avant d'en avoir besoin. Je consulte mes tableaux de bord chaque matin avec mon café. C'est devenu un rituel, et il m'a évité plus d'un « pourquoi le système est-il en panne ? ».

Ce qu'il faut mettre en place :

1. Alertes. Le service SAP Alert Notification envoie les événements de la plateforme et des applications par e-mail, vers Slack ou vers votre propre outil d'alerte. Ma configuration habituelle : e-mail pour les applications critiques et webhook Slack pour tout ce qui ne peut pas tomber.
2. Santé des applications. Temps de réponse et taux d'erreur par application, depuis les vues Cloud Foundry ou Kyma.
3. Utilisation et coût. Usage Analytics dans chaque sous-compte, et Costs and Usage au niveau du compte global. Les valeurs d'utilisation sont actualisées toutes les 24 heures.

Supprimez chaque mois les instances de service inutilisées. Réduisez la taille des espaces de développement en dehors des heures de travail. Vérifiez la consommation des droits d'utilisation avant de renouveler, car les allocations inutilisées sont une source courante de dépassements.

Automatisation et domaines personnalisés

Cliquer dans le cockpit ne passe pas à l'échelle. L'interface en ligne de commande de BTP (btp CLI) et les API de la plateforme peuvent scripter presque tout ce que fait l'interface : créer des sous-comptes, attribuer des droits d'utilisation, provisionner les développeurs.

Sur une mission, j'avais besoin d'environnements pour 12 nouveaux développeurs. Plutôt que de cliquer dans le cockpit toute la journée, j'ai lancé mon script et je suis allé prendre un café. À mon retour, tout était prêt. L'automatisation des déploiements a réduit de 80 % le temps de configuration sur une mission, et brancher les clés de service et la CLI CF dans un pipeline a ramené le déploiement de plusieurs heures à quelques minutes.

Les domaines personnalisés valent l'effort pour les applications destinées aux utilisateurs. Ils se configurent via le service SAP Custom Domain plutôt que par un menu du cockpit. Sur un projet client, les dirigeants ont remarqué tout de suite le rendu plus professionnel.

1. Créer des sous-comptes avant de s'être mis d'accord sur une convention de nommage.
2. Attribuer des rôles à des individus plutôt qu'à des collections de rôles et à des groupes.
3. Faire tourner des services de développement sur des plans dimensionnés pour la production.
4. Attendre la première panne pour mettre en place les alertes.
5. Ne pas documenter la structure du compte et les raisons qui la justifient. Le cockpit conserve le quoi, jamais le pourquoi.

Bloqué sur une erreur précise ? Mon guide des problèmes du cockpit BTP couvre les plus courantes. Le guide du Clean Core explique où se placent les extensions BTP dans un programme S/4HANA.

À quoi sert le cockpit SAP BTP ?

C'est la console d'administration web de SAP Business Technology Platform. Vous l'utilisez pour créer des sous-comptes, distribuer des droits d'utilisation, gérer les utilisateurs et la confiance, créer des instances de service, déployer et superviser des applications, et suivre l'utilisation et les coûts.

Quelle est l'URL de connexion au cockpit SAP BTP ?

Utilisez votre passerelle régionale : https://emea.cockpit.btp.cloud.sap pour l'Europe, le Moyen-Orient et l'Afrique, https://amer.cockpit.btp.cloud.sap pour les Amériques, ou https://apac.cockpit.btp.cloud.sap pour l'Asie-Pacifique. Les comptes d'essai utilisent https://cockpit.hanatrial.ondemand.com/trial/. Il vous faut un identifiant utilisateur SAP pour vous connecter.

Comment structurer les sous-comptes dans SAP BTP ?

Séparez dès le départ le développement, le test et la production dans des sous-comptes distincts, et nommez-les de façon que le domaine et l'étape soient évidents, par exemple Finance-Dev et Finance-Prod. Les grandes organisations ajoutent des répertoires par unité métier. Planifiez-le d'abord sur papier ; la structure est difficile à modifier une fois les services en fonctionnement.

Quels sont les quatre piliers de SAP BTP ?

SAP regroupe BTP en développement et automatisation d'applications, intégration, données et analytique, et intelligence artificielle. La plupart des programmes commencent par l'intégration et les extensions de S/4HANA, puis ajoutent des cas d'usage données et IA une fois la plateforme stable.

Comment connecter mon fournisseur d'identité à SAP BTP ?

Configurez un tenant SAP Cloud Identity Services et établissez la confiance avec votre sous-compte sous Security > Trust Configuration ; OpenID Connect peut le faire automatiquement. Connectez ensuite votre fournisseur d'identité d'entreprise, tel que Microsoft Entra ID ou Okta, à ce tenant. Les utilisateurs et l'authentification à deux facteurs sont alors gérés au même endroit.

Quel environnement d'exécution BTP choisir : Cloud Foundry, Kyma ou environnement ABAP ?

Adaptez-le à votre équipe. Cloud Foundry convient aux applications Java, Node.js et Python et reste le choix par défaut le plus sûr. Kyma convient aux microservices natifs Kubernetes mais exige des compétences Kubernetes. L'environnement ABAP convient aux développeurs ABAP qui construisent des extensions Clean Core à côté de S/4HANA.

Comment connecter SAP BTP à un système SAP on-premise ?

Installez le Cloud Connector à l'intérieur de votre réseau. Il ouvre un tunnel sortant sécurisé vers BTP, si bien qu'aucune modification entrante du pare-feu n'est nécessaire. N'exposez que les systèmes et les chemins dont BTP a besoin, vérifiez la connexion sous Connectivity dans le sous-compte, puis créez les destinations que vos applications et vos flux d'intégration appellent. Testez l'ensemble du chemin avant la production.