Tests de performance SAP : charge, concurrence et outils

Les tests de performance SAP prouvent, avant le go-live, que les transactions critiques, les jobs en arrière-plan et les interfaces respectent des temps de réponse convenus quand de nombreux utilisateurs et jobs s'exécutent en même temps. D'après mon expérience, ce sont les tests de concurrence qui comptent, exécutés sur des données masquées au volume de la production, selon des critères de réussite et d'échec que le métier a validés avant la première exécution.

Ce guide s'adresse aux DSI, aux directeurs de programme et aux responsables des tests des programmes S/4HANA, y compris RISE with SAP. Il couvre ce qu'il faut tester, les données nécessaires, la rédaction des critères d'acceptation, les outils adaptés et qui est responsable de quoi. Pour la place de la performance parmi les autres types de tests, commencez par ma vue d'ensemble les tests SAP expliqués.

Les problèmes de performance dans les programmes SAP sont rarement une surprise.

Les tuiles Fiori tombent en timeout quand des centaines d'utilisateurs se connectent au début d'une équipe. Un état spécifique se fige parce que quelqu'un a lancé une sélection sans limite sur l'exercice complet contre une très grande table. Les jobs en arrière-plan se chevauchent en fin de mois et le traitement de comptabilisation s'interrompt.

Tout cela est prévisible. La seule question est de savoir si le programme l'a testé, ou si le métier le découvre avec de vraies commandes en cours.

Les tests de performance au fil de SAP Activate

1. 01

   Explore

   Identifier les risques de performance dans la conception. L'architecture et la forme des états décident des résultats avant que le code ne soit écrit.

2. 02

   Realize

   Exécuter les tests de volume et de charge à mesure que le paramétrage se stabilise. Un paramétrage partiel produit des résultats trompeurs.

3. 03

   Avant l'UAT

   Terminer le cycle de performance complet avant l'UAT, pas pendant.

4. 04

   Bascule

   Approuver la bascule selon les critères d'acceptation convenus à l'avance, pas selon des impressions.

5. 05

   Hypercare

   Surveiller les indicateurs en production pendant 30 à 60 jours. La plupart des régressions apparaissent lors du premier cycle de clôture.

Dans un système ECC sur une base de données classique, les tests de performance consistaient à tester en charge le serveur d'application et la base de données : exécution ABAP, performance SQL et planification des jobs. Le frontal était SAP GUI, qui surprenait rarement qui que ce soit.

Sur S/4HANA, avec des frontaux Fiori, des extensions sur SAP BTP et une intégration via SAP Cloud Integration, la performance dépend de plusieurs couches à la fois. Une tuile Fiori lente peut venir d'un long appel ABAP, d'un timeout de la passerelle, d'un service OData non conçu pour des requêtes simultanées ou de la latence réseau dans une configuration hybride. Tester uniquement le back-end ne le trouvera pas.

1. 01Lancement de la tuilePics de connexion en début d'équipe
2. 02Appel ODataTimeouts de la passerelle, services non conçus pour la concurrence
3. 03Traitement ABAPAppels ABAP longs
4. 04Lecture en baseSélections sans limite sur de grandes tables
5. 05AffichagePlus la latence réseau pour les sites éloignés

Un seul temps de réponse, mesuré de bout en bout

Les tests de performance SAP HANA ont leur propre particularité lors d'une conversion. Un code ECC stable se comporte différemment sur une base de données en mémoire. Beaucoup de programmes deviennent nettement plus rapides, tandis que certains produisent des profils inattendus sur des schémas de données particuliers : une non-régression propre à la conversion pour le code spécifique lourd n'est donc pas facultative.

Les flux d'intégration ajoutent leur propre risque. Des flux qui fonctionnaient en développement avec des messages de test isolés peuvent s'accumuler en file d'attente ou échouer sans bruit aux volumes de production. Les symptômes ressemblent à autre chose : échecs intermittents de commandes, factures qui ne concordent pas, données présentes dans un système et absentes d'un autre.

Les tests de performance doivent avoir lieu avant le go-live. Ceux que je considère comme importants sont les tests de concurrence : de nombreux utilisateurs et jobs qui sollicitent les mêmes transactions, tables et services au même moment.

Un seul utilisateur qui saisit une commande client en deux secondes ne prouve presque rien. La même commande avec 150 personnes qui saisissent des commandes, un traitement de livraison en arrière-plan et une interface qui comptabilise des messages entrants, voilà le test qui prédit le premier jour.

