La validation de l’architecture technique et le choix des technologies pour une Mobilité ERP Efficace

De nos jours, de plus en plus de terminaux mobiles sont utilisés pour accéder aux ressources personnelles ou professionnelles. Qu’il s’agisse de téléphone, de tablette ou encore de PC, les tailles des écrans et les fonctionnalités sont variables et les solutions apportées aux utilisateurs doivent en tenir compte.

Par ailleurs, en entreprise, rares sont ceux qui profitent pleinement du cloud et il faut donc retravailler l’architecture afin de permettre aux utilisateurs de consommer les applications, depuis leurs terminaux mobiles, leur permettant d’interagir avec l’ERP. Ces changements devant être en accord avec les règles de sécurité et d’architecture de l’entreprise et en ligne avec la stratégie IT de celle-ci.

Pour répondre à ces problématiques, plusieurs solutions sont possibles et il convient de considérer un projet de mobilité dans sa globalité. En effet, il est essentiel de valider l’architecture technique d’une telle solution avant d’entamer la phase de construction car cette première étape peut apporter des contraintes nécessitant de revoir la conception de l’application.

Parmi les sujets essentiels, on compte l’authentification, l’accès aux données, la gestion du référentiel utilisateur, l’intégration de technologies tierces (Push notifications par exemple), ou encore la sécurisation des flux.

Une fois l’architecture établie et validée, il convient de valider la technologie à utiliser. Cette étape peut déjà avoir été faite conjointement avec l’étape précédente. Afin de bien comprendre les choix qui s’offrent à vous dans ce contexte, voici un résumé des options disponibles dans un contexte SAP.

La mobilité peut être assurée de différentes manières selon votre contexte et vos besoins. En effet, créer une application web qui sera consommée sur une tablette ou encore développer une application IOS native ne vous apportera pas les mêmes avantages mais aura également des contraintes différentes. Il convient donc de bien comprendre ce qu’apporte chaque type de mobilité et quels impacts en découlent. Ainsi, la définition de votre besoin permettra de choisir la meilleure solution de mobilité.

En effet, il n’y a pas de meilleure façon de faire de la mobilité car c’est bel et bien votre besoin et votre contexte technique qui permettra de faire votre choix technologique. Ce qui fonctionne dans un contexte peut ne pas du tout être adapté pour un autre contexte même au sein de la même entreprise. Il convient donc de considérer les différentes options de mobilité pour chacun de vos besoins.

Pour un projet SAP, les choix qui s’offrent à nous sont multiples et s’articulent principalement autour de deux thématiques :

Les solutions Web

Ces solutions sont basées sur le développement web, qui est très connu et simple à utiliser. Côté SAP, ce type d’application est généralement créé avec SAPUI5. Ces solutions se déclinent en différentes technologies afin d’apporter toujours plus de fonctionnalités à l’utilisateur tout en restant dans le domaine du développement WEB. On retrouve dans ce type de solution les PWA ou encore les applications hybrides.

Pour un projet SAP, les choix qui s’offrent à nous sont multiples et s’articulent principalement autour de deux thématiques :

Les solutions Web

Ces solutions sont basées sur le développement web, qui est très connu et simple à utiliser. Côté SAP, ce type d’application est généralement créé avec SAPUI5. Ces solutions se déclinent en différentes technologies afin d’apporter toujours plus de fonctionnalités à l’utilisateur tout en restant dans le domaine du développement WEB. On retrouve dans ce type de solution les PWA ou encore les applications hybrides.

Les solutions natives

Les applications natives sont par définition les applications qui apportent la meilleure expérience utilisateur. Outre le développement natif classique, on retrouve des évolutions dans ce domaine afin d’apporter un design particulier, celui de FIORI par exemple. C’est en effet ce qu’apporte SAP, Apple et Google avec les SDK de SAP Cloud Platform dédiés au développement natif pour IOS ou Android. De plus, on retrouve également dans cette catégorie les solutions dites compilées comme Flutter ou React Native par exemple. Le gain principal est au niveau du coût car le résultat est proche d’une application native mais l’application est multiplateforme ce qui rationalise les couts de développement et de maintenance.

Ci-après je vais vous présenter plus en détail chaque technologie que vous pouvez utiliser pour vos projets de mobilité. Nous verrons que ces technologies peuvent être complémentaires dans vos paysages applicatifs cars elles répondent à des besoins particuliers et ont chacune leurs propres contraintes, avantages et inconvénients.

Le Framework SAPUI5 (ou Open UI5) est majoritairement responsif, ce qui signifie que les contrôles s’adaptent à différentes tailles d’écran. Ceci ne peut fonctionner que si les bonnes librairies sont utilisées car il existe en effet des contrôles qui ne s’adaptent pas ou peu aux différentes tailles d’écran.

