Liste de contrôle pour l’évaluation d’une plateforme de surveillance SAP : 12 questions à se poser avant de faire son choix

La plupart des projets d’évaluation de solutions de surveillance SAP échouent avant même la première démonstration. L’équipe définit des exigences de manière très générale, organise des présentations avec trois fournisseurs, regarde les mêmes diapositives soignées sur la visibilité en temps réel et les alertes intelligentes, puis tente de comparer des plateformes qui, sur le papier, semblent toutes très similaires.

Les questions qui permettraient réellement de mettre en évidence les différences ne sont jamais posées, car personne ne les a préparées. Comment l’outil se comporte-t-il lorsqu’un job s’achève avec succès mais a généré des erreurs d’application dans le spool ? Peut-il surveiller les extensions SAP BTP dans la même vue que la pile ABAP sur site ? Que se passe-t-il au niveau du routage des alertes lorsque votre ingénieur de garde est en congé et que vous avez besoin d’une escalade automatique ?

Cette liste de contrôle s’articule autour de ces questions spécifiques. Chacune d’entre elles est conçue pour mettre en évidence une lacune réelle que les scripts de démonstration génériques ont tendance à éviter. Passez-les en revue lors des discussions avec les fournisseurs, et vous aurez une image beaucoup plus claire de ce que chaque plateforme fait réellement par rapport à ce que décrit le marketing.

Couverture : que surveille réellement la plateforme ?

Q1 Couvre-t-elle tous les composants SAP que vous utilisez aujourd’hui, y compris ceux dont personne n’est officiellement responsable ?

Tous les fournisseurs répondront par l’affirmative à cette question. La question complémentaire qui importe est la suivante : demandez une liste documentée des technologies prises en charge et comparez-la à votre environnement actuel. Pas à votre environnement cible après la migration vers S/4HANA. Votre environnement actuel, avec tous les composants hérités, le cluster de reporting BusinessObjects, les anciens systèmes NetWeaver et les connecteurs personnalisés.

Les environnements SAP en production correspondent rarement au schéma d’architecture épuré présenté dans la stratégie informatique. Il existe généralement des composants antérieurs à l’équipe informatique actuelle, des systèmes techniquement obsolètes mais toujours utilisés par la direction financière, et des intégrations que personne ne veut toucher car elles fonctionnent et que la personne qui les a développées est partie il y a trois ans. Une plateforme de surveillance qui couvre S/4HANA et HANA mais pas SAP BusinessObjects crée un angle mort dans une couche dont les utilisateurs métier dépendent au quotidien.

SAP BusinessObjects constitue un bon test spécifique. De nombreuses plateformes prétendent prendre en charge SAP mais ne couvrent que la pile ABAP de base. Demandez directement si l’outil surveille la planification des rapports, l’état de publication, la disponibilité des nœuds de serveur et la charge des sessions utilisateur dans les environnements BOBJ. Si la réponse est vague, considérez-la comme un « non ».

Q2  Le déploiement est-il sans agent, et qu’est-ce que cela signifie exactement pour votre environnement ?

Le terme « sans agent » est souvent utilisé de manière imprécise dans le domaine de la surveillance SAP. Certains fournisseurs entendent par là qu’ils utilisent les API RFC ou REST de SAP pour collecter des données sans déployer de logiciel supplémentaire sur le serveur d’applications SAP. D’autres indiquent qu’ils disposent d’un agent qui s’exécute sur un hôte collecteur distinct plutôt que sur le serveur SAP lui-même. D’un point de vue opérationnel, il s’agit d’architectures sensiblement différentes.

Un véritable déploiement sans agent, s’appuyant sur des connexions RFC SAP standard et des API, présente deux avantages pratiques qui s’amplifient avec le temps. Premièrement, il n’y a aucune demande de transport à gérer. Chaque transport SAP est un élément de gestion des changements qui doit passer par les phases de développement, d’assurance qualité et de production, et dans les environnements réglementés, ce processus prend du temps. Deuxièmement, lorsque SAP publie un correctif ou que vous mettez à niveau votre système, l’outil de surveillance continue de fonctionner car aucun code n’est installé côté SAP.