Ce tableau montre ce que prouve chaque type de test et quand l'exécuter :

Test	Ce qu'il prouve	Quand l'exécuter	Ce qu'il trouve généralement
Concurrence	De nombreux utilisateurs et jobs peuvent travailler sur les mêmes objets en même temps	Realize, une fois le paramétrage stable, puis à nouveau avant l'UAT	Attentes de verrous, pics de connexion, goulets d'étranglement de la passerelle
Charge	Le système respecte les temps de réponse au volume de pointe attendu	Realize, une fois les scripts de concurrence opérationnels	Services OData lents, états spécifiques lourds
Stress	Où le système casse au-delà des limites de conception	Avant l'UAT, si une croissance est attendue	Lacunes de dimensionnement, limites des files d'attente
Endurance	Le système tient une charge constante pendant des heures	Avant l'UAT, idéalement sur une clôture simulée	Croissance de la mémoire, conflits entre chaînes de jobs sur des exécutions répétées
Bout en bout	Le chemin complet que l'utilisateur attend respecte la cible	En parallèle des tests de charge	Problèmes invisibles quand chaque couche est testée isolément

Le mot clé des tests de charge est « attendu ». Il vous faut des volumes de transactions, des nombres d'utilisateurs et des schémas de sessions réels. Un test de charge construit sur des estimations de volume que tout le monde savait optimistes donne une réussite qui ne veut rien dire.

Le test d'endurance est celui qu'on saute le plus souvent. Les tests de volume en général sont le raccourci que les programmes prennent le plus souvent quand le calendrier se resserre, et celui qu'ils regrettent le plus.

Scriptez-les en premier. Ils couvrent la plupart des échecs qui atteignent la production.

1. Changement d'équipe et pic de connexion. Quand quelques centaines d'utilisateurs ouvrent le launchpad Fiori en même temps, l'authentification et l'affichage du launchpad s'envolent. Un système correct hors pointe peut être inutilisable dans cette fenêtre si les connexions simultanées n'ont jamais été testées.
2. Clôture mensuelle et clôture annuelle. Des comptabilisations en grand volume, des chaînes de jobs au séquencement strict et une équipe finance qui court contre une échéance fixe. Exécutez les chaînes de jobs de clôture de bout en bout avec les volumes de la période de clôture, pas avec des moyennes quotidiennes.
3. Les jobs en arrière-plan qui se chevauchent. Les traitements par lots sont généralement testés un par un, ce qui ne reflète pas la réalité. Un job mal optimisé peut en bloquer plusieurs autres, et la clôture dépasse sa fenêtre.
4. Les états spécifiques sans limite de sélection. Un état qui répond instantanément sur des données de test peut tourner pendant des minutes sur un exercice complet. Testez les sélections typiques et les pires cas, et bloquez les sélections sans limite.
5. Les utilisateurs multirégions. La latence réseau affecte chaque transaction. RISE transfère l'hébergement à SAP, mais la latence dépend toujours de la région choisie et du routage vers vos utilisateurs : testez donc depuis les sites les plus éloignés.

Mon guide de migration d'ECC vers S/4HANA explique où les tests de conversion s'insèrent dans le plan d'ensemble.

Des données de test au niveau de la production

Ce sont les données qui décident si tout cela a un sens. J'insiste sur des données masquées au niveau de la production : le volume et le réalisme de la production, avec les champs personnels et sensibles masqués.

Un client avec 200 000 lignes de commande ouvertes ne se comporte pas comme un client qui en a 5 000. Des filtres qui répondent instantanément dans un mandant de test maigre tombent en timeout en production. Alimentez le volume des zones à haut risque, utilisez un mix de transactions représentatif et faites de vrais appels d'interface quand c'est possible.

La façon d'obtenir ces données en toute sécurité, par des copies, des outils de données de test sélectives et le masquage, est décrite dans mon guide sur la gestion des données de test SAP. Planifiez le rafraîchissement avant le premier cycle de performance, car il prend plus de temps que ce que prévoient la plupart des plans de test.

Convenez des critères avec le métier pendant la phase Prepare, avant toute exécution. Chacun nomme la transaction ou le job, la charge et le seuil.

Ces exemples montrent la forme. Fixez vos propres chiffres à partir des besoins opérationnels :

