Architecture & Transformation
Architecte SAP S/4HANA indépendant
Design du paysage cible S/4HANA, choix d’infrastructure (RISE with SAP, Grow with SAP, On-Premise, IaaS souverain), intégration BTP, Clean Core et roadmap de transformation. L’architecture est une décision structurante : elle mérite une lecture indépendante des enjeux d’éditeur et d’intégrateur.
Ce que fait un architecte SAP S/4HANA
L’architecte SAP porte la cohérence technique du paysage sur toute la durée de vie du système. Il arbitre les choix structurants — modèle de déploiement, découpage fonctionnel, stratégie d’intégration, gouvernance des extensions — et documente les décisions pour que les équipes projet et MCO les tiennent dans la durée.
Un consultant S/4HANA indépendant intervient sans engagement vis-à-vis d’un intégrateur ou d’une offre cloud précise. Ses recommandations reposent sur le contexte du client, sa dette technique existante, ses contraintes de souveraineté et son profil de charge réel — pas sur un catalogue à défendre.
Périmètre de l’architecte SAP
- Design du paysage cible S/4HANA — instances, découpage fonctionnel, arbitrage entre monolithe et satellites
- Choix du modèle de déploiement : RISE with SAP, Grow with SAP, On-Premise (Anyware), IaaS souverain (Azure, AWS, OVHcloud)
- Stratégie d'intégration : SAP Integration Suite (CPI), API Management, PI/PO, protocoles (OData, IDoc, RFC, SOAP, REST)
- Gouvernance Clean Core : extensions in-app vs side-by-side sur BTP, cycle de vie des key users, in-app extensibility
- Roadmap de transformation : Brownfield, Greenfield ou Selective Data Transition — arbitrage sur la base des historiques et du legacy
- Cadrage sizing HANA : coordination avec le SAP Quick Sizer, la SAP HANA Sizing Tool et la SAP Note 1999997
- Cadrage cybersécurité architecture : IAS/IPS, SSO, Cloud Connector, réseau, ségrégation des environnements
Design du paysage cible S/4HANA
Le paysage S/4HANA ne se réduit plus à un couple ERP + PI. Il fédère une constellation de solutions SAP et non-SAP — S/4HANA Core, SAP BTP, SuccessFactors, Ariba, Concur, SAP Analytics Cloud, Signavio — auxquelles s’ajoutent les systèmes métiers du client (WMS, MES, CRM tiers, outils groupe).
Le rôle de l’architecte consiste à cadrer ce que S/4HANA doit porter en standard, ce qui est délégué à BTP ou à un système satellite, et comment ces briques communiquent — sans créer d’adhérences qui bloqueront les upgrades futurs.
Composantes typiques d’un paysage S/4HANA
- S/4HANA Core (Cloud Public, Cloud Private ou On-Premise) — Finance, Logistics, HR selon périmètre
- SAP BTP — extensions Clean Core, intégrations custom, Fiori side-by-side, IA/analytics
- SAP Integration Suite (CPI) — orchestration des flux inter-applicatifs SAP et non-SAP
- SAP Datasphere / SAP Analytics Cloud — reporting groupe et modélisation analytique
- SAP Signavio — process mining et documentation de processus
- SAP Business Data Cloud (BDC) — pour les organisations qui unifient données SAP et non-SAP dans une architecture data lakehouse
- Systèmes satellites : SuccessFactors (RH), Ariba (achats), Concur (frais), Fieldglass (contingent workforce)
Choisir entre RISE, Grow, On-Premise et IaaS souverain
Le choix du modèle de déploiement engage la DSI sur 7 à 10 ans. Chaque option a un profil de coût, de gouvernance et de souveraineté distinct. L’arbitrage doit tenir compte du niveau de personnalisation attendu, de la stratégie cloud groupe, des contraintes réglementaires et de la trajectoire Clean Core.
RISE with SAP
S/4HANA Cloud Private Edition avec run géré par SAP
Quand
Grands comptes cherchant à externaliser l'infrastructure et le run L1/L2 SAP ; besoin d'un contrat unique et d'un accès aux innovations Cloud.
Points de vigilance
Contractualiser précisément le périmètre de responsabilité SAP vs client ; anticiper l'accès aux logs et aux outils Basis souvent restreint.
Grow with SAP
S/4HANA Cloud Public Edition — offre standardisée
Quand
Entreprises acceptant le standard SAP avec extensions Clean Core sur BTP ; volonté d'accéder aux innovations trimestrielles sans effort de mise à niveau.
Points de vigilance
Champs personnalisables limités ; toute logique métier hors standard doit être portée par BTP (side-by-side).
On-Premise / Anywhere
S/4HANA déployé et exploité par le client, sur son infrastructure
Quand
Contraintes fortes de souveraineté, intégrations profondes avec des systèmes on-site (industrie, énergie), besoin de maîtrise complète du kernel et des upgrades.
Points de vigilance
MCO Basis à la charge du client ; roadmap upgrade à piloter ; coût CAPEX vs OPEX à instruire finement.
IaaS souverain
S/4HANA sur Azure, AWS, GCP ou OVHcloud / Bleu / S3ns
Quand
Compromis entre flexibilité cloud et contrôle. La souveraineté (SecNumCloud, RGPD) pilote souvent le choix de l'hyperscaler ou de l'offre "cloud de confiance".
Points de vigilance
Coordonner l'exploitation entre l'hyperscaler, l'intégrateur SAP et l'équipe Basis interne ; définir des SLA end-to-end réalistes.
Aucun de ces modèles n’est meilleur en absolu. L’arbitrage se fait au regard du contexte : dette technique héritée, capacité de l’équipe MCO interne, contraintes réglementaires, stratégie cloud groupe et niveau d’innovation attendu. Un architecte indépendant a précisément vocation à instruire ce choix sans biais commercial.
Stratégie d’intégration SAP et non-SAP
Une architecture S/4HANA moderne repose sur une couche d’intégration explicite. SAP Integration Suite (Cloud Integration ex-CPI, API Management, Event Mesh) est la brique de référence pour les flux inter-applicatifs sur BTP. Les paysages historiques conservent souvent PI/PO On-Premise en coexistence pendant une phase de bascule.
L’architecte définit les patterns d’intégration (synchrone/asynchrone, event-driven, batch), les protocoles autorisés (OData V4 en préférence, IDoc pour le legacy, RFC sécurisé pour l’interne, REST/SOAP pour l’externe) et la gouvernance des Cloud Connectors qui relient BTP au système On-Premise.
Décisions d’architecture d’intégration
- SAP Integration Suite comme couche cible sur BTP — cadrer les iflows critiques, le monitoring et la gouvernance des packages
- Coexistence PI/PO ↔ CPI : plan de bascule par domaine fonctionnel, pas de big-bang sur les interfaces critiques
- OData V4 pour les extensions et applications Fiori side-by-side — préférer les Business Events natifs à un polling ad hoc
- Cloud Connector : nombre d'instances, haute disponibilité, mapping des ressources exposées, ségrégation par environnement
- API Management : politique de rate-limit, authentification (OAuth 2.0, SAML), monetization interne si multi-BU
- Event Mesh / Advanced Event Mesh : arbitrer entre un bus événementiel SAP et une infrastructure existante (Kafka, Solace)
- Legacy IDoc : maintenir une gouvernance stricte des partners profiles, monitoring WE02/WE05, alerting sur les statuts en erreur
Clean Core et extensibilité BTP
Le principe Clean Core est structurant pour toute architecture S/4HANA : les modifications du noyau ABAP (custom code, user-exits historiques, améliorations invasives) doivent céder la place à des extensions explicites, gouvernées et découplées du cycle d’upgrade.
L’architecte détermine ce qui reste dans le core (via l’in-app extensibility et les key user extensions) et ce qui bascule side-by-side sur BTP (Cloud Application Programming Model, SAP Build, extensions Java/Node.js/ABAP Cloud). Ce partage conditionne la maintenabilité et la vitesse d’innovation à 5 ans.
Grille de décision Clean Core
- Personnalisation des données maîtres — in-app extensibility (transaction /IWFND/…, Custom Fields & Logic)
- Logique métier légère et isolée — key user extensions (BAdIs, Custom Business Objects, Custom CDS Views)
- Logique métier complexe et transverse — side-by-side sur BTP (CAP, RAP, Fiori side-by-side)
- Applications Fiori spécifiques — SAP Build Apps ou UI5 side-by-side, plutôt que patcher le launchpad standard
- Extensions data — SAP Datasphere / SAC pour les modèles analytiques transverses, plutôt que l'embedded Analytics
- Interfaces custom — SAP Integration Suite, pas d'iDoc custom modifiant les tables SAP standard
- Gouvernance des extensions : catalogue centralisé, revue par la Cellule d'Architecture, cycle de vie explicite
Roadmap S/4HANA : Brownfield, Greenfield ou hybride
La trajectoire de transformation dépend de l’historique ECC, du niveau de custom code, du poids fonctionnel et de la volonté de rebâtir vs préserver. L’architecte instruit le choix Brownfield / Greenfield / Selective Data Transition et documente les conséquences sur le planning, le budget et le legacy à conserver.
Le sizing HANA fait partie intégrante du cadrage d’architecture. Les outils de référence (SAP Quick Sizer, SAP HANA Sizing Tool, SAP Note 1999997) doivent être utilisés en combinaison — un sizing sous-évalué génère des incidents de production coûteux, un sur-dimensionnement alourdit inutilement la facture cloud.
Brownfield
Migration technique (SUM + DMO)
Quand
ECC récent, custom code maîtrisé, volonté de préserver l'historique et de raccourcir la fenêtre projet. La bascule est technique avant d'être fonctionnelle.
Risques
Le custom hérité reste — la dette n'est pas réduite. Un ATC (ABAP Test Cockpit) sur le custom code est indispensable en amont.
Greenfield
Réimplémentation complète
Quand
ECC ancien, dette fonctionnelle importante, refonte des processus souhaitée, volonté de repartir sur le standard SAP avec extensions Clean Core.
Risques
Coût et durée projet élevés ; conduite du changement lourde ; risque de sous-estimation des données à reprendre.
Selective Data Transition
Reprise sélective (via SNP CrystalBridge, Natuvion DCS, SAP LT)
Quand
Volonté de garder les données maîtres et l'historique récent, mais de repartir sur le standard S/4HANA. Compromis entre Brownfield et Greenfield.
Risques
Outillage tiers requis (coût licence + expertise) ; complexité de la gouvernance des données à conserver vs archiver.
Sécurité et gouvernance d’architecture
Une architecture S/4HANA sûre est instruite dès la phase de design, pas en fin de projet. L’architecte arbitre sur l’Identity Provider (SAP IAS, Azure AD, Okta), la stratégie SSO, la ségrégation réseau, les Cloud Connectors, la gouvernance des rôles SAP (PFCG, IAG, GRC) et les principes de moindre privilège appliqués aux comptes techniques.
Points d’architecture sécurité
- Identity & Access : SAP IAS (Identity Authentication Service) comme IdP central, fédération avec l'AD groupe, MFA obligatoire
- SAP IAG (Identity Access Governance) pour les paysages hybrides — cadrer la revue périodique des accès
- Ségrégation réseau : subnets dédiés par environnement, filtrage entre BTP et S/4HANA via Cloud Connector
- Chiffrement : TLS de bout en bout sur les interfaces, chiffrement HANA at-rest (Data Volume Encryption), gestion des clés
- Comptes techniques : rotation des credentials, gestion via un coffre-fort, désactivation des DDIC/SAP* par défaut en production
- Governance des rôles : PFCG structuré, SoD analysée via SAP GRC ou outil équivalent, revue périodique documentée
- Traçabilité : Read Access Logging sur les données sensibles, journalisation ST22/SM19/SM20 exportée vers un SIEM
Quand faire appel à un architecte SAP indépendant
L’architecture SAP conditionne le TCO à 7-10 ans. Un regard indépendant sur les choix structurants évite les décisions guidées par les préférences commerciales d’un éditeur ou d’un intégrateur.
Cadrage d'une trajectoire S/4HANA
Avant de sélectionner un intégrateur, l'entreprise a besoin d'un cadrage d'architecture indépendant : périmètre cible, options de déploiement instruites, roadmap Brownfield/Greenfield, hypothèses de sizing. Ce cadrage sert de référentiel pour comparer les propositions.
Second avis sur une architecture proposée
Un intégrateur ou un éditeur a présenté une cible architecturale. Un consultant SAP indépendant challenge les hypothèses (sizing, choix RISE vs On-Premise, dette Clean Core), documente les risques et propose des alternatives à instruire.
Design d'une extension BTP
L'entreprise veut développer une extension métier sur SAP BTP. L'architecte cadre la stack (CAP, RAP, Build), le modèle d'authentification, les patterns d'intégration avec S/4HANA et la gouvernance du cycle de vie.
Refonte du paysage d'intégration
Bascule de PI/PO vers SAP Integration Suite, cadrage d'une couche API Management, mise en place d'un modèle événementiel. L'architecte pilote la trajectoire technique et la coexistence pendant la phase de migration.
Architecture cybersécurité SAP
Design ou revue de l'IAM SAP (IAS, IAG), de la stratégie SSO, du durcissement Gateway, de la gouvernance PFCG et des flux de logs vers un SIEM. Sujet transverse Architecture + Sécurité.
Choix d'infrastructure cloud
Instruction d'un choix RISE / Grow / On-Premise / IaaS souverain (Azure, AWS, OVHcloud, Bleu, S3ns) au regard des contraintes de souveraineté, de la stratégie cloud groupe et du TCO à 7 ans.
Ressources associées
Expertise · Basis
Consultant SAP Basis & MCO
Administration technique, Go-Live, performance et migration S/4HANA côté exploitation.
Expertise · Migration
Migration SAP S/4HANA
Cadrage projet, arbitrage Brownfield vs Greenfield, sizing HANA et coordination du cutover.
Article · Migration
Les 7 erreurs qui plombent une migration S/4HANA
Retour d’expérience sur les risques récurrents en transformation S/4HANA.
Un cadrage d’architecture à instruire ?
Discutons de votre trajectoire S/4HANA
Que ce soit un cadrage complet, un second avis sur une architecture proposée ou un design d’extension BTP, décrivez votre situation. Réponse sous 24 heures ouvrées.
Prendre contact