Tests de performance SAP : ce que les DSI doivent savoir

Les tests de performance SAP démontrent, avant le go-live, que les transactions critiques, les jobs d'arrière-plan et les interfaces respectent les temps de réponse convenus avec les volumes de production. Démarrez-les dès la conception, menez les tests de volumétrie et de charge dans Realize une fois le paramétrage stabilisé, terminez le cycle avant les tests d'acceptation utilisateur (UAT) et faites des résultats une condition de validation de la bascule. Ce guide s'adresse aux DSI, aux directeurs de programme et aux responsables de tests des programmes S/4HANA, y compris RISE with SAP. Il couvre ce qu'il faut tester, qui en est responsable, comment rédiger les critères d'acceptation et ce qui change dans le cloud. Commencez par le tableau des critères d'acceptation : si vous ne pouvez pas le remplir, vous n'êtes pas prêt à tester.

Dans les programmes SAP, les problèmes de performance sont presque toujours découverts après le go-live. Les tuiles Fiori tombent en timeout quand 300 utilisateurs se connectent au changement d'équipe. Des Z-reports se figent parce que quelqu'un a lancé une requête sur l'exercice complet, sans limite de sélection, sur une table de 50 millions d'enregistrements. Des jobs d'arrière-plan se chevauchent pendant la clôture mensuelle et le traitement de comptabilisation s'interrompt en erreur.

Dans les programmes SAP, ces problèmes arrivent rarement par surprise. La plupart étaient prévisibles, mais personne ne les avait planifiés. Le schéma habituel : les tests fonctionnels ont été rigoureux. Les tests de volumétrie étaient prévus, puis repoussés quand le calendrier s'est resserré. Les conséquences sont arrivées dans les premières semaines d'exploitation.

Ce ne sont pas des cas limites. Ils sont prévisibles. La seule question est de savoir si le programme les a testés, ou si le métier les découvre avec de vraies commandes en cours.

Les tests de performance tout au long de SAP Activate

1. 01

   Explore

   Identifiez les risques de performance dans la conception. L'architecture et la forme des rapports décident du résultat avant la première ligne de code.

2. 02

   Realize

   Lancez les tests de volumétrie et de charge à mesure que le paramétrage se stabilise. Un paramétrage partiel produit des résultats trompeurs.

3. 03

   Avant l'UAT

   Terminez le cycle de performance complet avant l'UAT, et non pendant.

4. 04

   Bascule

   Validez la bascule d'après les critères d'acceptation convenus à l'avance, pas d'après une opinion.

5. 05

   Hypercare

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

Sur un système ECC avec une base de données classique, tester la performance revenait à tester en charge le serveur d'applications et la base : temps d'exécution ABAP, performance SQL, ordonnancement des jobs. Le front end était SAP GUI, qui réservait rarement des surprises.

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

1. 01Lancement de la tuilePics de connexions au début de l'équipe
2. 02Appel ODataTimeouts de la passerelle, services non conçus pour la simultanéité
3. 03Traitement ABAPAppels ABAP de longue durée
4. 04Lecture en baseSélections sans limite sur de grandes tables
5. 05AffichagePlus la latence réseau des sites éloignés

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

Les flux d'intégration ajoutent leur propre risque. Des flux qui fonctionnaient en développement et en environnement de qualité (QA) avec des messages de test isolés peuvent s'empiler ou échouer en silence aux volumes de production. Si les files de messages ne sont pas dimensionnées pour la charge réelle, les retards s'accumulent. Les symptômes ressemblent à autre chose : des échecs de commandes intermittents, des écarts de facturation, des données présentes dans un système et absentes d'un autre.