Élément	Condition de charge	Seuil de réussite	Responsable
Création de commande client (VA01 ou application Fiori)	150 utilisateurs simultanés en saisie de commandes	Moins de 3 secondes pour 95 % des transactions	Responsable du processus order-to-cash
Premier chargement du launchpad Fiori en début d'équipe	Pic de connexions simultanées pour l'équipe la plus nombreuse	Moins de 5 secondes pour 95 % des utilisateurs	Responsable des opérations informatiques
Chaîne de jobs de clôture mensuelle	Volumes de la période de clôture, séquence complète	Se termine dans la fenêtre de clôture convenue, sans interruption	Contrôleur financier
Interface de commandes entrantes	Volume horaire de messages en pointe	Aucun message en file d'attente depuis plus de 15 minutes	Responsable de l'intégration
État spécifique à fort volume	Volume complet des données de production, sélection typique	Moins de 60 secondes ; sélections sans limite bloquées	Propriétaire de l'état

« Le système doit être assez rapide pour les opérations métier » ne peut être ni testé ni accepté. Changer les critères après l'arrivée des résultats leur retire tout intérêt.

Si le système a été accepté parce que les utilisateurs de l'UAT l'ont trouvé rapide, vous avez une impression, pas un critère d'acceptation. Faites des résultats un jalon formel avant la bascule, comme le décrit mon guide sur les quality gates SAP. Le plan d'ensemble des cycles, avec les critères d'entrée et de sortie de chaque phase de test, a sa place dans votre stratégie de test S/4HANA.

Les outils de tests de performance SAP

Un test de performance a besoin de trois choses : un générateur de charge capable de piloter les protocoles SAP, une supervision côté SAP et un endroit où gérer les cas de test et les résultats. LoadRunner est l'outil de charge que j'ai fait utiliser par mes équipes sur des programmes SAP. Nommez l'outil tôt dans le plan de test, car les licences, les générateurs de charge et les compétences de scripting demandent tous du temps à organiser.

Les principales options en 2026 :

Outil	Rôle	À savoir
OpenText Professional Performance Engineering	Génération de charge	Le produit anciennement appelé LoadRunner Professional. Ses lots de protocoles couvrent SAP, SAP GUI et SAP Web
Tricentis NeoLoad	Génération de charge	Tricentis annonce la prise en charge de SAP GUI, Fiori, RFC et IDoc, et il peut réutiliser des éléments Tricentis Tosca
Apache JMeter	Génération de charge	Open source. Pilote du trafic HTTP comme les appels Fiori et OData
SAP Cloud ALM	Gestion des tests	Prépare et exécute des cas de test manuels et automatisés et suit les anomalies. Il ne génère pas de charge lui-même
SAP Solution Manager	Gestion des tests	La maintenance standard prend fin le 31 décembre 2027 : planifiez donc les nouveaux travaux dans Cloud ALM

Pour une vue plus large des outils fonctionnels et d'automatisation, consultez ma comparaison des outils de test et de validation SAP. L'outil compte moins que les scripts, les données et les critères.

RISE with SAP partage la responsabilité

Avec RISE with SAP, SAP est responsable de l'infrastructure : dimensionnement, région de l'hyperscaler, réseau et disponibilité de la plateforme. Le client et le partenaire sont responsables de la couche applicative.

Le document des rôles et responsabilités RISE de SAP est clair sur ce point. L'exécution des tests de charge et l'optimisation des requêtes SQL coûteuses relèvent des SAP Cloud Application Services, facturés en supplément. Si vous ne les achetez pas, c'est le client qui fait le travail.

Un échec courant sur les programmes RISE est de supposer que SAP détectera les problèmes de performance parce qu'il gère l'infrastructure. Il détectera les problèmes d'infrastructure. Inscrivez la répartition dans la charte et dans le plan de test :

1. SAP : disponibilité de l'infrastructure et temps de réponse au niveau de la plateforme
2. Partenaire : performance applicative sous la charge définie, y compris les extensions et les flux d'intégration
3. Client : résultats au niveau des processus, comme la durée de la clôture et le débit de commandes, et la décision d'acceptation

Le cloud public réduit le périmètre

Sur l'édition publique du cloud ERP de SAP, le système tourne sur une plateforme partagée exploitée par SAP. Avant de planifier un test de charge sur un tenant, demandez par écrit à SAP s'il est autorisé et quel préavis il exige.

Vos tests se concentrent alors sur ce qui vous appartient : intégrations spécifiques, extensions, états à fort volume, séquence de clôture et chemin réseau depuis vos sites. Les problèmes de performance de la plateforme relèvent du support SAP.

Les erreurs courantes

