SAP Build Apps

Un projet SAP Build Apps passe par quatre étapes :

1. Créer. Les projets sont créés dans le lobby SAP Build, soit comme application web et mobile, soit comme back-end d'application.
2. Concevoir. Le concepteur place des composants sur des pages dans un éditeur visuel et les met en forme librement. Le comportement est défini dans le Logic Canvas sous forme de flux logiques : un événement, comme l'appui sur un bouton, suivi de flow functions.
3. Connecter. Les données proviennent de destinations SAP BTP de type OData ou REST, qu'un administrateur doit activer pour SAP Build Apps dans le cockpit SAP BTP, ou d'un back-end construit avec des visual cloud functions.
4. Livrer. Les applications web sont construites et déployées sur SAP BTP et peuvent être exposées dans SAP Build Work Zone ; les applications mobiles sont construites en binaires iOS pour une publication sur l'App Store ou des tests locaux, et en packages Android au format APK ou AAB.

Le résultat est une application autonome qui lit et écrit les données SAP au travers d'API. SAP Build Apps est donc un client de SAP S/4HANA, jamais une modification de celui-ci.

En avril 2025, SAP a lancé une offre unifiée SAP Build qui réunit le développement d'applications, l'automatisation des processus et les business sites pour les utilisateurs low-code et code-first. Dans ce contexte, SAP a déprécié SAP Build Apps en tant que produit autonome, avec effet au 23 mars 2026. La documentation SAP indique que :

• les nouveaux projets doivent démarrer dans SAP Build ;
• les clients existants conservent l'accès à SAP Build Apps jusqu'à la fin de leur contrat en cours ;
• un outil de migration transforme l'archive .mtar des projets de front-end web en code React ou SAPUI5 pour SAP Business Application Studio, en ne couvrant que l'interface ;
• les données des projets back-end sont exportées en CSV et importées manuellement dans un projet CAP.

L'outil ne s'applique qu'aux front-ends d'applications web ; la page « path forward » de SAP ne décrit aucune migration pour les builds mobiles natifs. Tout nouvel investissement dans SAP Build Apps devrait commencer par une vérification de la date de fin du contrat et de la roadmap SAP Build actuelle.

• Liberté visuelle : l'interface n'est pas liée aux floorplans SAP Fiori, ce qui convient aux applications à l'image de la marque, centrées sur une tâche ou proches des applications grand public.
• Web et mobile natif à partir d'un seul projet : le même projet visuel peut cibler un navigateur et des appareils mobiles natifs.
• Prototypes rapides : un business technologist peut produire en quelques jours un prototype cliquable et connecté aux données, ce qui raccourcit les discussions sur les exigences.
• Connectivité SAP via la plateforme : les destinations réutilisent la connectivité et l'authentification déjà configurées sur SAP BTP.
• Compatibilité clean core : les applications s'exécutent en side-by-side et communiquent avec SAP S/4HANA au travers d'API, si bien qu'elles n'ajoutent aucun code au cœur de l'ERP.

Pour des applications petites et bien délimitées, avec un responsable clairement identifié, SAP Build Apps fournit un front-end opérationnel avec peu de code.

• Ce n'est pas SAP Fiori elements. La mise en page, la navigation et l'accessibilité relèvent du concepteur ; aucun floorplan piloté par les annotations ne garantit automatiquement la cohérence des applications.
• Les règles métier relèvent du back-end. Contrôles, calculs de prix ou comptabilisations doivent toujours provenir des API SAP S/4HANA. Les reconstruire en logique visuelle crée une seconde version de la règle, non synchronisée.
• La logique visuelle est plus difficile à relire à grande échelle. Les flux volumineux sont difficiles à comparer, tester et transmettre, une plainte fréquente dans les communautés de praticiens dès qu'une application dépasse son premier responsable.
• Limites du cycle de vie. La documentation SAP précise que le versioning n'est pas encore pris en charge pour les projets back-end, ce qui affecte le transport et le retour arrière.
• Cycle de vie du produit. La dépréciation du produit autonome fait de chaque application SAP Build Apps existante un élément à migrer, avec une échéance fixée par le contrat.

Ces limites tiennent au modèle low-code lui-même : SAP Build Apps accélère le front-end, tandis que la responsabilité et la logique métier restent des décisions de conception extérieures à l'outil.

Appliquez ces critères de décision à une application telle qu'un enregistrement des livraisons pour les chauffeurs de Bright Freight chez Alder Manufacturing :

Une erreur courante consiste à choisir l'outil selon les personnes disponibles plutôt que selon celles qui maintiendront l'application dans trois ans. SAP Build Apps convient aux applications ciblées, dotées d'un responsable et propres à un groupe d'utilisateurs ; les applications transactionnelles cohérentes relèvent davantage de SAP Fiori elements.