La plupart des décisions d’architecture SAP semblent solides sur un schéma. Les problèmes apparaissent six mois après le go-live, lorsque la réalité des opérations quotidiennes, des dépendances entre systèmes et de la latence cloud commence à déformer la conception initiale de manière imprévue.
La résilience dans une architecture SAP hybride ne consiste pas à ajouter de la redondance par-dessus une conception fragile. Il s’agit de faire les bons choix structurels dès le départ : comment les charges de travail sont séparées, comment les systèmes s’intègrent, comment S/4HANA est positionné par rapport aux services cloud, et comment l’observabilité est intégrée à l’architecture avant même d’en avoir besoin. Cet article couvre chacun de ces aspects de manière concrète.
Pourquoi la résilience doit être intégrée dès la conception de l’architecture SAP
Ce que signifie réellement “résilient” dans un contexte SAP
Dans un paysage SAP, la résilience ne se limite pas à la disponibilité. Un système peut être techniquement accessible tout en exécutant des batchs dégradés, en traitant des interfaces incorrectes ou en fournissant des transactions lentes qui érodent silencieusement la productivité.
Une véritable résilience signifie que le système peut absorber des perturbations — prévues ou non — sans compromettre l’intégrité des données, la continuité des processus métier ou des temps de réponse acceptables.
Cela implique d’aller au-delà de la redondance infrastructurelle. Il faut concevoir la gestion des pannes simultanément au niveau applicatif, d’intégration et des données. Un basculement de base de données n’a aucune valeur si le middleware ne gère pas correctement la reconnexion. La haute disponibilité doit être pensée de bout en bout.
Pourquoi le cloud hybride rend la résilience plus complexe
Un paysage SAP on-premise présente des modes de défaillance prévisibles : latence réseau stable, comportement du stockage connu, périmètres clairs.
Dans un modèle hybride — où S/4HANA fonctionne sur un hyperscaler tandis que des systèmes legacy restent on-premise via SAP BTP ou des intégrations directes — la surface de défaillance augmente fortement.
Chaque service cloud apporte son propre modèle de disponibilité, ses SLA et son périmètre d’impact. Une panne régionale peut affecter les extensions BTP sans impacter le cœur S/4HANA, créant des défaillances partielles plus difficiles à détecter et à corriger qu’une panne totale.
L’architecture doit anticiper explicitement ces scénarios asymétriques.
Patterns d’architecture clés pour un SAP hybride résilient
Architecture zonée : séparer les charges selon leur criticité
Une des décisions les plus efficaces consiste à définir des zones de workload basées sur le niveau de risque et de criticité.
Tous les composants SAP n’ont pas les mêmes exigences. Traiter un système transactionnel critique comme un batch mensuel ajoute du coût sans améliorer la résilience.
Une architecture zonée sépare :
- les systèmes cœur (ERP, achats, logistique)
- les workloads analytiques
- les environnements de dev/QA
- les extensions cloud
Chaque zone dispose de son infrastructure, de son isolation réseau et de ses objectifs de reprise.
Résultat : en cas d’incident, les équipes savent immédiatement quoi prioriser.
Cette approche simplifie aussi les migrations vers le cloud (ex : RISE with SAP) : seules certaines zones doivent être déplacées.
Conception de la couche d’intégration
La couche d’intégration est souvent la principale source de dette technique.
Les connexions point-à-point “temporaires” deviennent permanentes. Les interfaces conçues pour des tests passent en production. Résultat : un enchevêtrement difficile à maintenir.
Une architecture résiliente repose sur :
- une stratégie middleware claire (SAP Integration Suite, API gateway, etc.)
- une centralisation des flux
- des capacités de buffer, retry, monitoring et reroutage
Les connexions directes doivent être l’exception.
Il faut aussi gérer l’évolution des schémas (API versionnées, rétrocompatibilité) pour éviter des incidents lors des upgrades.
Haute disponibilité (HA) et Disaster Recovery (DR)
HA et DR sont souvent confondus — à tort.
- HA : limiter les interruptions (failover, restart, load balancing)
- DR : restaurer après un incident majeur (site ou région)
Dans un environnement hybride, les hyperscalers ne fournissent pas automatiquement un DR adapté à SAP.
Bonnes pratiques :
- SAP HANA System Replication (HSR) pour la base
- clusters (ex : Pacemaker)
- serveurs applicatifs distribués
Ces mécanismes doivent être testés régulièrement.
Pour le DR :
- définir RTO et RPO par zone
- éviter une approche “one-size-fits-all” coûteuse
Préparation au cloud pour S/4HANA
RISE with SAP : ce que cela change vraiment
RISE with SAP regroupe :
- S/4HANA Cloud
- SAP BTP
- infrastructure managée
Mais cela ne supprime pas les décisions d’architecture côté client.
SAP gère :
- l’infrastructure
- la base
- la HA de base
Le client garde :
- l’intégration
- les extensions
- la migration des données
- l’observabilité
Mal comprendre cette frontière mène à des angles morts critiques.
Sizing et scalabilité
S/4HANA repose sur une base in-memory → la mémoire est critique.
Un sous-dimensionnement crée des problèmes coûteux à corriger.
Le dimensionnement doit se baser sur :
- utilisateurs actifs
- volume transactionnel
- batchs
- croissance des données (3 ans)
Les serveurs applicatifs peuvent scaler horizontalement, mais uniquement si cela est prévu dès la conception.
Gestion de la phase de migration
La migration vers S/4HANA est une période à haut risque :
- systèmes en parallèle
- interfaces doubles
- dépendance à la qualité des données
Erreur fréquente : traiter cette phase comme un simple projet.
Il faut :
- établir des baselines avant migration
- instrumenter legacy et S/4HANA
- comparer les performances
Cette phase est une source précieuse d’insights.
L’observabilité comme pilier structurel
Limites du monitoring traditionnel
Le monitoring classique SAP fonctionne bien en on-premise, mais pas en hybride.
Dans un environnement distribué :
- les causes sont éloignées des symptômes
- les outils classiques ne voient qu’une partie du problème
À quoi ressemble une observabilité complète
Une observabilité efficace couvre plusieurs couches :
- Infrastructure : CPU, mémoire, réseau
- HANA : mémoire, requêtes, locks
- Application : work processes, dumps, temps de réponse
- Intégration : files, erreurs, latence
- Métier : KPIs processus
La corrélation entre ces couches est essentielle.
Instrumentation avant le go-live
Ajouter l’observabilité après un incident est trop tard.
Bonnes pratiques :
- privilégier le monitoring agentless
- définir les seuils sur des données réelles
- adapter les dashboards aux équipes
L’observabilité doit être testée avant la production.
Construire une architecture SAP durablement résiliente
Une architecture SAP résiliente repose sur 4 piliers :
- séparation intelligente des workloads
- intégration robuste
- migration maîtrisée
- observabilité intégrée
Chaque choix implique des compromis, mais un principe reste constant :
👉 la résilience se conçoit dès le départ, elle ne s’ajoute pas après coup
Avec la montée du cloud, de RISE with SAP et des extensions BTP, l’écart entre architectures résilientes et fragiles va s’accentuer.
Le moment d’agir, c’est la phase de design — pas le post-mortem.
Découvrez comment Redpeaks fournit une observabilité de bout en bout pour les environnements SAP hybrides et S/4HANA.