Il est important de choisir avec cohérence les librairies pour une application. En effet certaines ne sont pas du tout responsives et ne doivent donc pas être utilisées dans une application qui se doit d’être utilisée en mobilité. Voici un petit schéma permettant de visualiser les combinaisons possibles. À droite, les librairies dites responsives, à gauche, celles qui ne le sont pas et au centre celles qui peuvent être utilisées dans les 2 cas. Les librairies rayées sont celles déjà dépréciées et qu’il ne faut plus utiliser.

Afin d’optimiser l’expérience utilisateur en mobilité, SAP Propose une application appelée SAP FIORI Client, disponible gratuitement sur les principaux stores. Cette application permet de « mobiliser » une adresse web comme un Launchpad. Ceci donne l’impression à l’utilisateur d’avoir ses applications FIORI sous la forme d’une application mobile.

Les Progressives Web App, PWA, sont des application web enrichies afin de permettre leur installation sur PC ou mobile. On distinguera 2 cas, les applications créées pour être des PWA et les applications « adaptées en PWA ». Vous l’aurez compris, une application adaptée offrira moins de capacité qu’une application qui aura été pensée directement pour être une PWA.

Dans le contexte SAPUI5, il s’agit d’une solution très intéressante puisqu’elle permet d’accéder aux applications FIORI/SAP UI5 depuis son smartphone ou depuis son PC sans pour autant nécessiter un développement lourd. Ce type de développement reste assez simple mais ne peut offrir que des fonctionnalités proche d’une application web classique. En effet, seules les capacités du mobile accessible depuis une API web pourront être exploitées, à la différence des applications hybrides ou natives.

L’un des avantages majeurs de ce type d’application est le support hors ligne par la mise en cache des contenus.

Vous l’aurez compris, ce type de développement se situe entre les applications Web classique et les applications hybride en offrant une expérience mobile très satisfaisantes tout en restant très abordable tant sur la complexité que sur le coût.

Si cette technologie vous intéresse, un article dédié est disponible sur le blog Codilog :

SAP PWA – Les Progressive Web Apps avec SAP

Il s’agit d’applications web qui sont ensuite encapsulées dans un conteneur mobile. Il est également possible d’utiliser des plugins permettant d’interagir avec les fonctionnalités du téléphone comme l’appareil photo par exemple.

En matière de développement, cela revient à développer une application web, comme on le ferait pour une application FIORI. Ensuite, via les plugins permettant d’accès aux fonctionnalités du téléphone, le développeur peut ajouter des fonctionnalités. Enfin, il faut construire l’application pour la plateforme voulue (IOS, Android, Windows). Il est possible de s’appuyer sur un autre Framework que sapui5 comme Angular ou React.

Parmi les nombreux outils permettant de créer des applications mobiles hybrides, l’un des plus connus est Apache Cordova. Il s’agit d’une solution open source proposant de nombreux plugins et qui est également utilisé par SAP (KAPSEL) et Neptune.

Les plugins Kapsel permettent de gérer certaines fonctionnalités du téléphone ou de l’application comme par exemple permettre la lecture de code-barres, faciliter l’authentification et la gestion des notifications Push ou encore gérer les mises à jour des applications.

Avec une telle solution est qu’avec le même code source, qui est un projet web comme par exemple une application FIORI/UI5, vous pourrez générer une application IOS, Android ou encore Windows Phone. Ceci représente une réelle économie, tant sur le développement que sur la maintenance de vos applications. En effet, côté maintenance, un seul code source sera à maintenir mais aussi une seule technologie ce qui facilite les contrats de TMA.

Il s’agit de la solution à privilégier si vous souhaitez fournir une application sur plusieurs plateformes tout en maitrisant les coûts. Il s’agira néanmoins de s’assurer de conserver le même Framework web pour garder cet avantage car même s’il s’agit de Framework JavaScript, SAPUI5, Angular ou encore Vue sont assez différents et peuvent être assimilés à différents langages.

Cette solution est la plus performance mais aussi la plus couteuse. Elle permet en effet d’optimiser les performances et d’utiliser au maximum les capacités du téléphone. Toutefois, elle requiert de développer dans le langage de la plateforme, à savoir Swift pour IOS ou encore Java pour Android. De fait, un double développement sera nécessaire pour couvrir à la fois IOS et Android.

SAP à développer un partenariat avec Google et Apple qui a permis d’aboutir à une SDK FIORI spécialisé dans ces 2 plateformes. On a donc FIORI 4 IOS et FIORI 4 Android permettant d’avoir un design FIORI sur des applications mobile natives. Par ailleurs, cela permet de développer plus facilement les applications puisque le SDK propose des contrôles prêts à l’emploi comme pour SAPUI5. Qu’importe le langage, le design FIORI reste le même.