1. Considérer les tests fonctionnels comme des tests de performance. Les tests fonctionnels prouvent qu'une transaction donne le bon résultat. Ils ne disent rien de 150 personnes qui l'exécutent en même temps.
2. Laisser la performance à l'équipe Basis. L'équipe Basis est responsable du dimensionnement et de la planification des jobs. Elle n'est pas responsable de la conception des états, de l'architecture des services OData ni de la conception des flux d'intégration, et ce sont eux qui déterminent la performance applicative.
3. Confier la responsabilité à la seule équipe qualité. L'équipe qualité exécute les tests et rapporte les résultats, mais les décisions qui causent les problèmes de performance se prennent en conception. Un responsable des tests ou un architecte au niveau du programme doit avoir l'autorité de les contester tôt, et la matrice RACI doit dire qui peut bloquer le go-live pour des raisons de performance.
4. Accepter les manques comme des problèmes connus. La plupart des programmes qui ont des problèmes de performance en production n'ont pas sauté les tests. Ils ont testé sans critères convenus, ou ont testé puis accepté les échecs sous la pression du calendrier.

Rédigez les cinq ou six critères d'acceptation de vos transactions et jobs les plus à risque, avec un responsable nommé pour chacun. Si vous ne pouvez pas remplir le tableau ci-dessus, vous n'êtes pas prêt à tester, et vous avez trouvé le premier manque.

Vérifiez ensuite deux choses : qu'un rafraîchissement de données masquées au volume de la production est prévu au plan, et que le cycle de concurrence se termine avant le début de l'UAT.

Si vous souhaitez un regard indépendant sur un plan de tests de performance ou une décision de go-live, j'accompagne les organisations sur ce sujet. Vous pouvez me contacter ici.

Que sont les tests de performance SAP ?

Ils vérifient le comportement de SAP sous une charge réaliste : temps de réponse des transactions utilisateur, durée des jobs en arrière-plan, débit des interfaces et consommation des ressources quand de nombreuses personnes travaillent en même temps. Ils doivent être réalisés avant le go-live.

L'exactitude fonctionnelle et la performance sont deux propriétés différentes. Une transaction correcte pour un utilisateur peut tomber en timeout pour 200.

Quand les tests de performance doivent-ils commencer dans un programme SAP ?

L'identification des risques commence en Explore, car les choix d'architecture déterminent les résultats de performance. Les tests proprement dits commencent en Realize, une fois le paramétrage assez stable pour que les résultats aient un sens.

Terminez le dernier cycle avant l'UAT, pas pendant. Des anomalies de performance découvertes en UAT compriment le planning et poussent à les accepter comme des problèmes connus.

Quelle est la différence entre test de charge et test de concurrence dans SAP ?

Le test de charge vérifie les temps de réponse au volume de pointe attendu. Le test de concurrence vérifie ce qui se passe quand de nombreux utilisateurs et jobs travaillent sur les mêmes transactions, tables et services au même moment. C'est là qu'apparaissent les attentes de verrous, les pics de connexion et les goulets d'étranglement de la passerelle.

D'après mon expérience, ce sont les tests de concurrence qui comptent. Exécutez-les d'abord, puis construisez le test de charge complet par-dessus.

Quelles données de test utiliser pour les tests de performance SAP ?

Des données masquées au niveau de la production. Cela signifie le volume et le réalisme de la production, avec les champs personnels et sensibles masqués. Des données de test maigres cachent les filtres lents, les états lourds et les longues durées de jobs qui apparaissent dès le premier jour.

Quels outils utilise-t-on pour les tests de performance SAP ?

Des générateurs de charge comme OpenText Professional Performance Engineering (anciennement LoadRunner Professional), Tricentis NeoLoad et Apache JMeter produisent la charge. SAP Cloud ALM ou SAP Solution Manager gèrent les cas de test et les résultats, et la supervision côté SAP montre ce que le système a fait sous charge.

Qui est responsable des tests de performance avec RISE with SAP ?

SAP est responsable de l'infrastructure : dimensionnement, région, réseau et disponibilité de la plateforme. Le document des rôles et responsabilités RISE de SAP laisse l'exécution des tests de charge et l'optimisation des requêtes SQL coûteuses au client, sauf si les SAP Cloud Application Services sont achetés en supplément.

Le client et le partenaire sont responsables de la performance applicative et de la décision d'acceptation. Inscrivez la répartition dans les critères d'acceptation pour que chaque seuil ait un responsable.