La question à poser au fournisseur est la suivante : si nous effectuons demain une mise à niveau majeure du noyau SAP, votre outil de surveillance nécessite-t-il une intervention de notre part pour continuer à fonctionner ? Si la réponse est oui, vous êtes dépendant d’un agent, quoi qu’en dise le marketing.

Alertes : qualité du signal et niveau de configuration

Q3 Comment les seuils d’alerte sont-ils configurés, et qui les définit ?

Les seuils d’alerte par défaut sont presque toujours inadaptés à votre environnement spécifique. Il ne s’agit pas là d’une critique à l’égard des fournisseurs. Il s’agit d’un problème structurel : les seuils par défaut sont calibrés pour un système SAP moyen, et votre système n’est pas moyen. Il présente un profil de charge de travail spécifique, des cycles de traitement par lots spécifiques, des pics d’utilisation spécifiques qui font que « 80 % du CPU » a une signification complètement différente à 14 h un mardi par rapport à 2 h le premier lundi du mois.

Les questions pertinentes ici sont de savoir si les seuils peuvent être définis par système plutôt que globalement, si l’outil prend en charge les seuils basés sur l’heure (limites différentes pendant les heures de bureau par rapport aux fenêtres de traitement par lots nocturnes), et s’il existe un mécanisme permettant d’apprendre ou de suggérer des valeurs de référence à partir des données historiques.

Une plateforme de surveillance qui nécessite la saisie manuelle de seuils pour chaque indicateur sur chaque système sera techniquement correcte, mais ignorée sur le plan opérationnel. La charge de configuration finira par pousser quelqu’un à appliquer un seuil global à tous les systèmes simplement pour faire cesser le bruit, et vous reviendrez alors au comportement par défaut avec des étapes supplémentaires.

Q4 Que fait la plateforme entre le moment où elle détecte une anomalie et celui où elle envoie une notification ?

C’est précisément dans cette phase, entre la détection d’un problème et l’envoi d’une alerte utile, que la plupart des plateformes échouent. Une alerte brute indiquant « charge CPU élevée sur PRD » à 3 h du matin signale à l’ingénieur de garde qu’il se passe quelque chose. Elle ne lui permet toutefois pas de savoir s’il s’agit de la même saturation des processus de travail qui se produit tous les lundis lors de l’exécution du MRP, ou s’il s’agit d’une véritable anomalie. Elle ne lui indique pas quels jobs d’arrière-plan étaient actifs à ce moment-là, si la mémoire HANA était également sous pression, ni s’il existe des jobs en aval sur le point de manquer leur fenêtre d’exécution en raison du pic de CPU.

La question à se poser est la suivante : montrez-moi à quoi ressemble une alerte lorsqu’elle se déclenche. Pas l’écran de configuration. La notification réelle qui arrive dans la boîte de réception ou qui crée le ticket d’incident. Contient-elle le contexte corrélé, ou se contente-t-elle d’indiquer la valeur de la métrique qui a dépassé un seuil ?

La corrélation des alertes, qui consiste à regrouper les événements liés dans une vue d’incident unique plutôt que d’envoyer cinq notifications distinctes pour cinq symptômes d’une même cause première, est la fonctionnalité qui distingue les outils de surveillance qui réduisent le bruit opérationnel de ceux qui le génèrent.

Q5  Can it detect application-level errors inside a completed job ?

This is the most specific question on this list and the one most likely to catch a vendor off guard. SAP background jobs can finish with status FINISHED while containing error messages in their spool output. The ABAP program ran to completion, but it logged message type E records along the way, often because the program handles exceptions internally rather than letting them surface as job-level failures.

For financial close jobs, payroll runs, or billing processes, this distinction is critical. A job that posted 9,400 invoices out of 9,500 because the remaining 100 had data issues looks like a successful job in SM37. The discrepancy shows up when a business user reconciles the numbers two days later.

Ask the vendor directly: if a job completes with status FINISHED but its spool log contains message class E records, does your tool alert on that? Ask them to demonstrate it. Many platforms do not have this capability because it requires parsing spool content rather than just reading the job status field, which is significantly more complex to implement.

Surveillance des tâches en arrière-plan : au-delà des codes d’état

Q6 Peut-elle surveiller la durée d’une tâche par rapport à une valeur de référence, et pas seulement son état d’achèvement ?