SAP Propose des outils permettant pour chaque type de mobilité d’accélérer, de supporter et de faciliter les développements.

Ces outils sont basés sur le SAP Cloud Platform mobile services (SCPMS). Parmi ces outils, on trouve un environnement de développement, des services d’intégrations, des contenus additionnels (plugins), des SDK ou encore des services cloud comme les SAP CARDS.

D’un point de vue architecture, plusieurs couches sont nécessaires au fonctionnement des applications natives IOS ou Android. Dans les 2 cas, le SDK de SAP Cloud platform Mobile services est nécessaire, ce qui induit des coûts additionnels de licence (à partir de 3€/utilisateur/mois). Par ailleurs, il convient de rappeler que seul MAC OS, au travers de XCode peut compiler une application IOS, et cela nécessite également une licence développeur IOS.

Toutefois, la licence aux services mobiles de SCP présente de nombreux avantages, en matière de developpement et opérations mais aussi au niveau de la simplification de l’architecture ou encore de l’authentification par exemple.

La prise en main est facilitée par le SDK puisqu’il s’agit d’un équivalent de SAPUI5 pour les plateformes natives, aussi, que l’on soit développeur IOS/Android ou sapui5/FIORI, la moitié du chemin sera déjà parcourue. Par ailleurs, comme pour FIORI Web, la communauté est très développée et propose de nombreux contenus permettant de monter rapidement en compétence ou d’être aidé en cas de besoin. On retrouve par exemple des cours open SAP ou encore des tutoriaux dédiés à la technologie :

https://developers.sap.com/mission.sdk-android-get-started.html

https://developers.sap.com/group.ios-sdk-setup.html

Avec SCP et plus précisément le SAP Mobile services, SAP propose un outil permettant de créer des micro-applications, il s’agit des SAP Mobile Cards.

Le fonctionnement de cette technologie est simple, un administrateur met à disposition des contenus mobilisés et les utilisateurs peuvent les consommer depuis l’application SAP Mobile services client fournie par SAP.

En se connectant, l’utilisateur verra dans son application, l’ensemble des « Cards » mis à sa disposition. Il pourra ainsi passer d’un flux à l’autre très facilement et le tout depuis la même application.

Les SAP Mobile Cards offrent les fonctionnalités suivantes

• Support hors ligne pour une consommation à tout moment
• Rafraichissement des données automatiquement
• Notifications push, rappels ou alertes géo localisées
• Intégration mobile avec accès au téléphone, SMS, email, etc.
• Groupes de Cards pour un accès rapide et simplifier à l’ensemble de vos contenus et assurer une bonne organisation de vos contenus.

Ces micro-applications sont consommées au travers de l’application mobile SAP Mobile Services Client fournie par SAP et disponible dans les stores

https://play.google.com/store/apps/details?id=com.sap.mobileservices.client&hl=fr

https://apps.apple.com/fr/app/sap-mobile-services-client/id1413653544

Les cas d’usages de cette technologie sont des cas simples présentant 1 à 2 écrans maximum. Ces applications représentent des informations ou des actions que l’utilisateur peut vouloir visualiser/réaliser à tout moment avec ou sans réseau au moment où celui-ci est disponible. Il s’agit donc de présenter des écrans simples, intuitifs et centrés sur l’objet présenté.

• Applications de validation simples, Demandes d’achats, contrat, commandes d’achats, congés etc.
• Cockpits d’indicateurs ciblés (mono indicateurs en général)
• Activités récurrentes mais simples comme la création de congés, de feuille de temps, etc.

Les Mobiles Cards peuvent être créées depuis un modèle(Template). Il existe une dizaine de modèles disponibles au travers de l’outil Template Manager. Grâce à eux, les développements sont accélérés par un design déjà pensé et du code à adapté plus qu’à développer.

Outre votre système SAP S/4 HANA, ces modèles sont disponibles pour de nombreux outils SAP tels que Success Factors, Concur, Ariba ou encore C/4 Hana.

Avec ces applications, il est simple de proposer aux utilisateurs d’accéder à leurs tâches de workflow directement depuis leur mobile. Ainsi, l’équivalent de l’application My Inbox et les tâches qu’elle contient sont directement synchronisées sur le mobile. L’utilisateur peut même être notifié de nouvelles tâches pour gagner en efficacité

Exemple de micro-applications fournies par SAP pour Success Factors :

