Un paysage SAP réparti sur trois clouds dispose de trois pages de statut, trois consoles réseau et trois documents SLA, mais d’aucune vue montrant ce qui arrive à un processus métier lorsqu’il traverse les trois. Cette architecture est courante dans les entreprises, tout comme la lacune de monitoring qu’elle crée et qui est souvent sous-estimée à la conception.
Cet article examine les problèmes de visibilité lorsque SAP fonctionne chez plusieurs fournisseurs ou dans un mélange cloud et infrastructure locale, les architectures qui les aggravent et les choix permettant une visibilité de bout en bout sans refonte totale.
À quoi ressemble un environnement SAP multicloud
Le terme recouvre plusieurs configurations. La plus fréquente associe ECC ou S/4HANA sur site ou en IaaS gérée par le client, et des extensions BTP hébergées sur Azure, AWS ou GCP selon la région et le compte. Autre cas courant : S/4HANA dans RISE, avec Integration Suite sur BTP reliée à des services tiers chez un autre fournisseur.
Les entreprises choisissent rarement explicitement le multicloud. Elles accumulent des présences au fil des projets : Azure pour une intégration BTP en raison d’un accord d’entreprise, un SaaS logistique sur AWS, BusinessObjects migré sur une VM GCP plusieurs années auparavant. Les modèles d’architecture hybride permettent de concevoir cet ensemble volontairement. Ici, le problème est celui d’une configuration existante dont le monitoring n’a pas suivi.
Les lacunes de visibilité créées par le multicloud
Trois plans de monitoring sans corrélation
Azure Monitor suit Azure, CloudWatch suit AWS et BTP Cockpit suit les services BTP et les flux Integration Suite. Chaque outil produit des données exactes sur son domaine, sans voir les autres.
Un échec traversant plusieurs clouds produit donc des traces séparées. Une commande S/4HANA sur Azure ne déclenche pas sa notification logistique parce qu’une erreur de transformation dans Integration Suite empêche la génération de l’IDoc vers le prestataire AWS. Azure indique une instance saine, BTP une erreur de flux, AWS rien puisque le message n’est jamais arrivé. Aucun lien automatique n’unit ces observations.
L’investigation doit rapprocher les heures, retrouver le flux BTP lié à la transaction SAP et distinguer la cause de la conséquence côté AWS. Sans identifiant de corrélation parcourant la transaction jusqu’au destinataire, cela relève de l’enquête plutôt que d’une consultation de tableau de bord. L’observabilité SAP de bout en bout relie précisément les événements techniques aux résultats métier au-delà des infrastructures.
La latence réseau, nouvelle variable de performance SAP
Sur site, la latence entre serveur applicatif et HANA est généralement inférieure à une milliseconde. Dans le cloud, même dans une zone de disponibilité, elle se situe souvent entre 1 et 3 ms ; entre zones d’une région, entre 2 et 5 ms ; entre fournisseurs ou régions, les appels synchrones peuvent atteindre 20 à 50 ms par saut.
Les appels synchrones successifs cumulent ce coût. Une commande sollicitant S/4HANA pour le prix, Integration Suite pour les taxes et un service tiers pour les conditions contractuelles ajoute 90 ms avec trois sauts à 30 ms, avant le traitement. Aucun monitoring isolé ne voit ce surcoût ; seule la mesure de bout en bout le révèle.
La mesure doit donc se faire au niveau du processus. Un composant à 200 ms peut fonctionner correctement, alors que le processus prend quatre secondes et comporte douze appels interclouds ajoutant chacun 30 ms. Le défaut architectural n’apparaît que dans la chronologie globale.
Des modes de panne propres au cloud
Dégradation partielle des zones de disponibilité
Sur site, les pannes paraissent souvent binaires : serveur disponible ou arrêté, lien connecté ou coupé. Une zone cloud peut se dégrader partiellement : erreurs API accrues, latence stockage élevée ou pertes réseau intermittentes. SAP reste joignable, mais certaines transactions ralentissent ou échouent.
Les symptômes dispersés sont difficiles à détecter avec un monitoring SAP standard : certaines transactions réussissent, d’autres non, sans événement système évident. Il faut les corréler aux données de disponibilité de la zone, externes à SAP.
Variabilité des entrées-sorties et conséquences HANA
HANA est sensible à la latence du stockage. Le stockage bloc cloud introduit une variabilité peu visible sur des baies dédiées : une écriture de 1 ms dans 99 % des cas peut prendre 15 ms pendant une maintenance ou un pic d’utilisation de l’infrastructure sous-jacente.
Ces pics affectent les savepoints, sauvegardes de logs et delta merges. Leur suivi continu expose cette variabilité comme signal opérationnel. L’écart de durée d’un savepoint est souvent le premier indice, avant même une reconnaissance du fournisseur sur sa page de statut.
À noter : ces pages reflètent les événements d’infrastructure affectant la disponibilité, pas les dégradations restant sous ce seuil. Une latence stockage multipliée par trois peut être absente du statut cloud, mais visible dans les savepoints HANA et, si elle dure, dans les temps de réponse dialogue.
RISE with SAP et sa frontière de monitoring
RISE regroupe hébergement S/4HANA, infrastructure et opérations de plateforme dans un abonnement SAP. SAP gère l’infrastructure, la configuration du cluster HANA et la disponibilité de base. Le client conserve la configuration applicative, les extensions, les intégrations et l’observabilité applicative.
Le SLA RISE couvre la disponibilité infrastructure et la santé plateforme. Taux d’achèvement des processus, réussite des jobs, erreurs d’interfaces et performances applicatives HANA restent au client. Se limiter au monitoring intégré crée donc des angles morts.
Lorsqu’un processus échoue, SAP peut confirmer une infrastructure saine ; l’investigation applicative appartient au client. Celui-ci a besoin d’une connexion indépendante à la couche S/4HANA. Les API RFC ou REST standard la permettent, mais nécessitent une configuration et des autorisations explicites, souvent absentes. L’approche sans agent convient particulièrement : aucun accès infrastructure RISE, seulement un utilisateur applicatif dédié.
Les corrections architecturales
Un plan unifié et une collecte interclouds
Un plan unifié rassemble métriques applicatives SAP, infrastructure cloud et middleware sur un axe temporel commun. Les données SAP proviennent de RFC et SQL HANA ; les API fournisseurs ajoutent état des zones, latence stockage et réseau. Une dégradation de zone et une anomalie SAP simultanées apparaissent sur la même chronologie.
Cela ne nécessite pas de remplacer tous les outils cloud. Il faut pouvoir ingérer plusieurs sources et les corréler par temps et contexte métier. Les données propres à SAP, absentes des outils fournisseurs, exigent une connexion qui comprend SAP.
Corrélation des transactions entre clouds
Des identifiants métier propagés de l’origine au middleware puis à tous les destinataires rendent l’analyse possible. Sans identifiant partagé, relier transaction S/4HANA, flux BTP et résultat reçu exige une reconstruction manuelle. Avec l’identifiant dans chaque payload et chaque étape de journalisation, une seule recherche suffit. Le monitoring des hubs d’intégration SAP décrit comment assurer cette propagation de manière cohérente.
Sondes synthétiques des processus métier
Le monitoring synthétique exécute périodiquement des transactions légères et mesure leur résultat global. Une sonde crée une commande test, vérifie le traitement du message dans Integration Suite puis sa réception dans le système aval. Elle teste toute la chaîne toutes les quelques minutes et alerte si une étape échoue ou dépasse le délai attendu, avant qu’une transaction réelle ne subisse le problème.
Cette approche reflète directement la santé du processus. Une réussite confirme le parcours complet ; un échec situe l’étape et le cloud. Elle complète le monitoring des composants, fournit le premier signal et réduit le travail d’enquête.
La visibilité multicloud est d’abord un problème d’architecture. Ajouter un tableau de bord ne corrige pas l’absence de corrélation, d’identifiants partagés et de suivi global. La propagation des identifiants, l’emplacement de la collecte unifiée et le choix des sondes doivent être pensés à la conception et sont difficiles à ajouter après coup.
Pour une équipe héritant d’un paysage sans visibilité prévue, le point de départ est un bilan des lacunes : composants couverts ou non et processus sans vue globale. L’évaluation gratuite du monitoring SAP offre une démarche structurée. Les corrections sont progressives ; le bilan fixe la priorité.
Redpeaks collecte les métriques applicatives de RISE, des clouds gérés par le client et des environnements sur site via une connexion sans agent, avec corrélation intersystèmes et monitoring d’intégration. Découvrez la couverture multicloud.
