SAP BTP multi-cloud : quels bénéfices tirer d’une migration imposée ?

SAP BTP s’éloigne donc des environnements propriétaires SAP sur lesquels il est né pour adopter  une logique multicloud, basée sur différents hyperscalers (AWS, Microsoft Azure, Google Cloud…). Dans la terminologie de l’éditeur, SAP BTP Neo, qui s’exécutait uniquement dans les datacenters du premier éditeur européen, va céder la place au multi-cloud environment – souvent improprement appelé  “Cloud Foundry”. Au 31 décembre 2028, tous les développements effectués sur cette plateforme de première génération devront avoir migré vers  la version modernisée du PaaS.

L’appellation “SAP BTP Cloud Foundry” masque, en réalité, un raccourci trompeur. Car si la nouvelle version de SAP BTP est bien proposée sur l’environnement de développement Open Source éponyme, les entreprises disposent également de deux autres options : Kyma, autre projet Open Source qui s’appuie sur Kubernetes pour des applications conteneurisées, et ABAP Environment destiné aux développements dans le langage propriétaire de SAP.

Cet état des lieux montre bien la variété des choix qu’offre cette migration, tant en termes d’infrastructures d’hébergement que d’environnements ou de langages de développement. « Toutefois, la migration vers le multi-cloud environment n’est pas transparente », prévient Mikaël Thépault, qui dirige l’activité SAP BTP au sein du groupe Talan. Avec des implications tant contractuelles que technologiques, c’est un chantier qu’il vaut mieux anticiper, d’autant que SAP réserve désormais toutes ses évolutions majeures au multi-cloud environment.

Une migration avec un œil FinOps

« D’abord, il faut examiner l’aspect contractuel, conseille l’expert. Sur Neo, contre un forfait annuel, les entreprises avaient accès à tous les services de la plateforme. Sur le multi-cloud environment, on passe à une logique de facturation à l’usage, avec trois modèles possibles : souscription, crédits ou approche hybride. Il faut donc analyser les services consommés pour retenir l’approche la plus avantageuse.»

Cette migration est l'occasion de réexaminer les architectures déployées sur Neo sous l'angle de l'optimisation des coûts (FinOps). « Prenons l’exemple du service Integration Suite, illustre l'expert. Sur Neo, les entreprises déployaient souvent trois tenants distincts : développement, qualité et production. Avec le multi-cloud environment et sa facturation à l'usage, il devient pertinent de mutualiser : un tenant pour le hors-production, un pour la production. L'économie n'est pas négligeable, chaque tenant représentant un coût mensuel significatif. »
Par ailleurs, dans multi-cloud environment, chaque service est associé à un coût basé sur la consommation / volume rendant indispensable le suivi des consommations, comme le propose Talan avec son offre BTP4You. Celle-ci comprend  un pilotage de consommation détaillé avec rapprochement des relevés SAP, une veille sur le cycle de vie et les nouveautés des services utilisés, ainsi qu’un conseil en architecture adapté aux projets et problématiques métiers. « En effectuant les bons choix d’architecture, le passage au multi-cloud environment ne se traduit pas par une inflation des coûts, assure Mikaël Thépault. L’un de nos clients dans l’énergie, par exemple, a effectué, à isopérimètre, la migration de ses applications mobiles et Fiori dans une enveloppe budgétaire similaire à celle qu’il consacrait à Neo, notamment en profitant des services additionnels sans surcout pour le prototypage et des optimisations découlant d’une facturation à l'usage.

Des outils pour simplifier la migration

La seconde étape du projet concerne la migration de l’existant proprement dite, pour laquelle SAP met à disposition des procédures de migration pour chaque service. Deux cas méritent une attention particulière : les développements spécifiques et l’intégration. Sur le premier point, l'outillage existe mais la migration se fait plus ou moins simplement selon l'ancienneté du code : « Les développements récents s’adaptent relativement facilement, observe Mikaël Thépault, mais les applications plus anciennes peuvent nécessiter des adaptations importantes. À cela s'ajoute la nécessité de mettre en place un repository Git pour la gestion de version, auparavant intégrée nativement dans Neo. » Sur le volet intégration, « l'outillage assure une migration simplifiée de la version Integration Suite de Neo vers celle du multi-cloud environment en minimisant les impacts. Mais il faut rester attentif à l'aspect FinOps, car si la version Neo permettait de consommer autant de messages que souhaité, celle du multi-cloud environment inclut une limite de messages par tenant et par mois. Au-delà, chaque message supplémentaire est facturé. »

Factures électroniques et IA : Cloud Foundry et rien d’autre

Ces efforts de migration et de mise en place d’un suivi de la consommation débouchent sur l’accès à une suite beaucoup plus riche, dotée d’une architecture event-driven et construite sur une logique poussée de DevOps. Avec des gains immédiats sur des projets souvent inscrits tout en haut de la feuille de route technologique des entreprises. Comme la facturation électronique. « Pour une solution bâtie sur une plateforme de dématérialisation agréée, ce serait dommage de s’en remettre à une intégration via Neo, alors que le multi-cloud environment permet de bâtir une solution synchrone directement sur les API de l’ERP Cloud (on premise, public et private). Par ailleurs, toute solution construite sur Neo devra être revisitée avant fin 2028 », observe ainsi le responsable de l’activité BTP de Talan.
Même constat avec l'IA : le multi-cloud environment offre SAP AI Core pour faciliter la consommation de LLM du marché, ainsi que l'accès à l'assistant IA Joule.