Le débat que tout le monde a mal posé
Depuis que SAP a lancé RISE with SAP en 2021, la question "BTP ou on-premise ?" revient dans chaque comité de direction IT. Le problème, c'est que la question est mal formulée. SAP BTP n'est pas une alternative à S/4HANA on-premise — c'est une plateforme complémentaire. On peut très bien maintenir un S/4HANA on-premise robuste et utiliser BTP pour certaines extensions, certaines intégrations ou certaines interfaces.
Ce qui a changé, en revanche, c'est la stratégie commerciale de SAP. RISE with SAP est une offre packagée qui regroupe S/4HANA Cloud (sous l'une de ses deux éditions, Private ou Public), un accès à SAP BTP et une série de services. Pour beaucoup d'entreprises françaises, cette offre représente un changement de paradigme : passer de licences perpétuelles et d'une infrastructure maîtrisée en interne à un abonnement mensuel et une dépendance accrue envers SAP.
Avant de décider, il faut comprendre les quatre modèles de déploiement réels, leurs contraintes techniques et leurs implications sur vos développements spécifiques.
Les quatre modèles de déploiement SAP
1. S/4HANA On-Premise
Le système tourne sur votre infrastructure (ou celle d'un hébergeur IaaS). Vous gérez vous-même les upgrades, les bases, la disponibilité. Vous avez un accès complet au système ABAP : développements custom, RAP, CDS Views, AMDP, tout est possible. C'est le modèle qui offre le plus de liberté technique, mais aussi le plus de charge opérationnelle. Il reste le modèle dominant chez les grandes entreprises françaises avec des équipes Basis internes.
2. S/4HANA Cloud, Private Edition (RISE)
Édition single-tenant proposée sous RISE with SAP, hébergée chez SAP ou un hyperscaler (AWS, Azure, GCP). Techniquement très proche du on-premise : les développements ABAP custom restent possibles, l'accès SAP GUI est conservé, les approches Brownfield, Greenfield ou Selective Data Transition sont supportées. SAP gère l'infrastructure et accompagne les upgrades. C'est souvent le premier pas vers le cloud pour les organisations qui veulent réduire la charge Basis sans perdre leur liberté de développement.
3. S/4HANA Cloud, Public Edition (RISE / GROW)
Édition multi-tenant, standardisée, opérée intégralement par SAP avec deux releases majeures par an. Les développements ABAP custom dans le core ne sont pas autorisés : aucun accès au backend GUI, pas de modification du code source SAP. Les extensions passent par les Key User Extensibility Tools (champs et logique custom sans code) ou par des extensions side-by-side via SAP BTP. Seules les implémentations Greenfield sont supportées, sur un périmètre limité aux processus standards et lignes de métier les plus courants. Ce modèle convient aux organisations prêtes à adapter leurs processus aux standards SAP, pas l'inverse.
4. Extensions SAP BTP (side-by-side)
Quel que soit votre modèle de core (on-premise, Private Edition ou Public Edition), SAP BTP permet de déporter une logique métier à l'extérieur du système SAP. L'extension tourne sur BTP, communique avec le core via des API OData ou des événements, et ne touche pas au code SAP. C'est la seule option sur Public Edition pour le code custom, mais c'est aussi une option valide sur on-premise ou Private Edition quand la logique implique des technologies non disponibles en ABAP (IA, Python, Node.js, intégrations SaaS tierces).
Tableau comparatif
| Critère | On-Premise | Private Edition | Public Edition |
|---|---|---|---|
| Développement ABAP custom | Complet | Complet (accès SAP GUI) | Interdit (Key User Tools uniquement) |
| Approches d'implémentation | Brownfield, Greenfield, Selective | Brownfield, Greenfield, Selective | Greenfield uniquement |
| Contrôle des upgrades | Total | Accompagné (SAP pilote) | Aucun (2 releases/an imposés) |
| Charge infrastructure | Élevée (équipe Basis) | Faible | Nulle |
| Modèle financier | Capex (licences perpétuelles) | Opex (abonnement RISE) | Opex (abonnement RISE / GROW) |
| Couverture industries | 25 industries SAP | 25 industries SAP | Périmètre LoB standards |
| Extensions via BTP | Optionnel | Optionnel | Obligatoire pour le custom code |
| Délai de déploiement | Long (infra à préparer) | Moyen | Rapide (tenant pré-configuré) |
Quand BTP est vraiment la bonne réponse
En dehors du cas Public Cloud où BTP est imposé, il existe des situations où une extension BTP est objectivement meilleure qu'un développement ABAP dans le core, même sur on-premise.
Logique métier très volatile. Si une règle de calcul change plusieurs fois par an et que l'équipe métier veut la maintenir elle-même (via SAP Build Process Automation ou des règles métier low-code), isoler cette logique sur BTP évite des transports SAP à répétition.
Intégration avec des SaaS tiers. Connecter SAP à Salesforce, Workday ou un système IoT via SAP Integration Suite (BTP) est nettement plus simple que de gérer des IDocs ou des RFC vers des systèmes hétérogènes. L'Integration Suite dispose de connecteurs prêts à l'emploi et d'un monitoring centralisé.
Besoin d'IA ou de machine learning. SAP AI Core (BTP) permet d'intégrer des modèles d'apprentissage automatique dans les processus SAP. Cela ne se fait pas en ABAP natif.
Interface utilisateur personnalisée. SAP Build Work Zone permet de créer des portails et des interfaces sur mesure, consommant des APIs S/4HANA, sans toucher au Fiori Launchpad core.
Quand l'ABAP on-premise reste supérieur
La hype autour de BTP a conduit certains projets à sur-architecting : des extensions BTP complexes pour des besoins qui auraient été résolus en 200 lignes d'ABAP RAP, avec une meilleure performance, un débogage plus simple et un coût d'exploitation bien inférieur.
Sur S/4HANA on-premise ou private cloud, RAP reste la solution cible pour tout développement d'interface utilisateur Fiori et toute logique métier transactionnelle. Un Business Object RAP tourne dans le même process que S/4HANA, accède directement aux tables sans appel réseau, et bénéficie des mécanismes de lock, draft et autorisation natifs de SAP. Une extension BTP équivalente implique un appel OData réseau, une gestion des tokens OAuth, et une infrastructure BTP supplémentaire à superviser.
Le critère de décision est simple : si la technologie ABAP peut répondre au besoin, préférez ABAP. Si le besoin impose une technologie non disponible en ABAP ou une isolation du core, optez pour BTP.
La fin de maintenance ECC : quelle urgence réelle ?
SAP a confirmé les échéances de fin de support pour SAP ECC. La maintenance mainstream s'arrête le 31 décembre 2025 pour ECC 6.0 sans Enhancement Package et avec EhP1 à EhP5. Pour les versions plus récentes (EhP6, EhP7 et EhP8), la maintenance mainstream s'arrête le 31 décembre 2027, avec une option Extended Maintenance payante (surcoût d'environ 2 points sur le contrat de support) jusqu'au 31 décembre 2030. Au-delà de 2030, seul un dispositif de Customer-Specific Maintenance reste possible.
Contrairement aux rumeurs, SAP ne ferme pas S/4HANA on-premise. SAP a publiquement confirmé un engagement d'innovation pour S/4HANA jusqu'à fin 2040 : il y aura toujours au moins une release S/4HANA en maintenance jusqu'à cette date. Depuis la release 2023, chaque version de S/4HANA on-premise bénéficie de sept ans de maintenance mainstream, avec un cycle de releases majeures tous les deux ans.
La vraie urgence n'est donc pas de basculer vers RISE — c'est de migrer d'ECC vers S/4HANA, dans le modèle de déploiement le plus adapté à votre organisation. Pour la grande majorité des entreprises françaises avec lesquelles nous travaillons, ce modèle est on-premise ou Private Edition, avec des extensions BTP ciblées sur les cas d'usage qui le justifient vraiment.
Ce que nous faisons chez Kaï Consulting
Sur le projet Kuhn Group, la stratégie retenue est S/4HANA on-premise avec des extensions Fiori développées en RAP dans le core. Aucune extension BTP n'a été nécessaire pour les besoins de l'implémentation Greenfield. Sur d'autres projets, nous avons mis en place SAP Integration Suite (BTP) pour connecter S/4HANA à des systèmes tiers e-commerce, tout en conservant la logique transactionnelle SAP en ABAP natif.
Notre approche est pragmatique : nous n'avons pas de préférence commerciale pour BTP ou pour l'on-premise. Nous choisissons la solution la plus adaptée au besoin réel, en tenant compte du coût total de possession, de la maturité de vos équipes et de votre trajectoire sur 5 ans.
Questions fréquentes
Quelle est la différence entre SAP BTP et RISE with SAP ?
RISE with SAP est une offre commerciale packagée qui regroupe S/4HANA Cloud (Private Edition ou Public Edition) et un accès à SAP BTP. SAP BTP est la plateforme technique sous-jacente. On peut utiliser BTP sans RISE (sur un S/4HANA on-premise), et RISE sans développer sur BTP.
Peut-on garder un S/4HANA on-premise et utiliser SAP BTP ?
Oui, c'est même la configuration la plus courante en Europe. S/4HANA on-premise reste le core et BTP est utilisé pour des extensions ciblées (intégration, IA, interfaces) via SAP Cloud Connector.
SAP arrête-t-il vraiment le support on-premise ?
Non. SAP a confirmé un engagement d'innovation pour S/4HANA jusqu'à fin 2040 : au moins une release S/4HANA reste en maintenance jusqu'à cette date. La fin de maintenance concerne SAP ECC : 31 décembre 2025 pour EhP1-5, 31 décembre 2027 pour EhP6/7/8 (Extended Maintenance payante jusqu'à fin 2030).
Quand choisir une extension BTP plutôt qu'un développement ABAP ?
Sur on-premise avec accès ABAP, préférez RAP pour les besoins transactionnels et Fiori. Optez pour BTP quand le besoin implique de l'IA, des technos non-ABAP, ou une intégration SaaS tierce complexe.
Quel est le coût réel de RISE with SAP vs on-premise ?
Sur 5 ans, le TCO est comparable. RISE convertit un Capex en Opex et transfère la charge infrastructure à SAP. Pour les grandes structures avec équipes Basis internes, l'on-premise reste souvent moins cher sur la durée.
Vous devez trancher entre RISE with SAP, on-premise et une stratégie BTP hybride ?
Discuter de votre stratégie de déploiement