Exploitation & MCO
Consultant SAP Basis indépendant
Administration technique, performance en production, préparation des Go-Live et maintien en conditions opérationnelles (MCO). Une couverture Basis de bout en bout, de l’architecture du paysage à la surveillance quotidienne.
Ce que couvre SAP Basis
La couche SAP Basis — historiquement désignée SAP BC (Basis Component) dans les notes SAP et les documentations produit — constitue le socle technique sur lequel repose l’ensemble de l’application SAP. Elle couvre l’administration du système d’exploitation de l’instance, la gestion des work processes, du système de transport, des connexions RFC, des tâches d’update, des jobs d’arrière-plan et du système de spool.
Dans S/4HANA, le périmètre Basis s’étend à l’administration de la base de données HANA, qui est désormais obligatoire et intégrée à l’instance (plus de séparation optionnelle entre la couche ABAP et la base). La maîtrise du dimensionnement mémoire HANA, des paramètres de gestion des work processes et de l’ordonnancement batch fait partie intégrante du rôle Basis.
Composants techniques couverts
- Work processes : DIA, BTC, UPD, UP2, ENQ, SPO — dimensionnement et équilibre selon le profil de charge
- Système de transport (TMS) : routes, layers, import queue, monitoring des transports critiques
- RFC et ICM : gestion des destinations logiques, durcissement des connexions, monitoring des appels entrants/sortants
- Message server et enqueue server : configuration et supervision dans un paysage multi-instances
- Kernel SAP : suivi des versions, procédures de mise à jour sur systèmes en production
- Mémoire HANA : global_allocation_limit, PHYS_MEMSIZE, statement_memory_limit, coexistence ABAP/HANA
- Buffers ABAP : program buffer, table buffer, CUA buffer — surveillance via ST02
- Ordonnancement batch : SM36/SM37, parallélisation, équilibre des fenêtres nocturnes
Architecture technique et paysage système
Un paysage SAP standard comprend trois environnements : développement (DEV), qualité/recette (QAS) et production (PRD). Le consultant Basis définit les règles de transport entre ces environnements, dimensionne chaque instance indépendamment et supervise la cohérence du paysage.
Dans S/4HANA, la séparation historique entre le serveur d’application ABAP et le serveur de base de données Oracle ou DB2 cède la place à une architecture où HANA est la seule base de données supportée. Cela simplifie la couche de stockage mais exige une maîtrise spécifique de l’administration HANA : gestion des Column et Row Stores, paramétrage mémoire, suivi des requêtes coûteuses via M_EXPENSIVE_STATEMENTS.
Spécificités S/4HANA pour la Basis
- Base HANA obligatoire — plus de choix de SGBD ; le DBA SAP doit maîtriser HANA Studio, SAP HANA Cockpit et DBACOCKPIT
- Stack ABAP simplifiée — la couche Java (AS Java) disparaît dans la majorité des déploiements S/4HANA On-Premise
- Fiori Launchpad — introduction d'une couche Gateway (transaction /IWFND/MAINT_SERVICE) à administrer séparément
- Embedded Analytics — les CDS Views et les Analytical Apps génèrent des requêtes HANA spécifiques à monitorer
- Paysage DEV/QAS/PRD — les règles de transport s'appliquent à la fois aux objets ABAP et aux configurations HANA-side
- Co-déploiement — si HANA et l'instance ABAP partagent le même serveur, PHYS_MEMSIZE doit être explicitement borné
Diagnostic et performance en production
Un problème de performance SAP en production suit une logique de diagnostic systématique. L’expérience terrain Basis permet de naviguer rapidement entre les couches : work processes, mémoire HANA, buffers ABAP, verrous, requêtes coûteuses.
SM50 / SM66
Work processes et sessions
SM50 supervise les work processes du serveur courant ; SM66 offre une vue globale multi-instances. Premier point d’entrée lors d’un ralentissement : identifier les WP en RUNNING (charge normale), PRIV (monopolisation mémoire) ou bloqués.
ST02
Buffers ABAP
ST02 affiche l’état des buffers ABAP : Program buffer, Table buffer, CUA buffer. La colonne Swaps indique si un buffer est sous-dimensionné. Des swaps croissants signalent une recharge permanente depuis la base, dégradant les temps de réponse.
ST04 / M_EXPENSIVE_STATEMENTS
Requêtes HANA coûteuses
ST04 donne accès à M_EXPENSIVE_STATEMENTS, la vue système HANA qui liste les requêtes consommatrices. Le seuil de capture est à calibrer selon le volume de requêtes et le profil de charge. Les requêtes Z sur des tables volumineuses sans index adapté sont les premières causes de saturation CPU HANA.
SM12 / DB01
Analyse des verrous
SM12 gère les lock entries SAP au niveau de l’enqueue server. Un verrou orphelin laissé par un processus interrompu bloque les sessions suivantes en cascade. DB01 complète l’analyse en listant les sessions bloquantes côté HANA.
DBACOCKPIT
Database Administration Cockpit
DBACOCKPIT centralise l’administration HANA depuis l’instance ABAP : espace disque, croissance des tables, sauvegarde, alertes base de données. Identifie les tables à forte croissance (BALHDR, EDIDC, SWW_CONT, DBTABLOG) avant qu’elles n’affectent les performances.
ST22
Dumps ABAP
ST22 répertorie les dumps ABAP. Un TSV_TNEW_PAGE_ALLOC_FAILED indique un épuisement de mémoire session — signal que les paramètres ztta/roll_extension ou abap/heap_area_total méritent une revue de calibrage.
Séquence de diagnostic incident production
- 1SM50 — charge WP→
- 2SM66 — vue globale→
- 3ST02 — buffers→
- 4ST04 — requêtes HANA→
- 5SM12 — verrous SAP→
- 6DB01 — verrous HANA→
- 7DBACOCKPIT — base→
- 8ST22 — dumps
Cette séquence couvre les causes racines les plus fréquentes d’un incident de performance. En pratique, l’expérience terrain permet de court-circuiter certaines étapes selon les symptômes initiaux — la liste est un guide, pas un protocole rigide.
Préparation et tenue du Go-Live SAP
Dans les 72 heures précédant et suivant un Go-Live, le consultant Basis pilote les contrôles techniques de bout en bout. Cette fenêtre critique concentre les risques les plus visibles pour les utilisateurs finaux.
La préparation Go-Live Basis couvre le dimensionnement final des work processes selon le profil de charge attendu, la validation des paramètres mémoire HANA, le contrôle des fenêtres batch, la configuration du monitoring Cloud ALM, et la mise en place du protocole War Room avec revue régulière des métriques clés.
Ce que le consultant Basis gère au Go-Live
- Validation finale du dimensionnement : WP dialog, batch, update — à calibrer selon le profil de charge réel, pas uniquement les estimations de sizing
- Contrôle des paramètres mémoire HANA (global_allocation_limit, PHYS_MEMSIZE) et ABAP (buffers, mémoire session)
- Vérification de l'ordonnancement batch : répartition des fenêtres nocturnes pour éviter la saturation simultanée
- Configuration SARA / ILM avant Go-Live pour les archivages et purges — une politique d'archivage absente dès le départ génère des rattrapages coûteux
- Mise en place des alertes SAP Cloud ALM sur les métriques critiques : CPU HANA, WP occupés, buffer swaps, lock wait
- Supervision War Room : couverture continue des 72 premières heures, avec revue régulière des métriques (SM66, ST22, WE02, SM37)
- Protocole hotfix : tout transport d'urgence passe par le TMS avec documentation et rollback préparé
MCO SAP — Maintien en Conditions Opérationnelles
Le MCO Basis couvre l’ensemble des opérations récurrentes qui maintiennent le paysage SAP en état de marche : suivi des incidents techniques, gestion des patches kernel, montées de version (upgrade kernel, Support Packages, Enhancement Packages), surveillance des transports, et optimisation continue des performances.
La fin du mainstream maintenance de SAP Solution Manager prévue le 31 décembre 2027 rend la migration vers SAP Cloud ALM incontournable pour les paysages actifs. Cloud ALM centralise le health monitoring, les alertes et la gestion des événements d’intégration pour l’ensemble du paysage — S/4HANA, BTP, SuccessFactors, Ariba.
Activités MCO Basis récurrentes
- Monitoring quotidien : charge WP, mémoire HANA, jobs batch en erreur, verrous persistants, dumps ST22
- Gestion des patches kernel SAP : suivi des niveaux de kernel, fenêtres de maintenance, procédures de rollback
- Application des Support Packages et Enhancement Packages sur les environnements non-production puis production
- Surveillance du système de transport : files d'import, transports en erreur, cohérence des layers entre DEV/QAS/PRD
- Suivi des performances : analyse périodique via ST02, ST04, DBACOCKPIT — identification des dérives avant qu'elles deviennent des incidents
- Politique d'archivage et de purge : suivi des tables à forte croissance (BALHDR, EDIDC, SWW_CONT) via SARA
- SAP Cloud ALM : configuration du health monitoring, revue des tableaux de bord, ajustement des seuils d'alerte selon l'évolution du profil de charge
Rôle Basis dans une migration S/4HANA
La migration ECC vers S/4HANA mobilise le consultant Basis à plusieurs étapes clés. Son rôle ne se limite pas à la mise à jour technique : il conditionne la faisabilité et la sécurité de la bascule.
Le sizing est la première étape critique. HANA remplace le SGBD relationnel existant : les besoins mémoire sont différents, et les outils SAP (Quick Sizer, SAP HANA Sizing Tool, SAP Note 1999997) doivent être utilisés en combinaison. Le Basis valide ensuite le chemin de mise à niveau, prépare les environnements de migration et gère les contraintes techniques du cutover.
Avant projet
- Audit du paysage ECC existant : versions, kernel, niveaux de patch
- Sizing HANA : validation via SAP HANA Sizing Tool et SAP Note 1999997
- Définition du chemin de mise à niveau (SUM, DMO, migration de données)
Préparation technique
- Mise en place des environnements de migration (Sandbox, DEV, QAS)
- Configuration des routes de transport S/4HANA
- Validation des prérequis système : OS, kernel cible, stack Java si applicable
Cutover
- Coordination technique du Go-Live : gel des transports, bascule système, validation
- Supervision War Room : monitoring continu post-bascule pendant 72 heures
- Gestion des incidents techniques de premier et second niveau
Stabilisation
- Analyse des performances HANA post-migration : requêtes coûteuses, nouveaux patterns de charge
- Ajustement des paramètres Basis selon la charge réelle observée
- Mise en place du MCO Cloud ALM pour le run permanent
Quand un consultant Basis indépendant apporte de la valeur
Un consultant Basis indépendant intervient ponctuellement ou sur la durée selon les besoins. Voici les contextes où cette intervention est particulièrement justifiée.
Absence d'équipe Basis interne
Une DSI sans compétence Basis dédiée expose ses systèmes SAP à des risques techniques non couverts. L'externalisation partielle — pour les interventions critiques, les montées de version, les Go-Live — permet de combler ce manque sans recruter en permanence.
Préparation d'un Go-Live
Le Go-Live concentre les risques techniques dans une fenêtre très courte. Un consultant Basis expérimenté sur les Go-Live SAP renforce l'équipe projet pendant cette période critique — dimensionnement final, War Room, supervision post-bascule.
Crise de performance en production
Quand un système SAP ralentit brutalement, la résolution d'incident exige une lecture combinée des couches : work processes, mémoire HANA, buffers ABAP, verrous, requêtes coûteuses. Cette analyse systémique est le cœur du métier Basis.
Audit pré-migration S/4HANA
Avant une migration ECC vers S/4HANA, un audit technique Basis permet d'établir l'état réel du système existant : niveaux de kernel, dette de patches, sizing HANA à prévoir, points de vigilance pour le cutover.
MCO externalisé ou renforcé
Le MCO Basis peut être confié en totalité ou en complément d'une équipe interne. Un consultant SAP BC senior en renfort N2/N3 assure la surveillance quotidienne, les patches récurrents et la gestion des incidents techniques selon les niveaux de service définis.
Transition vers SAP Cloud ALM
Avec la fin du mainstream maintenance de SAP Solution Manager prévue le 31 décembre 2027, la migration vers Cloud ALM est un chantier Basis à part entière : configuration du health monitoring, migration des alertes existantes, formation des équipes.
Ressources associées
Article · Basis
10 leviers Basis pour un Go-Live maîtrisé
Work processes, mémoire HANA, buffers, verrous, batch, Cloud ALM — le détail technique des 10 points de contrôle Basis en production.
Article · Migration
Les 7 erreurs qui plombent une migration S/4HANA
Dont l’absence d’expert Basis dédié — analyse des risques récurrents en migration ECC vers S/4HANA.
Article · Cybersécurité
Sécuriser votre paysage SAP en production
La cybersécurité SAP est transverse au rôle Basis : Gateway, Security Notes, durcissement des interfaces et des paramètres.
Besoin d’un expert Basis ?
Discutons de votre contexte
Que ce soit pour un Go-Live, une crise de performance, un audit pré-migration ou la mise en place d’un MCO, décrivez votre situation. Une réponse sous 24 heures ouvrées.
Prendre contact