1. Les tests de charge vérifient le comportement sous le volume attendu. Le mot clé est « attendu ». Il vous faut de vrais volumes de transactions, de vrais nombres d'utilisateurs et de sessions simultanées. Beaucoup de tests de charge échouent parce qu'ils s'appuient sur des estimations de volume que tout le monde savait déjà optimistes.
2. Les tests de contrainte (stress) dépassent les limites de conception pour trouver le point de rupture du système. Si les volumes doivent doubler dans dix-huit mois, ils indiquent si l'architecture tiendra, et si le dimensionnement deviendra un problème avant la prochaine revue d'infrastructure.
3. Les tests d'endurance (soak) appliquent une charge constante sur une longue durée pour révéler les problèmes qui s'installent avec le temps : fuites de mémoire, fragmentation et contention entre chaînes de jobs au fil des exécutions répétées. C'est le test le plus souvent sauté, et celui qui aurait détecté l'échec de clôture mensuelle décrit plus bas.
4. Les tests de bout en bout suivent le parcours complet d'un utilisateur : lancement de la tuile, appel OData, traitement ABAP, lecture en base, affichage. C'est le seul moyen de trouver des problèmes invisibles quand chaque couche est testée isolément.

Changement d'équipe et pic de connexions. Quand 200 utilisateurs ouvrent le launchpad Fiori à 8 h, l'authentification et l'affichage du launchpad subissent un pic. Un système sans problème en heures creuses peut devenir inutilisable sur ce créneau si les connexions simultanées n'ont jamais été testées. Dans l'industrie, la distribution et les services financiers, les pics de connexions provoquent les plaintes les plus visibles dès le premier jour.

Clôture mensuelle et clôture annuelle. Le scénario le plus risqué sur la plupart des programmes : des comptabilisations en gros volumes, des chaînes de jobs au séquencement strict et une équipe finance qui court après une échéance fixe. Exécutez les chaînes de jobs de clôture de bout en bout avec les volumes d'une période de clôture, pas avec les moyennes quotidiennes.

Les jobs batch sont généralement testés isolément, ce qui ne reflète pas la réalité. En fin de mois, le traitement en arrière-plan atteint son pic et de nombreux programmes tournent en parallèle sur les mêmes ressources. Un seul job mal optimisé peut en bloquer cinq autres, et la clôture dépasse sa fenêtre.

Conversion d'ECC vers S/4HANA. Un code ECC stable se comporte différemment sur HANA. Beaucoup de programmes deviennent nettement plus rapides ; certains produisent des profils inattendus sur des schémas de données particuliers. Les tests de non-régression propres à la conversion ne sont pas facultatifs. Mon guide de migration d'ECC vers S/4HANA explique où ils s'inscrivent dans le plan de conversion.

Utilisateurs multi-régions. La latence réseau affecte chaque transaction. Une commande client qui prend deux secondes dans le pays d'hébergement peut sembler cassée à 3 000 miles de là si personne n'a testé depuis cet endroit. RISE confie l'hébergement à SAP, mais la latence dépend toujours de la région choisie et du routage vers vos utilisateurs.

Convenez des critères avec le métier pendant la phase Prepare, avant tout test. 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 de saisie de commandes simultanés	Moins de 3 secondes pour 95 % des transactions	Propriétaire du processus order-to-cash
Premier chargement du launchpad Fiori au début de l'équipe	Pic de connexions simultanées de la plus grande équipe	Moins de 5 secondes pour 95 % des utilisateurs	Responsable de l'exploitation informatique
Chaîne de jobs de clôture mensuelle	Volumes d'une période de clôture, séquence complète	Se termine dans la fenêtre de clôture convenue, sans arrêt en erreur	Contrôleur financier
Interface de commandes entrantes	Volume horaire de messages au pic	Aucun retard dans la file supérieur à 15 minutes	Responsable de l'intégration
Rapport spécifique à gros volume	Volume complet des données de production, sélection typique	Moins de 60 secondes ; sélections sans limite bloquées	Propriétaire du rapport

« Le système doit être assez rapide pour les opérations métier » ne peut être ni testé ni accepté. Modifier les critères une fois les résultats connus ruine l'intérêt d'en avoir.

Demandez chacun de ces éléments nommément :

