Introduction : le BTP est devenu incontournable, mais mal compris
En 2026, il n'y a plus de projet S/4HANA serieux sans une stratégie BTP (Business Technology Platform). C'est le lieu ou SAP concentre ses innovations : Joule, SAP Build, RAP, CAP, Integration Suite, Datasphere. Pourtant, je continue d'observer, chez des clients pourtant matures, des décisions d'architecture BTP qui vont leur coûter cher pendant des années.
Après avoir concu des architectures d'extension BTP pour des acteurs de l'énergie, de la defense aerospatiale et de la construction, j'ai identifie les choix structurants qui distinguent les projets qui tiennent dans le temps des projets qui derivent. Cet article propose un guide pragmatique pour l'architecte SAP en 2026.
Les trois scénarios d'extension : Key User, On-Stack, Side-by-Side
Avant de parler de RAP ou CAP, il faut comprendre les trois grandes approches d'extension dans le monde S/4HANA moderne.
Key User Extensibility
Realisee depuis le navigateur par les utilisateurs métier avances, sans code. Ajout de champs, création de formulaires, customisation d'écrans Fiori, création de rapports simples. C'est le mécanisme a privilegier pour les adaptations legeres.
Usage pertinent : ajout d'un champ client sur une commande, création d'un tableau de bord simple, personnalisation d'une validation.
Limites : pas de logique complexe, pas d'integration externe, pas de versioning avance.
On-Stack Developer Extensibility (ABAP Cloud)
Développement ABAP réalisé directement dans le tenant S/4HANA, en respectant les règles ABAP Cloud : uniquement des APIs publiques, pas de modification du standard, architecture RAP pour les services métier. C'est le mécanisme pour les extensions qui doivent être très integrees au système.
Usage pertinent : nouveaux objets métier fortement couples aux données S/4 (module personnalise pour la gestion spécifique d'un processus métier), services OData custom, reports complexes.
Limites : le code reste dans le tenant S/4 (donc expose aux contraintes de versioning du cloud), utilisation des ressources HANA du système principal, complexité de la governance.
Side-by-Side Extensibility (sur BTP)
Développement réalisé sur BTP, dans un environnement separe de S/4HANA. Typiquement en CAP (Node.js ou Java) ou en ABAP Cloud sur BTP. Les extensions communiquent avec S/4HANA via API.
Usage pertinent : applications transverses, integrations tierces, portails, workflows complexes, micro-services métier, extensions qui doivent survivre a des changements de backend.
Limites : complexité opérationnelle superieure, coût BTP, nécessité de maîtriser un nouveau socle technologique.
RAP vs CAP : le vrai critère de choix
Qu'est-ce que RAP concrètement
RAP (RESTful Application Programming Model) est le modèle de développement moderne pour construire des services métier en ABAP, avec une architecture qui separe proprement :
- Le modèle de données (CDS views)
- La logique métier (behavior définition)
- L'interface (OData service)
RAP est optimise pour les extensions fortement couplees a S/4HANA, notamment quand on veut exploiter les capacités transactionnelles du système principal.
Qu'est-ce que CAP concrètement
CAP (Cloud Application Programming Model) est le framework SAP pour construire des applications cloud-native, généralement en Node.js ou Java, sur BTP. CAP offre :
- Un modèle de données declaratif (CDS)
- Une génération automatique de services OData et REST
- Une integration native avec les services BTP (authentification, persistence HANA Cloud, messaging)
- Un modèle de déploiement cloud-native (conteneurs, Cloud Foundry ou Kyma)
CAP est adapte aux extensions decouplees, aux applications transverses, aux integrations complexes.
Le tableau de décision
| Critère | RAP | CAP |
|---------|-----|-----|
| Couplage fort avec S/4HANA | Excellent | Moyen |
| Transactions ACID avec S/4 | Natif | Complexe (via API) |
| Integration avec autres systèmes | Limite | Excellent |
| Independance du backend S/4 | Faible | Forte |
| Profil développeur disponible | ABAPers formes | Devs JS/Java |
| Portabilite vers un autre ERP | Nulle | Elevee |
| Utilisation des ressources HANA S/4 | Oui (impact performance) | Non |
En pratique, j'applique cette règle simple : si l'extension a besoin d'acceder fréquemment a des données transactionnelles S/4 en temps reel avec de forts volumes, RAP. Si l'extension a vocation a être transverse, a communiquer avec plusieurs systèmes, ou a survivre a un changement de backend, CAP.
SAP Build : quand le low-code fait sens et quand il faut s'en mefier
Ou SAP Build excelle
SAP Build (Apps, Process Automation, Work Zone) permet de construire rapidement :
- Des applications mobile simples (saisie sur le terrain, approbations)
- Des workflows d'approbation multi-niveaux
- Des portails utilisateur agregant plusieurs services
- Des integrations simples entre APIs
Chez un client de la construction, nous avons déployé en 6 semaines une application mobile SAP Build permettant aux chefs de chantier de saisir leurs releves de compteurs, avec workflow d'approbation automatique. En ABAP ou CAP, ce projet aurait pris 4 à 5 mois.
Les pièges de SAP Build
Le low-code n'est pas une baguette magique. Les pièges classiques :
- Dette technique cachee : les applications low-code mal concues deviennent rapidement impossibles a maintenir quand elles grossissent
- Explosion des licences : SAP Build a un modèle de licensing par application et par utilisateur qui peut devenir très cher a grande échelle
- Gouvernance difficile : sans cadre, chaque equipe métier commence à créer ses applications, creant un chaos de mini-systèmes non-integres
- Limites techniques : des qu'on sort des cas d'usage prévus, le low-code montre ses limites rapidement
Ma règle : SAP Build pour les applications tactiques et jetables, code pour les applications structurantes et durables.
Integration Suite : le vrai hub d'integration
SAP Integration Suite est désormais le standard pour les echanges entre SAP et le reste du SI. Elle regroupe :
- Cloud Integration (ex CPI) : l'orchestrateur de flux
- API Management : la gestion du cycle de vie des APIs
- Event Mesh : les echanges evenementiels
- Open Connectors : les connecteurs vers les solutions du marche
- Integration Advisor : l'aide à la construction de mappings EDI
Recommandations d'architecte
Quelques principes que j'applique systématiquement :
1. Toute integration passe par Integration Suite, jamais de point-a-point directement depuis S/4HANA vers un système tiers. Cela evite le spaghetti d'integration qu'on retrouve dans les systèmes ECC matures.
2. Les APIs exposees par S/4HANA sont publiees dans API Management, avec une gouvernance claire (quota, authentification, monitoring).
3. Les integrations evenementielles utilisent Event Mesh, pas des integrations synchrones qui fragilisent les systèmes.
4. Le monitoring est centralise dans Cloud ALM ou un outil tiers, jamais eclate sur chaque instance d'integration.
Joule Developer : le vrai gain de productivite
Joule Developer est l'assistant IA de SAP pour les développeurs. Integre dans Business Application Studio et dans ADT (ABAP Development Tools), il permet :
- La génération de code ABAP RAP a partir d'une description
- La conversion de code ABAP classique vers ABAP Cloud
- La génération de CDS views avec jointures complexes
- La création de tests unitaires
- Le refactoring de code pour conformité Clean Core
Les gains observes sur le terrain
Dans mes projets recents :
- Génération de RAP : 30 à 40% de reduction du temps de développement sur les services CRUD standards
- Conversion ABAP Cloud : 25 à 30% sur les migrations de code legacy
- CDS views : 40 à 50% pour les views complexes avec jointures
- Tests : 60% sur la génération de tests unitaires
Attention : Joule ne remplace pas les développeurs seniors. Il accelere les développeurs mid-level et libere les seniors des tâches a faible valeur ajoutee. La qualité du code genere depend directement de la qualité du prompting et de la revue humaine.
La gouvernance des credits BTP : le piège cache
C'est probablement le point le plus sous-estime par les equipes projet. Les credits BTP sont consommes par :
- Runtime : execution des applications CAP, des flux d'integration
- Stockage : persistance HANA Cloud, stockage objet
- Services : utilisation de Document Management, Work Zone, Analytics Cloud
- IA : consommation Joule et services GenAI
Les derives classiques
J'ai vu chez un grand energeticien une explosion de 300% de la consommation BTP en 8 mois, causee par :
- Des flux d'integration mal concus (polling toutes les 30 secondes au lieu de push evenementiel)
- Des logs non purges qui saturaient le stockage HANA Cloud
- Des instances de dev/test laissees actives le week-end
- Une utilisation non maîtrisée de services GenAI en développement
Les règles de gouvernance à poser
1. Tagging systématique de tous les services BTP avec le centre de coût
2. Quotas par equipe avec alerting automatique a 70% et 90%
3. Revue mensuelle de la consommation avec les chefs de projet
4. Arret automatique des environnements non-productifs le week-end
5. Clean-up periodique des ressources orphelines
Chez un client industriel, la mise en place de ces règles a permis de reduire de 40% la consommation BTP en 4 mois, sans aucun impact fonctionnel.
Cas concret : une architecture d'extension complète
Chez un acteur de la construction, voici l'architecture cible que nous avons déployée :
- Extensions legeres (champs ajoutes, écrans Fiori adaptes) : Key User Extensibility, gérées par les key users métier
- Extensions métier couplees (nouveaux objets de gestion spécifique des chantiers) : RAP dans le tenant S/4HANA
- Application mobile de saisie terrain : SAP Build, déploiement rapide, utilisateurs occasionnels
- Plateforme d'integration avec les sous-traitants : CAP sur BTP, avec Event Mesh et API Management
- IA de prédiction des retards chantier : modèle externe (Vertex AI), integration via Cloud Integration
Chaque choix est justifie par le critère de couplage, de duree de vie, et de profil utilisateur. Cette architecture tourne aujourd'hui en production avec 3 500 utilisateurs, sans avoir eu besoin d'être refondue en 18 mois.
Conclusion : la discipline de l'architecte BTP
Le BTP offre une flexibilite considérable, mais sans discipline, il devient rapidement un chaos de services mal integres et mal gouvernes. Les règles qui fonctionnent :
1. Un catalogue d'architecture documente et partage entre toutes les equipes
2. Des critères clairs de choix entre Key User, RAP, CAP, Build
3. Une gouvernance des credits avec responsabilisation par equipe
4. Une integration passant systématiquement par Integration Suite
5. Un investissement formation pour que les développeurs maitrisent les nouveaux modèles
L'architecte SAP en 2026 ne peut plus se contenter de connaitre ABAP. Il doit comprendre les enjeux cloud, integrer les principes DevOps, gouverner les coûts d'infrastructure, et piloter une pluralite de technologies. C'est un métier exigeant -- mais c'est aussi le plus passionnant que j'aie connu en vingt ans dans l'écosystème SAP.