Une tâche batch qui s’exécute actuellement en deux fois plus de temps que d’habitude ne pose pas encore de problème. Elle pourrait bien se terminer à l’heure. Mais c’est un signal, et le détecter pendant qu’elle est encore en cours permet à l’équipe opérationnelle d’enquêter avant que la fenêtre de la tâche ne se referme et que les tâches dépendantes ne commencent à s’accumuler dans la file d’attente.

Pour générer des alertes basées sur la durée, la plateforme doit connaître la durée normale de chaque tâche. Cela signifie qu’elle doit stocker l’historique des durées d’exécution et utiliser ces données pour signaler les écarts. Cela signifie également qu’elle doit prendre en compte les variations de durée légitimes : une tâche qui s’exécute en 40 minutes un jour normal peut s’exécuter en 90 minutes en fin de mois, car le volume de données est trois fois plus important.

Demandez comment l’outil établit les références de durée. Utilise-t-il une moyenne mobile ? Permet-il des références distinctes par période (fin de mois par rapport aux jours normaux) ? Les seuils peuvent-ils être configurés en pourcentage de la référence plutôt qu’en limite de temps fixe ? Une plateforme qui ne peut alerter que sur les « tâches s’exécutant depuis plus de X minutes » nécessite un réajustement manuel constant à mesure que les volumes d’activité changent.

Intégration avec vos outils existants

Q7 Comment s’intègre-t-elle à votre plateforme ITSM, et à quoi ressemble le ticket ?

L’intégration native à un système ITSM est un argument de vente courant. Ce qui varie considérablement d’une plateforme à l’autre, c’est la qualité du contenu des tickets générés. Une intégration qui ouvre un incident ServiceNow avec pour objet « Alerte SAP : charge CPU élevée » est techniquement une intégration. Une intégration qui ouvre un incident avec le nom du système concerné, la métrique spécifique et sa valeur actuelle, les événements corrélés survenus dans le même intervalle de temps, les étapes d’investigation recommandées et un lien direct vers la transaction SAP pertinente est un outil qui aide réellement.

Demandez un exemple concret de ce à quoi ressemble un ticket d’incident créé automatiquement. Renseignez-vous spécifiquement sur le contexte propre à SAP : le ticket fait-il référence au SID concerné, au nom de la transaction ou du job, au type de processus de travail, aux entrées de journal pertinentes ? Une intégration d’alerte informatique générique traite SAP comme n’importe quel autre système surveillé. Une intégration adaptée à SAP crée des tickets sur lesquels un ingénieur SAP Basis peut agir sans avoir à tout réexaminer depuis le début.

Renseignez-vous également sur l’intégration bidirectionnelle. Lorsque l’incident est résolu dans ITSM, le statut de l’alerte est-il mis à jour dans la plateforme de surveillance ? Lorsqu’une fenêtre de maintenance est ouverte dans la plateforme de surveillance, la création d’incidents dans ITSM est-elle suspendue pendant cette période ? Ces comportements bidirectionnels font la différence entre une intégration qui fait gagner du temps et une qui entraîne un double traitement.

Coûts de déploiement et d’exploitation

Q8 Combien de temps faut-il pour passer de l’installation à une surveillance efficace de l’environnement de production ?

Le délai de rentabilisation est l’indicateur que les fournisseurs ont le plus tendance à minimiser lors des évaluations. La démonstration s’effectue sur un environnement de référence préconfiguré où tout est optimisé et où chaque tableau de bord semble parfait. Votre mise en service en production sera différente.

Demandez un calendrier de référence issu d’un déploiement client comparable, idéalement avec un nombre de systèmes et une complexité d’environnement similaires aux vôtres. Demandez spécifiquement combien de temps dure la période de collecte de données de référence avant que les alertes ne soient fiables. Demandez comment le réglage des seuils est géré pendant les premières semaines, lorsque le système est encore en train d’apprendre le comportement normal. Demandez qui est responsable de ce travail de réglage : le fournisseur, votre équipe ou un processus partagé.

Un outil qui nécessite six mois d’intervention de services professionnels avant de cesser de générer des faux positifs n’est pas une plateforme de surveillance. Il s’agit d’une mission de conseil accompagnée d’un logiciel de surveillance. Le processus de mise en service doit se mesurer en semaines, et votre équipe doit être en mesure de le mener à bien à l’aide de la documentation du fournisseur plutôt qu’avec la présence de ce dernier.