Bien sûr, il est également possible de définir vos propres Cards spécifiques mais avant de se lancer, il convient de s’assurer qu’il s’agit de la bonne solution. En effet, les SAP Mobile Cards ont des contraintes techniques mais également ergonomiques qu’il faut considérer au risque de ne pas satisfaire les utilisateurs. Rappelons qu’il s’agit une solution de MICRO Applications.

Les SAP Mobile Cards présentent les avantages suivants :

• Réduction des couts de développement grâce aux modèles d’applications avec pas ou peu de code.
• Centralisation de l’accès aux applications dans une seule et même application comme pour l’application Wallet de IOS
• Intégration de nouveaux contenus directement depuis un plugin Launchpad
• Accès direct aux contenus
• Accès hors ligne

Les applications compilées en code natif sont à mi-chemin entre les applications natives et les applications hybrides.

Il s’agit en effet d’application hybride mais qui ne sont pas basé sur les Webview à l’exécution.

Aussi, elles sont généralement plus performantes que les applications hybrides et permettent une utilisation plus large des fonctionnalités du téléphone. C’est une option à privilégier dans le cas où une application hybride ne pourrait satisfaire vos besoins ou si les besoins en performance sont très accrus.

A l’inverse, si vous avez besoin de librairies JavaScript tierces pour votre application, il sera plus compliqué de traiter le sujet avec ce genre de technologie.

Les solutions du marché les plus connues permettant de créer ce genre d’applications sont Native Script, Flutter ou encore ReactNative.

Ce type de développement s’intègre toutefois mal avec les produits SAP puisque le Framework SAPUI5 ou plus généralement le design FIORI n’existe pas dans ce domaine. L’arrivée des Web Components permet de raccrocher les wagons mais cela reste toutefois assez timide et opter pour une telle solution engendrera forcément des coûts supplémentaires en matières d’acquisition de compétences, de maintenance voire d’architecture et de licences selon vos choix.

L’écosystème de la technologie est un élément important auquel on ne pense pas toujours. En effet, il est important qu’il existe une forte communauté autour des outils et technologies que vous choisirez car c’est d’une part un gage de qualité, mais aussi l’assurance de trouver de l’aide en cas de problèmes, d’une documentation fournie et d’évolutions régulières. Enfin, c’est un gage de pérennité.

Il convient ensuite de se poser les bonnes questions afin de déterminer au mieux la solution à privilégier pour le développement de l’application.

• Est-il nécessaire d’accéder aux fonctionnalités natives du téléphone ?
• A-t-on besoin d’un accès web et mobile ?
• L’application est-elle simple ou complexe ?
• Y a-t-il beaucoup de saisies attendues ?
• Les ressources sont –elles accessibles par HTTPS ? de manière asynchrone ?
• Quelles compétences à mon équipe de développement/de maintenance ?

La réponse à ces questions peut influer sur vos choix de solution ou à minima vous permettre de pallier à certains manquements que vous pourriez avoir. Par exemple, former l’équipe de développement si elle n’a pas les compétences en développement natif par exemple.

Si vous hésitez entre différentes options répondant à vos critères, vous pourrez trancher en fonction du cout de chaque option, de la stratégie IT ou encore de futures fonctionnalités envisagées.

Les applications natives vous apporteront à la fois la meilleure performance et la meilleure couverture de fonctionnalités du téléphone. Toutefois, elles seront les plus couteuses en développement et maintenance.

Les applications hybrides (ou compilées) sont plus polyvalentes car elles permettent de rationaliser les couts tout en apportant des fonctionnalités natives du téléphone.

Enfin, les applications Web sont les plus simples et rapides à mettre en œuvre, elles ont toutefois des fonctionnalités limitées à ce que peuvent offrir les API Web. Les API natives du téléphone ne peuvent pas être consommés.

Pour conclure, il convient de rappeler que toutes les façons de faire de la mobilité évoquées ici sont à considérer car elles présentent toutes des avantages et des inconvénients. Il est difficile de présenter une analyse comparative entre toutes ces technologies car certaines sont très pertinentes dans un contexte particulier alors qu’elles peuvent paraitre peu concurrentiel face au développement natif par exemple. Toutefois, lorsqu’on prend le temps d’analyser le contexte, on se rend assez vite compte que l’application native n’est pas forcément la meilleure solution pour des raisons de coût par exemple au regard des fonctionnalités attendues. Comme le dit l’expression, inutile de prendre un canon pour tuer une mouche, il faut en effet choisir la meilleure technologie face au contexte.

Bien que l’on se trouve souvent contraint en matière de choix par des stratégies IT, il convient de rappeler que la base de chaque solution présentée ici est FIORI et que l’on parle ici uniquement de la façon de mettre en œuvre ce design.