Side-by-side : étendre S/4HANA Public Cloud avec de petites apps Cloud Foundry, sans sacrifier le clean core

Chaque projet S/4HANA Public Cloud atteint le moment où l’extensibilité key-user touche son plafond. Un champ supplémentaire, une validation, une mise en page d’app ajustée : aucun problème, elle est faite pour cela. Mais ensuite, les ventes veulent un tableau de bord qui agrège le chiffre d’affaires sur plusieurs années et des dizaines de milliers de documents. Ou un service métier a besoin d’un petit processus que le standard ne connaît tout simplement pas. Et soudain, la question est sur la table : devons-nous quand même toucher au noyau ?

Non. La réponse s’appelle side-by-side : une petite application sur SAP BTP Cloud Foundry qui vit à côté du système et lui parle exclusivement via des API released. L’ERP reste intact, l’extension tourne à côté. Et petite s’entend au sens littéral.

Le modèle : une petite app à côté du système

Le plan de construction est toujours le même, et c’est précisément sa force. Au backend, un service CAP (Cloud Application Programming Model, Node.js ou Java) qui va chercher, agrège ou enrichit les données de S/4HANA. Devant, un frontend : Fiori/UI5 si l’app doit ressembler à SAP, ou un frontend web léger si ce n’est pas nécessaire. La connexion vers l’ERP passe par le service Destination et des accords de communication dans S/4HANA, et seules les API released du SAP Business Accelerator Hub sont consommées.

C’est tout. Pas de zoo de frameworks, pas de plateforme maison, pas de modification. Qui a déjà monté un projet Node.js s’oriente dans CAP en quelques jours. Et comme Cloud Foundry facture la mémoire par instance, une app qui tourne dans quelques centaines de MB ne coûte presque rien à exploiter.

Un exemple tiré d’un de nos projets

Chez une entreprise commerciale suisse, les ventes voulaient voir dans le CRM ce qu’un client avait réellement acheté au fil des ans : chiffre d’affaires par année, par groupe de produits, tendance. Les données brutes vivent dans l’ERP, réparties sur environ 75’000 commandes clients. Aucun rapport CRM standard ne couvre cela, et personne ne voulait bricoler l’ERP pour autant.

Nous avons donc construit une petite app side-by-side : un service CAP qui lit les commandes via l’API released des commandes clients, les agrège par client et sert un tableau de bord léger. Le tout est intégré comme mashup directement dans SAP Sales Cloud V2, avec SSO par iframe pour que personne ne se connecte deux fois. Le commercial ouvre le client dans le CRM et voit le tableau de bord comme s’il faisait partie du produit.

Le bilan : l’ERP n’a jamais été touché. L’app tourne dans quelques centaines de MB de mémoire Cloud Foundry. Les coûts d’infrastructure mensuels se situent dans les deux chiffres en francs. Et les ventes ont obtenu une vue du client qui n’existait tout simplement pas avant.

La checklist d’architecture

Pour que le modèle reste propre, nous nous tenons à cinq points dans chaque projet :

1. Uniquement des API released. Ce qui n’est pas documenté comme released dans le SAP Business Accelerator Hub n’est pas consommé. Point final. Cette seule règle décide si l’app survit aux upgrades.
2. Un accord de communication par scénario. Pas un accord fourre-tout avec tous les scopes, mais un accord dédié par cas d’usage métier. Cela garde les autorisations traçables et les mises hors service indolores.
3. Principal propagation ou utilisateur technique : décider consciemment. Si l’ERP doit savoir quel humain interroge, il vous faut la principal propagation. Si un utilisateur technique suffit, c’est plus simple, mais alors l’app vérifie elle-même qui peut voir quoi. Les deux sont légitimes ; l’indécision, non.
4. Service Destination au lieu d’URL dans le code. Les endpoints, les credentials et la méthode d’authentification vivent dans la destination, jamais dans le repository.
5. Un sous-compte BTP par étage. Test et production séparés, chaque étage avec ses propres destinations vers le tenant S/4HANA correspondant. Cela semble évident, et c’est de facto étonnamment souvent négligé.