Q9 Comment gère-t-il les environnements hybrides dans lesquels certains systèmes sont sur site et d’autres hébergés sur RISE with SAP ou chez un hyperscaler ?

Cette question est devenue d’autant plus pertinente que le programme RISE with SAP de SAP accélère l’adoption du cloud par les entreprises. Le défi de la surveillance dans un environnement hybride ne se limite pas à la couverture technique. Il s’agit d’une visibilité unifiée : voir un système NetWeaver sur site et une instance S/4HANA hébergée sur RISE dans la même vue, avec des événements corrélés entre eux lorsqu’un processus métier s’étend sur les deux.

RISE with SAP mérite tout particulièrement une question spécifique, car le modèle de responsabilité partagée crée une ambiguïté que de nombreux clients n’ont pas encore pleinement cernée. SAP gère l’infrastructure et la plateforme dans RISE. Le client est propriétaire de la configuration de l’application, des extensions, des intégrations et, surtout, de l’observabilité. La plateforme de surveillance que vous choisissez doit fonctionner au sein du modèle de connectivité RISE sans obliger SAP à ouvrir un accès à l’infrastructure qui ne relève pas du périmètre standard du service.

Demandez au fournisseur s’il dispose de déploiements en production dans des environnements RISE with SAP. Demandez comment la connectivité à l’instance S/4HANA est établie. Si la réponse implique une demande de connectivité non standard auprès de SAP, cela constitue un risque d’adoption. Une plateforme qui se connecte via RFC standard à l’aide d’un utilisateur de surveillance dédié devrait fonctionner dans RISE sans aucune configuration particulière.

Rapports, résilience et coût total

Q10 À quoi ressemblent les rapports pour les personnes qui ne sont pas des ingénieurs SAP Basis ?

La surveillance SAP est souvent évaluée exclusivement par l’équipe technique qui l’utilise au quotidien. Les besoins en matière de rapports des autres parties prenantes, notamment le directeur informatique qui doit rendre compte des niveaux de service, les responsables des processus métier qui ont besoin d’une confirmation que leurs processus critiques ont été menés à bien, et le chargé de compte MSP qui a besoin de données destinées aux clients, figurent rarement sur la liste des exigences.

Une bonne plateforme de surveillance prend en charge plusieurs modes de reporting. Des tableaux de bord techniques pour l’équipe Basis. Des vues sur les niveaux de service pour la gestion des opérations. Des résumés sur l’état des processus métier pour les personnes qui sont responsables des processus, et non de l’infrastructure. Si une plateforme ne peut afficher que des données métriques brutes dans une interface dont l’interprétation nécessite des connaissances SAP, sa valeur en matière de reporting est limitée au public le plus restreint de l’organisation.

Demandez une démonstration de la couche de reporting d’un point de vue non technique. Que verrait le directeur financier s’il se connectait ? Peut-on générer un rapport indiquant si les trois processus financiers les plus critiques ont été menés à bien dans les délais prévus par le SLA le mois dernier ? Ce rapport peut-il être automatisé et envoyé par e-mail ? Si la réponse à l’une de ces questions est non, la plateforme est un outil destiné à l’équipe Basis, et non à l’organisation.

Q11 Que se passe-t-il lorsque l’outil de surveillance lui-même rencontre un problème ?

Cette question met visiblement les fournisseurs mal à l’aise, et c’est précisément pour cela qu’il vaut la peine de la poser. Les infrastructures de surveillance tombent en panne. Les collecteurs se déconnectent. Les connexions à la base de données sont interrompues. La base de données de surveillance est saturée. Et dans chacun de ces scénarios, la question est de savoir si le système de surveillance détecte et signale sa propre défaillance, ou si la seule façon de s’en rendre compte est de constater qu’un tableau de bord n’a pas été mis à jour depuis six heures.

L’auto-surveillance est une exigence fondamentale qui n’est pas systématique. Le système de surveillance doit émettre une alerte lorsque ses propres composants sont défaillants, lorsque la collecte de données s’est arrêtée pour un système spécifique, ou lorsque la transmission des alertes a échoué. Il doit disposer d’un processus de reprise documenté en cas de défaillance des collecteurs. Et idéalement, il devrait intégrer une forme de redondance pour les environnements à haute disponibilité où la continuité de la surveillance fait elle-même partie du SLA.