Attente	Ce qui doit être livré	Pourquoi c'est important
Niveaux de service de performance	Des seuils par transaction, interface et job, avec critères de réussite et d'échec	Empêche l'opinion issue de l'UAT de l'emporter sur les preuves
Périmètre fondé sur les risques	Priorisation selon le nombre d'utilisateurs, les points d'intégration et la dépendance aux données	Concentre les cycles de test sur les charges qui comptent
Participation de toutes les équipes	Basis, infrastructure, fonctionnel, sécurité et intégration présents pendant les exécutions	Évite le renvoi de responsabilités quand des écarts apparaissent
Outils et environnements prêts	Générateurs de charge (OpenText LoadRunner, Tricentis NeoLoad, Apache JMeter), supervision et rafraîchissements de données en place avant le début des cycles	Rend la simulation réaliste
Données de test réalistes	Données de base au volume de production, vrais appels d'interface, mix de transactions représentatif	Rend les résultats prédictifs du comportement au go-live
Rapports de performance	Mix de charge, temps de réponse, CPU et mémoire, durées des jobs, taux d'erreur	Donne à la validation de la bascule une base de preuves
Plan de supervision après le go-live	KPI à suivre pendant les 30 à 60 premiers jours	Confirme que le système en production reste dans les limites testées

Quatre erreurs reviennent le plus souvent, même dans de grandes entreprises aux méthodes de delivery bien rodées.

Confondre tests fonctionnels et tests de performance. Les tests fonctionnels prouvent qu'une transaction donne le bon résultat. Ils ne disent rien de ce qui se passe quand 150 personnes la lancent en même temps.

Tester avec de petits volumes de données. Un client avec 200 000 lignes de commande ouvertes se comporte autrement qu'un client qui en a 5 000. Des filtres qui répondent instantanément en test expirent en production. Chargez des volumes réalistes dans les zones à haut risque.

Laisser la performance à Basis. Basis est responsable du dimensionnement et de l'ordonnancement des jobs. Il ne l'est ni de la conception des rapports, ni de l'architecture des services OData, ni de la conception des flux d'intégration, et ce sont eux qui pilotent la performance applicative.

Confier la responsabilité à la seule équipe QA. La QA exécute les tests et rapporte les résultats. Les décisions qui causent les problèmes de performance sont prises par les équipes fonctionnelles, techniques et Basis pendant la conception. Un responsable des tests ou un architecte au niveau du programme doit avoir l'autorité de les remettre en cause tôt, et la matrice RACI doit préciser qui peut bloquer le go-live pour des raisons de performance.

RISE partage la responsabilité

Avec RISE with SAP, SAP est responsable de l'infrastructure : dimensionnement, région du 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 de RISE de SAP le dit sans détour : repérer et optimiser les instructions SQL coûteuses reste à la charge du client, sauf si vous achetez les services applicatifs complémentaires de SAP.

Une défaillance courante sur les programmes RISE tient à l'hypothèse que SAP détectera les problèmes de performance puisqu'il exploite l'infrastructure. Il détectera les problèmes d'infrastructure. Il ne détectera pas un service OData mal conçu, un job ABAP inefficace ou un flux d'intégration qui ne passe pas à l'échelle. Inscrivez ce partage dans la charte du programme et dans le plan de test :

1. SAP : disponibilité de l'infrastructure et 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 des commandes, et la décision d'acceptation

Public Edition et GROW réduisent le périmètre

Sur S/4HANA Cloud Public Edition, généralement acheté via GROW with SAP, SAP réalise les tests de performance de sa plateforme multi-tenant dans le cadre de son propre standard produit et n'attend pas des clients qu'ils testent en charge le système partagé. Vos tests se déplacent vers ce qui vous appartient : intégrations spécifiques, extensions, rapports et analyses à gros volume, séquence de clôture et de consolidation, et chemin réseau depuis vos sites. Les problèmes de performance de la plateforme elle-même relèvent du support SAP.

L'IA aide pour les scripts, pas pour l'architecture

Les éditeurs d'outils de test de charge ajoutent de l'IA pour la maintenance des scripts et l'analyse des résultats, ce qui aide sur les programmes où l'application change d'un cycle à l'autre. Vérifiez ces promesses sur votre propre paysage avant de payer. SAP Cloud ALM peut aider à générer des cas de test et des exigences, et les assistants IA peuvent rédiger des ébauches de scénarios à partir de descriptions de processus.

Rien de cela ne corrige l'architecture. L'IA ne vous dira pas que le service OData aurait dû être conçu autrement, ni qu'un rapport est trop lourd pour ses volumes. Ces décisions restent prises par des personnes, en conception, avant tout test.