La récompense : des upgrades dont personne ne se soucie

C’est ici que la discipline paie. S/4HANA Public Cloud reçoit ses upgrades de release au rythme trimestriel, qu’on le veuille ou non. Qui aurait modifié le noyau testerait maintenant ses modifications chaque trimestre. L’app side-by-side, elle, ne remarque rien de l’upgrade, parce qu’elle n’utilise que des API released et versionnées dont SAP garantit la compatibilité. Notre tableau de bord de l’exemple a traversé plusieurs changements de release. Effort de notre côté : zéro.

C’est le vrai sens du clean core. Pas un dogme, mais la liberté de laisser les upgrades simplement se produire.

Savoir-faire de projet : construire ennuyeux

La règle la plus importante pour les apps side-by-side est peu spectaculaire : construisez-les ennuyeuses. Des tableaux de bord orientés lecture, de petits scénarios d’écriture via des API released, des tâches clairement délimitées. C’est exactement là que le modèle montre sa force.

Deux signaux d’alarme tirés de projets que nous avons repris. Premièrement : si vous vous surprenez à répliquer la moitié de l’ERP dans une HANA Cloud, arrêtez-vous et remettez la cible en question. À partir de ce point, vous ne construisez plus un scénario d’extension, mais un deuxième système avec tous les problèmes de synchronisation qui vont avec. Deuxièmement : surveillez les limites de débit des API. Les API released sont bridées, et une app qui réinterroge 75’000 documents à chaque chargement de page l’apprend douloureusement. Agréger, mettre en cache, recharger de manière planifiée : sans éclat, mais exactement juste.

Questions fréquentes

Combien coûte l’exploitation d’une petite app Cloud Foundry ?

Moins que ce que la plupart attendent. Vous payez essentiellement la mémoire Cloud Foundry (heures-GB) plus de petits postes pour les services Destination et Authorization. Une app avec quelques centaines de MB de mémoire finit à deux chiffres en francs par mois. Le bloc de coûts pertinent n’est pas l’exploitation, c’est la construction, et même celle-ci reste raisonnable pour un scénario ciblé.

Quand l’extensibilité key-user, quand BTP Cloud Foundry, quand Steampunk ?

Notre règle empirique : extensibilité key-user pour les champs, validations et ajustements d’interface dans une app existante. BTP Cloud Foundry dès qu’il faut une agrégation de données propre, une interface propre ou une intégration dans un autre système (un CRM, par exemple). Steampunk, c’est-à-dire ABAP Cloud embarqué ou sur BTP, quand la logique doit vivre près des transactions ERP et que l’équipe apporte des compétences ABAP. ABAP Cloud aura d’ailleurs bientôt son propre article ici.

Une telle app peut-elle être intégrée dans SAP Sales Cloud V2 ?

Oui, et c’est l’un des plus beaux cas d’usage. Sales Cloud V2 intègre l’app comme mashup, par iframe directement dans la vue client ou opportunité. Avec un SSO correctement mis en place, les utilisateurs ne remarquent pas qu’ils travaillent dans une app externe. C’est exactement ainsi que tourne notre tableau de bord de chiffre d’affaires de l’exemple.

L’app casse-t-elle quand SAP modifie l’API ?

Les API released sont versionnées, et SAP maintient les versions existantes stables. Les nouvelles versions arrivent de manière additive. Le risque se situe presque entièrement du côté des interfaces non released, et c’est précisément pourquoi la règle numéro un de la checklist se trouve là où elle se trouve.

Votre extensibilité key-user est à sa limite et la prochaine proposition sur la table s’appelle modification du noyau ? Nous vous montrons volontiers à quoi ressemble le modèle side-by-side dans votre cas. Parlez-nous.