Demandez au fournisseur : si votre collecteur perd la connectivité avec notre système SAP à 2 h du matin, comment le saurons-nous ? Si la réponse est « vous verriez des lacunes dans les données », cela signifie que vous ne le sauriez qu’après avoir vérifié manuellement. Ce n’est pas de l’autosurveillance. C’est une absence de preuve.

Q12 Comment la tarification évolue-t-elle à mesure que votre environnement s’étend, et qu’est-ce qui est inclus dans le prix de base ?

La tarification de la surveillance SAP présente davantage de variations que la plupart des catégories de logiciels d’entreprise, et ces variations ne sont pas toujours visibles dans le devis initial. Le modèle de tarification structurel le plus courant est celui basé sur le nombre de SID surveillés, ce qui est transparent et prévisible. Les pièges résident dans ce qui est inclus dans le niveau de base et ce qui devient une option facturée séparément.

Voici les coûts des options courantes sur lesquels il convient de s’informer spécifiquement : les connecteurs ITSM (ServiceNow, Jira, BMC Remedy) facturés par intégration, la conservation des données historiques au-delà d’une période par défaut, la surveillance des systèmes hors production à un tarif différent, et l’accès à des fonctionnalités spécifiques (tableaux de bord personnalisés, accès API, surveillance des spools) réservées aux niveaux tarifaires supérieurs.

Renseignez-vous également sur ce qui se passe au moment du renouvellement. Un modèle par SID où les systèmes de production coûtent X et les systèmes hors production moins que X est simple. Un modèle où le prix est calculé par métrique collectée, ou où la tarification varie en fonction du volume de données, crée une incertitude qui s’amplifie à mesure que votre environnement s’étend. Obtenez le modèle de tarification complet par écrit avant de commencer une validation de principe, et non après avoir déjà investi trois mois dans l’évaluation.

Les 12 questions en bref

Utilisez ce résumé comme référence lors de vos entretiens avec les fournisseurs. La colonne « Critère essentiel » indique l’élément principal que chaque question vise à déterminer.

Comment utiliser cette liste de contrôle dans la pratique ?

Passez en revue ces questions avant la première démonstration du fournisseur, et non pendant celle-ci. Si vous les envoyez au fournisseur à l’avance, vous obtiendrez des réponses préparées pour les questions auxquelles il peut répondre, et des esquives ou un silence pour celles auxquelles il ne peut pas répondre. Cela en soi est révélateur.

Pendant la démonstration, demandez des démonstrations en direct des scénarios spécifiques qui vous importent. Pas une présentation générale des fonctionnalités. Montrez-moi ce qui se passe lorsque cette tâche s’éternise. Montrez-moi l’alerte qui se déclenche lorsque le volume du journal HANA dépasse 70 %. Montrez-moi à quoi ressemble le ticket dans ServiceNow. Les fournisseurs capables de démontrer le scénario spécifique que vous décrivez sont ceux qui en ont réellement la capacité. Ceux qui vous renvoient à un élément de leur feuille de route future ou à une possibilité de configuration personnalisée vous montrent leurs lacunes.

Réalisez une validation de principe dans votre environnement réel avant de prendre une décision finale. Deux à quatre semaines avec vos systèmes, vos profils de tâches et vos configurations d’alerte valent mieux que vingt heures de démonstrations. Cela mettra également en évidence la complexité du déploiement, la qualité de base et les taux de faux positifs qu’aucun environnement de démonstration ne vous montrera.

Le processus d’évaluation d’une plateforme de surveillance peut sembler être une charge supplémentaire. Ce n’est pas le cas. Le coût lié au choix d’un outil qui ne couvre pas votre environnement réel, qui déclenche des alertes que personne ne consulte ou qui passe à côté des pannes silencieuses à l’origine de vos incidents les plus coûteux, est bien plus élevé que le temps que vous passez à poser ces questions dès le départ.

Redpeaks couvre SAP NetWeaver, S/4HANA, HANA, BusinessObjects, BTP et les environnements cloud à partir d’un seul collecteur sans agent, avec des valeurs de référence pour la durée de chaque tâche, des alertes au niveau du spool et une intégration native à l’ITSM.

Demandez une démonstration sur votre propre environnement