Introduction : le Go-Live, moment de vérité de la Basis
Il y a quelque chose de très particulier dans un Go-Live SAP. Pendant dix-huit mois, les equipes projet debattent de configuration fonctionnelle, de specifications, de tests d'integration. Puis arrive le jour J, et c'est la Basis qui tient le système a bout de bras. Si la couche technique n'est pas taillee pour la charge reelle, tout le reste s'effondre. J'ai vu des projets impeccables au niveau fonctionnel echouer dans les trois premiers jours de production parce qu'un parametre de work process etait mal dimensionne, ou parce qu'un buffer ABAP debordait en continu.
Dans cet article, je reviens sur les dix leviers Basis que je vérifié systématiquement avant chaque mise en production, que ce soit sur S/4HANA Private Cloud Edition, sur On-Premise, ou sur une plateforme hybride avec BTP. Les exemples chiffres viennent de projets reels menes dans l'énergie, la defense et l'industrie sur les dernières années.
Levier 1 : le dimensionnement des work processes
Comprendre les types de WP
SAP distingue six types de work processes : DIA (dialog), UPD (update V1), UP2 (update V2), BTC (batch), SPO (spool) et ENQ (enqueue). Chacun consomme de la memoire, chacun a un role spécifique. Le mauvais reflexe consiste a multiplier les DIA en pensant absorber la charge : cela reduit en fait les performances globales parce que chaque WP ajoute une surcharge memoire significative.
Les valeurs à retenir par type de WP sont à calibrer selon la RAM disponible, le nombre d'utilisateurs concurrents et le profil de charge — aucune plage universelle ne s'applique. À titre de point de départ terrain (à valider via SAP Note 1021005, accès S-user requis) pour un serveur d'application de 64 GB de RAM dédiés à SAP :
- rdisp/wp_no_dia : à ajuster selon le nombre d'utilisateurs concurrents
- rdisp/wp_no_btc : à dimensionner selon le volume de jobs batch et les fenêtres de traitement
- rdisp/wp_no_upd : typiquement quelques WP, selon le volume d'update V1
- rdisp/wp_no_upd2 : idem pour l'update V2
- rdisp/wp_no_enq = 1 (toujours un seul sur le serveur central — valeur fixe)
- rdisp/wp_no_spo : selon le volume d'impression
Le piège du ratio DIA/BTC
Chez un gestionnaire de réseau énergétique, le Go-Live avait été préparé avec 40 DIA et 5 BTC. Des le deuxième jour, la file d'attente batch explosait : les traitements de releve de compteurs prévus pour s'executer entre 23h et 5h debordaient jusqu'à 11h du matin, bloquant les jobs de facturation. La solution a ete de rebasculer vers 25 DIA et 15 BTC après observation fine de la charge reelle dans SM50 et SM66.
La surveillance via SM50 et SM66
SM50 montre les WP du serveur courant, SM66 les WP de tous les serveurs d'application. Pendant les 72 heures après Go-Live, un membre de l'equipe Basis doit monitorer ces transactions en continu, avec un seuil d'alerte — à calibrer selon le profil du système — généralement fixé à partir de 80% de WP occupés à titre indicatif. Au-delà du seuil retenu, on bascule immédiatement des DIA vers des BTC ou on redémarre les sessions fantômes.
Levier 2 : sizing memoire HANA, la zone critique
Le calcul reel, pas le calcul Quick Sizer
SAP Quick Sizer fournit des estimations basees sur le nombre d'utilisateurs et de documents. Dans la pratique, d'après les retours terrain de la communauté Basis, il peut sous-estimer les besoins mémoire HANA pour des systèmes chargés en données historiques — aucune étude SAP officielle ne quantifie cet écart. La formule heuristique que j'utilise comme point de départ (heuristique terrain, non prescrite par SAP — à valider via SAP Note 1999997 et le SAP HANA Sizing Tool officiel) :
- Taille mémoire HANA = (taille totale row store + column store après compression) × 2 + 50 GB overhead
Le facteur 2 couvre les besoins de delta store, de processing, et laisse une marge pour les pics. Pour un système S/4HANA avec 4 TB de données compressées, cette heuristique conduit à viser au moins 8 TB de RAM — à confirmer avec le SAP HANA Sizing Tool avant tout achat de matériel.
Les parametres critiques
- global_allocation_limit : plafond de memoire que HANA peut allouer. La valeur par défaut (0) déclenche un calcul automatique par HANA (environ 90 % des premiers 64 Go + 97 % au-delà) — il n'y a généralement pas lieu de la modifier manuellement.
- statement_memory_limit : plafond par requete. La valeur par défaut est 0 (sans limite par statement) ; ajuster en fonction des explosions de consommation constatées dans M_EXPENSIVE_STATEMENTS (valeur de départ à calibrer selon la taille mémoire de l'instance — SAP HANA Administration Guide).
- PHYS_MEMSIZE cote serveur d'application ABAP : doit être explicite et cohérent avec la RAM disponible, sinon SAP applique des heuristiques dangereuses.
Le cas defense
Sur un projet pour un industriel de la défense, le système S/4HANA 2023 passait en production avec 3 TB de RAM HANA pour 2,1 TB de données. Après deux semaines, les pics de memoire atteignaient 2,9 TB en periode de cloture mensuelle. Nous avons du ajouter 1 TB en urgence pour éviter les out-of-memory sur les requetes de consolidation financiere. Lecon : toujours dimensionner pour le pire mois, pas pour la moyenne.
Levier 3 : les buffers ABAP, souvent oublies
ST02, le tableau de bord indispensable
La transaction ST02 affiche l'état des buffers ABAP : Table buffer, Program buffer, CUA buffer, Screen buffer, etc. La colonne critique a surveiller est "Swaps" : toute valeur croissante indique que le buffer est trop petit et que SAP recharge sans cesse des objets depuis la base.
Les seuils de référence que je me fixe (seuils indicatifs terrain — observer via ST02 sous charge et calibrer selon le profil système ; aucune valeur officielle SAP n'est prescrite publiquement) :
- Program buffer hit ratio > 98%
- Table buffer swaps < 1000 par jour
- CUA buffer fill < 70%
Si un seul de ces critères n'est pas respecte, il faut augmenter le parametre correspondant (abap/buffersize pour le program buffer, zcsa/table_buffer_area pour les tables).
L'exemple du program buffer sous-dimensionne
Chez un acteur du BTP, j'ai observé après Go-Live un program buffer à 400 MB avec un hit ratio de 92%. Les utilisateurs se plaignaient de lenteurs sur les transactions métier Fiori. En passant abap/buffersize de 400000 à 1200000 (1,2 GB), le hit ratio est remonte a 99% et les temps de reponse Fiori ont chute de 40%.
Levier 4 : les parametres memoire par session
Les quatre parametres qui comptent
- ztta/roll_area : mémoire roll par work process — valeur à calibrer selon le profil de charge (point de départ terrain usuel : quelques MB, à ajuster selon votre contexte)
- ztta/roll_extension : extension autorisée — à dimensionner selon la taille mémoire de l'instance et le volume de traitement ; aucune valeur universelle prescrite par SAP
- abap/heap_area_dia : heap max pour un WP dialog — à calibrer selon la RAM disponible pour l'instance ABAP
- abap/heap_area_total : heap total pour l'ensemble des WP — à aligner avec PHYS_MEMSIZE et la RAM allouée à l'instance
Si abap/heap_area_total est mal calibre, les gros traitements provoquent des TSV_TNEW_PAGE_ALLOC_FAILED, dumps catastrophiques pour les utilisateurs finaux.
La dependance avec PHYS_MEMSIZE
PHYS_MEMSIZE doit refleter la RAM reellement disponible pour l'instance SAP. SAP utilise cette valeur pour calculer automatiquement plusieurs derives. Sur un serveur de 128 GB avec HANA en co-deployment, PHYS_MEMSIZE pour l'instance application doit être explicitement borné pour éviter que les deux processus se marchent dessus — la valeur exacte dépend de la répartition mémoire entre HANA et l'instance ABAP (à définir selon votre sizing et les recommandations SAP HANA Administration Guide pour les déploiements co-résidents).
Levier 5 : l'analyse ST04 et les requetes coûteuses
Les expensive statements
ST04 sur HANA donne acces a M_EXPENSIVE_STATEMENTS, qui liste les requetes ayant consomme plus de ressources qu'un seuil parametrable. Je fixe ce seuil à titre indicatif à 5 secondes ou 1 GB de mémoire traitée dans les premiers jours de production (points de départ indicatifs à ajuster selon le volume de requêtes et le profil de charge — aucune valeur officielle SAP n'est prescrite publiquement pour ce seuil de départ).
Les requêtes les plus coûteuses appartiennent souvent à du code custom mal écrit : jointures implicites, SELECT *, absence d'indices sur les colonnes de filtrage. Dans les 48 à 72 heures après Go-Live, une chasse systématique aux requêtes au-delà de 10 secondes permet selon notre expérience terrain de réduire significativement la charge CPU HANA.
Le cas industriel : une requete a 400 secondes
Sur un Go-Live S/4HANA chez un équipementier industriel, ST04 a remonté dès le jour 1 une requête Z custom s'exécutant en 420 secondes, appelée 80 fois par heure. Elle faisait un FULL scan d'une table de mouvements de stock à 90 millions de lignes. Ajouter un index secondaire approprie a ramene le temps a 2 secondes. Sans cette action, le système s'effondrait dans la semaine.
Levier 6 : la gestion des verrous (lock analysis)
SM12 et la detection des verrous orphelins
Les verrous SAP sont gérés par le serveur enqueue. Un verrou orphelin, laisse par un processus interrompu, bloque les autres sessions et provoque des effets en cascade. SM12 permet de lister et supprimer ces verrous. En production, je mets en place un job automatique qui détecte les verrous dormants au-delà d'un seuil à calibrer selon le SLA du processus métier concerné (point de départ usuel : 30 minutes, à adapter) et qui alerte la Basis.
DB01 pour les verrous base de données
Au-dela des verrous SAP, la base peut elle-même avoir des contentions. DB01 sur HANA liste les sessions bloquantes. Lors du Go-Live d'un opérateur de réseaux chez un client énergie, nous avons découvert que les batchs de clearing automatique généraient des locks sur KNA1 qui bloquaient les saisies commerciales. Nous avons du redecouper les traitements en lots plus fins et desynchroniser leurs fenêtres d'execution.
Levier 7 : le planning batch intelligent
Éviter la tempête parfaite
La plus grande erreur que j'observe est de planifier tous les batchs critiques a la même heure, typiquement minuit. Les serveurs d'application explosent pendant 45 minutes, les update tasks s'empilent, les utilisateurs qui se connectent a 6h du matin trouvent un système exsangue.
Ma méthode : étaler la charge sur toute la fenêtre nocturne — par exemple les jobs courts en début de nuit, les jobs moyens en milieu de nuit, les jobs lourds en fin de nuit. Ces fenêtres sont à adapter selon les contraintes métier et les SLA de clôture propres à chaque organisation. SM37 et SM36 permettent d'ordonnancer, mais sur des paysages complexes je recommandé un outil externe type Redwood ou SAP Cloud ALM pour la vue consolidee multi-systèmes.
La parallelisation maîtrisée
Les RFC asynchrones et les groupes de serveurs permettent de paralleliser les traitements massifs. Mais attention : multiplier les parallelismes sur un serveur déjà charge aggrave la situation. La règle de prudence opérationnelle : maintenir une marge suffisante sur les BTC workers (seuil indicatif terrain : ne pas dépasser 60% d'occupation en moyenne) pour absorber les jobs urgents et les reprises — à calibrer selon le nombre de WP batch et le profil de charge.
Levier 8 : l'archivage et la purge
Les tables qui grossissent dangereusement
DBACOCKPIT permet d'identifier les tables a forte croissance. Les candidates classiques : BALHDR (logs applicatifs), EDIDC (IDoc headers), SWW_CONT (workflows), DBTABLOG (logs DB). Sans politique d'archivage, ces tables explosent et les requetes correspondantes s'effondrent.
SARA (transaction d'archivage SAP) et les Archive Development Kits doivent être configurés AVANT le Go-Live, pas après. J'ai vu un projet chez un acteur de la construction où BALHDR avait atteint 400 GB en six mois, rendant certaines analyses impossibles. La purge retroactive a pris trois weekends.
Levier 9 : monitoring proactif avec Cloud ALM
Le shift vers le monitoring moderne
SAP Solution Manager (fin du mainstream maintenance prévue le 31 décembre 2027) cède la place à Cloud ALM, désormais l'outil recommandé par SAP pour le monitoring et l'opérations management. Il agrege les metriques de tous les systèmes (S/4HANA, BTP, SuccessFactors, Ariba) dans un tableau de bord unique.
Avant Go-Live, Cloud ALM doit être configure avec :
- Health monitoring sur tous les systèmes du paysage
- Alerting sur les WP occupes, le CPU HANA, le buffer swap
- Integration events vers l'outil de ticketing (ServiceNow, Jira)
- Dashboards dedies pour le run post Go-Live
Les règles d'alerte critiques
Les seuils que je configure à titre de point de départ terrain (seuils indicatifs issus de l'expérience terrain — SAP Cloud ALM permet de configurer ces alertes ; les valeurs par défaut SAP Cloud ALM sont à vérifier dans la documentation en ligne, elles peuvent évoluer entre versions) :
- CPU HANA > 80% pendant 10 minutes : alerte P2
- Work processes DIA occupés > 90% : alerte P1
- Buffer swap > 100/minute : alerte P3
- Lock wait time > 30 secondes : alerte P2
- Memory growth anormale sur une session : alerte P2
Levier 10 : le plan de War Room Go-Live
Les 72 premières heures
Aucune Basis ne devrait laisser un Go-Live sans supervision pendant les 72 premières heures. La War Room reunit physiquement (ou en visio permanente) :
- Un architecte Basis senior
- Un DBA HANA
- Un développeur ABAP pour le hotfix eventuel
- Un referent Integration Suite si des interfaces critiques sont en jeu
- Un chef de projet cote métier pour prioriser
Chaque heure, un point de dix minutes fait le tour des metriques clés : temps de reponse moyen (SM66), charge CPU HANA, files d'attente BTC, erreurs ST22, IDoc en erreur (WE02). Cette cadence permet d'intercepter les derives avant qu'elles ne deviennent des incidents bloquants.
Le hotfix maîtrise
Le reflexe d'urgence est de patcher en production. C'est souvent une mauvaise idée. Mon principe : tout hotfix doit passer par un transport urgent documente, avec validation ATC minimale, et avec un rollback préparé. J'ai vu un Go-Live gravement aggrave par un hotfix pose dans la panique qui a casse un flux logistique.
Modes de defaillance classiques au jour 1
Après une vingtaine de Go-Live accompagnes, je retrouve les mêmes causes racines dans 80% des incidents :
1. Work processes DIA satures par des sessions fantomes non nettoyées
2. Buffer de programmes ABAP sous-dimensionne après activation de nombreux Z customs
3. Requetes custom non optimisees découvertes sous charge reelle
4. Jobs batch concentres a minuit qui saturent le système
5. Verrous d'enqueue orphelins sur des tables maîtres
6. Out-of-memory HANA sur les cloturations financieres
7. Interface CPI/PI saturee a l'heure de pointe
8. Logs applicatifs non archives qui font exploser les tables de logs
9. PHYS_MEMSIZE mal renseigne après un changement de VM
10. Parametres heap non alignes entre serveurs d'application
Conclusion : la Basis, discipline silencieuse du succès
Dans les retrospectives de projet SAP, on parle rarement de la Basis. C'est pourtant elle qui determine si la solution fonctionnelle, aussi brillante soit-elle, tient la route en production. Les dix leviers que je viens de detailler ne sont pas exhaustifs, mais ils couvrent l'essentiel des causes d'incident que j'ai pu observer en dix ans d'accompagnement de Go-Live complexes.
Mon conseil final : investissez dans votre expertise SAP Basis, avant le projet plutot qu'après l'incident. Un architecte Basis senior expérimenté coûte moins cher que trois semaines d'indisponibilite d'un ERP qui irrigue 15 000 utilisateurs. La Basis n'est pas une commodity : c'est un actif stratégique qui merite le même soin que l'architecture fonctionnelle.