La plupart des programmes qui ont des problèmes de performance en production n'ont pas totalement sauté les tests. Ils ont testé sans critères convenus, ou testé puis accepté les écarts comme des anomalies connues sous la pression du calendrier. La discipline est dans les critères et dans leur application, pas dans l'outil. Pour situer la performance parmi les autres types de tests, consultez ma comparaison des outils de test et de validation SAP et mon guide des quality gates SAP.

Qu'est-ce que le test de performance SAP et pourquoi est-ce important ?

Il vérifie le comportement de SAP sous une charge réaliste : temps de réponse des transactions utilisateur, durées d'exécution des jobs d'arrière-plan, débit des interfaces et consommation de ressources en travail simultané.

L'exactitude fonctionnelle et la performance sont deux propriétés distinctes. Une transaction correcte pour un utilisateur peut expirer pour 200. Un job qui s'exécute en dix minutes sur des données de test peut tourner pendant des heures avec les volumes de production. Le découvrir après le go-live perturbe l'exploitation, impose des changements en urgence et abîme la confiance des utilisateurs au moment où l'adoption est la plus fragile.

Quand les tests de performance doivent-ils démarrer dans un programme SAP ?

L'identification des risques commence dans Explore, parce que les choix d'architecture déterminent les résultats de performance. Les tests proprement dits commencent dans Realize, dès que le paramétrage est assez stable pour que les résultats aient un sens. Un paramétrage partiel donne des chiffres trompeurs.

Terminez le dernier cycle avant l'UAT, pas pendant. Les défauts de performance trouvés en UAT compriment le calendrier restant et poussent à les accepter comme anomalies connues.

À qui revient la responsabilité des tests de performance SAP ?

Au programme, pas à la seule équipe QA. La QA exécute et rapporte, mais les décisions qui déterminent la performance sont prises en conception par les équipes fonctionnelles, techniques et Basis. Un architecte central ou un responsable des tests du programme doit avoir l'autorité de les remettre en cause tôt.

Rendez-le explicite dans la matrice RACI : qui approuve les critères d'acceptation, qui est responsable de la correction quand les critères ne sont pas atteints, et qui peut bloquer le go-live pour des raisons de performance.

Comment RISE with SAP change-t-il la responsabilité des tests de performance ?

SAP est responsable de l'infrastructure : dimensionnement, région, réseau et disponibilité de la plateforme. Le client et le partenaire sont responsables de la performance applicative : paramétrage, extensions, conception OData et Fiori, flux d'intégration et KPI de processus. Le document des rôles et responsabilités de RISE laisse l'optimisation SQL au client, sauf achat de services SAP complémentaires.

Inscrivez ce partage dans les critères d'acceptation pour que chaque seuil ait un responsable.

Quels sont les problèmes de performance SAP Fiori les plus courants ?

Quatre schémas couvrent l'essentiel. Les pics de connexions au début de l'équipe, quand l'authentification et l'affichage du launchpad subissent un pic. Les services OData qui renvoient de gros jeux de résultats ou font plusieurs appels back end par interaction. La couche passerelle qui devient elle-même un goulet d'étranglement et doit donc être supervisée pendant les tests. Et les applications spécifiques ou fortement modifiées, où les hypothèses de performance standard ne s'appliquent pas.

Comment définir les critères d'acceptation de performance pour SAP ?

Nommez la transaction, la charge et le seuil. Par exemple : « La création de commande se termine en moins de 3 secondes pour 95 % des transactions avec 150 utilisateurs simultanés dans le rôle de saisie de commandes. » C'est testable.

« Le système doit être assez rapide » ne l'est pas. Convenez des critères avec le métier pendant la phase Prepare, à partir de besoins opérationnels réels, et ne les modifiez pas une fois les résultats connus.

Que se passe-t-il si les tests de performance sont sautés ou comprimés ?

Les problèmes apparaissent en production : des jobs qui dépassent leur fenêtre et en bloquent d'autres, des applications Fiori qui expirent au pic, une clôture mensuelle deux fois plus longue qui manque les échéances de reporting, des files d'interfaces qui s'engorgent.

Les utilisateurs confrontés à des problèmes de performance dans leurs premières semaines se forgent une image négative du système, difficile à inverser. Et la correction en urgence en exploitation coûte plus cher que les tests n'auraient coûté, car ce qui était une décision de conception dans Realize devient un changement d'architecture urgent.